Codest
  • Tietoa meistä
  • Palvelut
    • Ohjelmistokehitys
      • Frontend-kehitys
      • Backend-kehitys
    • Staff Augmentation
      • Frontend-kehittäjät
      • Backend-kehittäjät
      • Tietoinsinöörit
      • Pilvi-insinöörit
      • QA insinöörit
      • Muut
    • Se neuvoa-antava
      • Tilintarkastus & konsultointi
  • Toimialat
    • Fintech & pankkitoiminta
    • E-commerce
    • Adtech
    • Terveysteknologia
    • Valmistus
    • Logistiikka
    • Autoteollisuus
    • IOT
  • Arvo
    • TOIMITUSJOHTAJA
    • CTO
    • Toimituspäällikkö
  • Tiimimme
  • Tapaustutkimukset
  • Tiedä miten
    • Blogi
    • Tapaamiset
    • Webinaarit
    • Resurssit
Työurat Ota yhteyttä
  • Tietoa meistä
  • Palvelut
    • Ohjelmistokehitys
      • Frontend-kehitys
      • Backend-kehitys
    • Staff Augmentation
      • Frontend-kehittäjät
      • Backend-kehittäjät
      • Tietoinsinöörit
      • Pilvi-insinöörit
      • QA insinöörit
      • Muut
    • Se neuvoa-antava
      • Tilintarkastus & konsultointi
  • Arvo
    • TOIMITUSJOHTAJA
    • CTO
    • Toimituspäällikkö
  • Tiimimme
  • Tapaustutkimukset
  • Tiedä miten
    • Blogi
    • Tapaamiset
    • Webinaarit
    • Resurssit
Työurat Ota yhteyttä
Takaisin nuoli PALAA TAAKSE
2021-10-05
Ohjelmistokehitys

Miksi sinun pitäisi käyttää SCSS:ää tyyliteltyjen komponenttien sijaan?

Codest

Jacek Ludzik

Tuotesuunnittelija

Olen työskennellyt parin viime kuukauden ajan erään asiakkaamme projektin parissa. Kun olin aivan alussa, jouduin valitsemaan kirjaston muotoilua varten.

Vertailtuamme suosittuja ratkaisuja, kuten tavallista CSS:ää, Emotion, SCSS ja Tyylitellyt komponentit, valitsin lopulta viimeisen. Kaikki näytti olevan kunnossa. Se on nykyään hyvin suosittu kirjasto, mikä tarkoittaa, että -
on jo suuri yhteisö, joten jos kohtaisin ongelmia, löydän todennäköisesti ratkaisun jostain Stack Overflow'sta tai GitHubista. Sen lisäksi, Tyylitellyt komponentit on joitakin optimointiominaisuuksia, mikä tarkoittaa, että ne renderöivät vain silloin, kun niitä tarvitaan. Osoitteessa projekti odotettiin rakennettavan käyttäen React:tä ja Typescriptiä. Tämä kirjasto tukee erinomaisesti molempia tekniikoita. Kuulostaa mahtavalta, eikö?

Aloitin koodaamisen silloin. Kuukauden kuluttua, kun sovellus on kasvanut, etusivun joukkue ja minä keskityin ominaisuuksien toimittamiseen, huomasimme, että hämmästyttävästi toimiva Tyylitellyt komponentit kirjastolla oli oma maalinsa, ja kerron teille miksi.

Ensinnäkin, nimeämiskäytäntö. Erottamaan toisistaan Tyylitellyt komponentit React-komponenteista, jouduin käyttämään Tyylitelty etuliite, joka väheni koodi luettavuus. Sitten (mikä saattaa olla outoa), Typescript-tuki. Tyylitellyt komponentitperustuvat CSS-in-JS-lähestymistapaan, kuten ehkä tiedätkin. Tämä tarkoittaa, että voit siirtää niille minkä tahansa propin ja muuttaa syötteen tyyliä tämän propin perusteella, ja henkilökohtaisesti pidän tätä ominaisuutta mahtavana. Typescriptissä sinun pitäisi myös toteuttaa tämän propin tyyppi tekee siitä koodia pidemmän minkä tahansa Tyylitelty komponentti. "Mutta se kestäisi vielä 5 sekuntia, joten mikä on ongelmasi?" - saatat sanoa. Olet oikeassa, vaikka kun sovellus skaalautuu nopeasti ja komponenttien määrä on
lisääntyy, nämä 5 sekuntia voidaan helposti moninkertaistaa satoihin kertoihin. Toinen ongelma on sijoitus Tyylitellyt komponentit.

