Waarom zou je SCSS gebruiken in plaats van gestileerde componenten?

Na het vergelijken van populaire oplossingen zoals gewone CSS, Emotion, SCSS en Gestileerde onderdelenUiteindelijk selecteerde ik de laatste. Alles leek in orde te zijn. De bibliotheek is tegenwoordig erg populair, wat betekent dat
er is al een grote community, dus als ik problemen tegenkom, vind ik waarschijnlijk wel ergens een oplossing op Stack Overflow of GitHub. Daarnaast, Gestileerde onderdelen hebben enkele optimalisatiefuncties, wat betekent dat ze alleen renderen wanneer dat nodig is. De project was naar verwachting gebouwd met React en Typescript. Deze bibliotheek heeft geweldige ondersteuning voor beide technologieën. Klinkt geweldig, toch?

Ik begon toen met coderen. Na een maand, toen de app gegroeid was, werd de frontend team en ik gericht op het leveren van functies, ontdekten we dat de verbazingwekkende Gestileerde onderdelen De bibliotheek had een eigen doel en ik zal je vertellen waarom.

Allereerst de naamgevingsconventie. Om onderscheid te maken tussen Gestileerde onderdelen van React componenten, moest ik de Gestileerd voorvoegsel dat afnam code leesbaarheid. Dan (wat misschien vreemd is), ondersteuning voor Typescript. Gestileerde onderdelenzijn, zoals je misschien weet, gebaseerd op de CSS-in-JS aanpak. Dit betekent dat je een willekeurige prop kunt doorgeven en de stijl van de invoer kunt wijzigen op basis van deze prop en persoonlijk vind ik dit een geweldige functie. In Typescript moet je ook het type van deze eigenschap implementeren, waardoor de code langer wordt. Gestileerd onderdeel. "Maar het zou 5 seconden langer duren, dus wat is je probleem" - zou je kunnen zeggen. Je hebt gelijk, hoewel als de app snel opschaalt en het aantal componenten is
toenemend, kunnen deze 5 seconden gemakkelijk met honderden vermenigvuldigd worden. Een ander probleem is de plaatsing van de Gestileerde onderdelen.

Sommige JS-ontwikkelaars plaatsen ze in hetzelfde bestand met de component waartoe ze behoren en anderen maken er aparte bestanden voor. Beide benaderingen zijn goed om vele redenen. Het hangt vooral af van de complexiteit van het component. Het volgen van een van deze technieken kan de cohesie behouden, maar ze samenvoegen geeft precies het tegenovergestelde. We zijn afgestapt van de CSS-in-JS aanpak en gemigreerd naar SCSS. Het was niet gemakkelijk en snel, maar met een beetje hulp hebben we het gehaald. We begonnen met het stylen van html-tags in de BEM-methodologie en zetten de stijlen natuurlijk in aparte bestanden, één per component. Ik zei dat het doorgeven van JS props aan Gestileerde onderdelen is een geweldige functie, maar in SCSS het is onmogelijk. Ik denk dat we het er ook allemaal over eens zijn dat de syntaxis die React wil gebruiken om voorwaardelijke klassen te coderen verschrikkelijk is.

Nou, er is een heel interessante oplossing. Als je de BEM-methodologie verbindt met de clsx bibliotheek, krijg je zoiets als dit (grote shoutout naar mijn vriend Przemek Adamczyk voor het laten zien van deze bibliotheek)

Ziet er veel netter uit, vind je niet?

Het beste is dat je alleen de conditievariabele op componentniveau hoeft te typen en
niet op het niveau van styling. Het bespaart echt tijd. Helaas heeft zo'n oplossing ook nadelen.
SCSS is eenvoudig en vriendelijk, maar wees voorzichtig als je het gebruikt met Next.js. Dit framework doet niet
toestaan om stijlbestanden rechtstreeks in het componentbestand te importeren (alleen CSS-modules).

Als je één bestand per component wilt, moet je het volgende maken index.scss met al uw SCSS bestanden en
importeer het in de _app.tsx bestand. Het enige probleem is dat je handmatig elk SCSS bestand dat je hebt gemaakt. In React bestaat dit probleem echter niet en kun je het volgende importeren SCSS bestanden waar je maar wilt. Begrijp me niet verkeerd. Gestileerde onderdelen zijn echt goed. Zoals ik al eerder zei, zijn het doorgeven van JS-variabelen en het globale thema geweldige functies. Als je een grote app bouwt waarbij optimalisatie cruciaal is, zal deze bibliotheek waarschijnlijk aan je behoeften voldoen. In ons geval is migratie naar SCSS de jackpot winnen.

Samenvattend

Concluderend, hoewel er geldige argumenten zijn voor beide SCSS en gestileerde componenten in webontwikkeling De uiteindelijke beslissing hangt af van verschillende factoren. SCSS biedt een meer vertrouwde syntaxis voor ervaren ontwikkelaars in traditionele CSS en biedt een naadloze integratie met bestaande codebases en componentbibliotheken .

Aan de andere kant, Gestileerde onderdelen bieden verbeterde Ervaring als ontwikkelaar met de mogelijkheid om stijlen in te kapselen in componenten en het stylingproces te vereenvoudigen. Het bevordert ook modulariteit en herbruikbaarheid van code, waardoor front-end engineers efficiënt de onderdelenmap en een consistente UI maken voor alle webapp . Gezien het belang van gebruikersgegevens veiligheid en prestaties, is het cruciaal om de invloed van beide benaderingen op de uiteindelijke bundelgrootte en laadtijden te beoordelen. Uiteindelijk is de keuze tussen SCSS en gestileerde componenten moet gebaseerd zijn op de specifieke behoeften van het project, de vaardigheden van de ontwikkelingsteam en de algemene doelen van de webapplicatie . Het is raadzaam voor ontwikkelaars om alle factoren te evalueren, op de hoogte te blijven via blogberichten en discussies in de sector en een weloverwogen beslissing nemen die aansluit bij hun projectvereisten en de algehele kwaliteit van het project verbetert. front-end ontwikkelingsproces .