Jotkut JS-kehittäjät sijoittavat ne samaan tiedostoon sen komponentin kanssa, johon ne kuuluvat, ja toiset luovat niille erilliset tiedostot. Molemmat lähestymistavat ovat hyviä monista syistä. Se riippuu lähinnä komponentin monimutkaisuudesta. Jompaakumpaa tekniikkaa noudattamalla voidaan säilyttää koheesio, mutta niiden yhdistämisellä saavutetaan juuri päinvastainen tulos. Luovuimme CSS-in-JS -lähestymistavasta ja siirryimme käyttämään SCSS. Se ei ollut helppoa ja nopeaa, mutta pienen avun avulla selvisimme siitä. Aloitimme html-tunnisteiden muotoilun BEM-menetelmällä ja laitoimme tietenkin tyylit erillisiin tiedostoihin, yksi per komponentti. Sanoin, että JS-tukien välittäminen Tyylitellyt komponentit on mahtava ominaisuus, mutta SCSS se on mahdotonta. Luulen, että olemme myös kaikki samaa mieltä siitä, että syntaksi, jolla React haluaa koodata ehdollisia luokkia, on kauhea.

react-luokkien nimien koodi

No, on olemassa yksi varsin mielenkiintoinen ratkaisu. Jos yhdistät BEM-menetelmän ja clsx kirjasto, saat jotain tällaista (iso huuto ystävälleni Przemek Adamczykille, joka näytti minulle tämän kirjaston).

clsx-koodi

Näyttää paljon siistimmältä, eikö vain?

Parasta on se, että sinun tarvitsee vain kirjoittaa olosuhdemuuttuja komponenttitasolla ja
ei muotoilun tasolla. Se todella säästää aikaa. Valitettavasti tällaisella ratkaisulla on haittapuolensa.
SCSS on helppo ja ystävällinen, mutta ole varovainen, kun käytät sitä Next.js:n kanssa. Tämä kehys ei
sallii tyylitiedostojen tuonnin suoraan komponenttitiedostoon (vain CSS-moduulit).

Jos haluat yhden tiedoston komponenttia kohti, sinun on luotava seuraavat tiedostot index.scss joka sisältää kaikki SCSS tiedostot ja
tuo se _app.tsx tiedosto. Ainoa ongelma on se, että sinun on tuotava manuaalisesti jokainen SCSS luotu tiedosto. React:ssä tätä ongelmaa ei kuitenkaan ole, ja voit tuoda SCSS tiedostoja minne haluat. Älä ymmärrä minua väärin. Tyylitellyt komponentit ovat todella hyviä. Kuten sanoin aiemmin, JS-muuttujien siirtäminen sekä globaali teema ovat hämmästyttäviä ominaisuuksia. Kun rakennat isoa sovellusta, jossa optimointi on ratkaisevaa, tämä kirjasto todennäköisesti täyttää tarpeesi. Meidän tapauksessamme kuitenkin siirtyminen SCSS osui jättipottiin.

Yhteenveto

Lopuksi voidaan todeta, että vaikka on olemassa päteviä perusteluja molemmille. SCSS ja tyylitellyt komponentit osoitteessa web-kehitys , lopullinen päätös riippuu useista tekijöistä. SCSS tarjoaa tutumman syntaksin kokeneet kehittäjät perinteisessä CSS:ssä ja tarjoaa saumattoman integraation olemassa oleviin koodipohjat ja komponenttikirjastot .

Toisaalta, Tyylitellyt komponentit tarjota parannettu kehittäjäkokemus sen kyky kapseloida tyylejä komponenttien sisällä ja yksinkertaistaa muotoiluprosessia. Se edistää myös koodin modulaarisuutta ja uudelleenkäytettävyyttä, minkä ansiosta front-end-suunnittelijat voivat tehokkaasti hallinnoida komponenttien hakemisto ja luoda johdonmukainen käyttöliittymä koko verkkosovellus . Ottaen huomioon käyttäjätiedot turvallisuuden ja suorituskyvyn kannalta on ratkaisevan tärkeää arvioida molempien lähestymistapojen vaikutusta lopulliseen paketin kokoon ja latausaikoihin. Viime kädessä valinta seuraavien vaihtoehtojen välillä SCSS ja tyylitellyt komponentit tulisi perustua hankkeen erityistarpeisiin, hankkeen toteuttajan osaamiseen ja osaamiseen. kehitystiimi ja ohjelman yleiset tavoitteet verkkosovellus . Kehittäjien on suositeltavaa arvioida kaikki tekijät, pysyä ajan tasalla läpi blogikirjoitukset ja alan keskusteluista ja tehdä tietoon perustuva päätös, joka vastaa heidän projektivaatimuksiaan ja parantaa yleistä kokonaisuutta. front-end-kehitysprosessi .

Aiheeseen liittyvät artikkelit

Ohjelmistokehitys

Mestareiden vertailu: Angular vs Vue

Tällä hetkellä on olemassa muutamia yleisesti käytettyjä ja jatkuvasti kehitettyjä frontend-kehyksiä, joista kukin eroaa hieman toisistaan. Silti niillä saattaa olla jotain yhteistä. Tässä...

Oliwia Oremek

Tilaa tietopankkimme ja pysy ajan tasalla IT-alan asiantuntemuksesta.

    Tietoa meistä

    The Codest - Kansainvälinen ohjelmistokehitysyritys, jolla on teknologiakeskuksia Puolassa.

    Yhdistynyt kuningaskunta - pääkonttori

    • Toimisto 303B, 182-184 High Street North E6 2JA
      Lontoo, Englanti

    Puola - Paikalliset teknologiakeskukset

    • Fabryczna Office Park, Aleja
      Pokoju 18, 31-564 Krakova
    • Brain Embassy, Konstruktorska
      11, 02-673 Varsova, Puola

      Codest

    • Etusivu
    • Tietoa meistä
    • Palvelut
    • Tapaustutkimukset
    • Tiedä miten
    • Työurat
    • Sanakirja

      Palvelut

    • Se neuvoa-antava
    • Ohjelmistokehitys
    • Backend-kehitys
    • Frontend-kehitys
    • Staff Augmentation
    • Backend-kehittäjät
    • Pilvi-insinöörit
    • Tietoinsinöörit
    • Muut
    • QA insinöörit

      Resurssit

    • Faktoja ja myyttejä yhteistyöstä ulkoisen ohjelmistokehityskumppanin kanssa
    • Yhdysvalloista Eurooppaan: Miksi amerikkalaiset startup-yritykset päättävät muuttaa Eurooppaan?
    • Tech Offshore -kehityskeskusten vertailu: Tech Offshore Eurooppa (Puola), ASEAN (Filippiinit), Euraasia (Turkki).
    • Mitkä ovat teknologiajohtajien ja tietohallintojohtajien tärkeimmät haasteet?
    • Codest
    • Codest
    • Codest
    • Privacy policy
    • Verkkosivuston käyttöehdot

    Tekijänoikeus © 2025 by The Codest. Kaikki oikeudet pidätetään.

    fiFinnish
    en_USEnglish de_DEGerman sv_SESwedish da_DKDanish nb_NONorwegian fr_FRFrench pl_PLPolish arArabic it_ITItalian jaJapanese ko_KRKorean es_ESSpanish nl_NLDutch etEstonian elGreek fiFinnish