Proč byste měli používat SCSS místo stylizovaných komponent?

Po porovnání populárních řešení, jako jsou prosté CSS, Emotion, SCSS a Stylizované součásti, nakonec jsem vybral poslední. Vše se zdálo být v pořádku. V dnešní době má velmi oblíbenou knihovnu, což znamená.
je tu už velká komunita, takže kdybych narazil na nějaký problém, najdu pravděpodobně řešení někde na Stack Overflow nebo GitHubu. Kromě toho, Stylizované součásti mají některé optimalizační funkce, což znamená, že se vykreslují pouze v případě potřeby. Stránky projekt se očekávalo, že bude postaven pomocí React a Typescript. Tato knihovna má skvělou podporu pro obě technologie. Zní to úžasně, že?

Tehdy jsem začal kódovat. Po měsíci, kdy se aplikace rozrostla, se frontend tým a já se soustředil na poskytování funkcí, jsme zjistili, že úžasný Stylizované součásti knihovna měla svůj vlastní cíl a já vám řeknu proč.

Především jde o konvenci pojmenování. Rozlišování Stylizované součásti z komponentů React, musel jsem použít Stylizované předpona, která se snížila kód čitelnost. Dále (což může být zvláštní), podpora Typescriptu. Stylizované součásti, jak možná víte, jsou založeny na přístupu CSS-in-JS. To znamená, že jim můžete předat libovolnou rekvizitu a na základě této rekvizity změnit styl, tj. vstup, a osobně si myslím, že tato funkce je úžasná. V Typescriptu byste také měli implementovat typ této rekvizity, díky čemuž je kód delší než jakýkoli jiný Stylizovaná složka. "Ale trvalo by to o 5 vteřin déle, tak v čem je problém?" - můžete říct. Máte pravdu, i když když se aplikace rychle škáluje a počet komponent je
zvyšování, těchto 5 sekund může být snadno vynásobeno stokrát. Dalším problémem je umístění Stylizované součásti.

Některé stránky Vývojáři JS je umístit do stejného souboru s komponentou, ke které patří, a jiné pro ně vytvářejí samostatné soubory. Oba přístupy jsou dobré z mnoha důvodů. Většinou záleží na složitosti komponenty. Dodržování jedné z těchto technik může zachovat soudržnost, ale jejich slučování přináší přesný opak. Rezignovali jsme na přístup CSS-in-JS a přešli jsme na tzv. SCSS. Nebylo to snadné a rychlé, ale s malou pomocí jsme to zvládli. Začali jsme stylovat html značky podle metodiky BEM a samozřejmě jsme styly umístili do samostatných souborů, pro každou komponentu jeden. Řekl jsem, že předávání JS rekvizit Stylizované součásti je úžasná funkce, ale v SCSS je to nemožné. Myslím, že se také všichni shodneme na tom, že syntaxe, kterou chce React kódovat podmíněné třídy, je příšerná.

No, je tu jedno docela zajímavé řešení. Pokud spojíte metodiku BEM s metodikou clsx dostanete něco takového (velký dík mému příteli Przemku Adamczykovi, který mi tuto knihovnu ukázal).

Vypadá to mnohem čistěji, nemyslíte?

Nejlepší je, že stačí zadat proměnnou podmínky na úrovni komponenty a.
ne na úrovni stylingu. Opravdu to šetří čas. Takové řešení má bohužel i své nevýhody.
SCSS je snadný a přívětivý, ale buďte opatrní při jeho používání s Next.js. Tento framework neumí
umožňují importovat soubory stylů přímo do souboru komponenty (pouze moduly CSS).

Pokud dáváte přednost jednomu souboru pro každou komponentu, musíte vytvořit index.scss obsahující všechny vaše SCSS soubory a
importovat do _app.tsx soubor. Jediným problémem je, že musíte ručně importovat každý SCSS soubor, který jste vytvořili. V React však tento problém neexistuje a můžete importovat SCSS kdekoli chcete. Nechápejte mě špatně. Stylizované součásti jsou opravdu dobré. Jak jsem již řekl, předávání proměnných JS a globální téma jsou úžasné funkce. Pokud vytváříte velkou aplikaci, kde je optimalizace klíčová, tato knihovna pravděpodobně splní vaše potřeby. V našem případě však přechod na SCSS vyhrál jackpot.

Shrnutí

Závěrem lze říci, že ačkoli existují platné argumenty pro obě varianty SCSS a stylizované komponenty na adrese vývoj webových stránek , konečné rozhodnutí závisí na různých faktorech. SCSS nabízí známější syntaxi pro zkušení vývojáři v tradičním CSS a poskytuje bezproblémovou integraci se stávajícími základy kódů a knihovny komponent .

Na druhou stranu, Stylizované součásti nabízejí rozšířenou zkušenosti vývojářů s jeho schopností zapouzdřit styly do komponent a zjednodušit proces stylování. Podporuje také modularitu kódu a jeho opakované použití, což umožňuje front-endu inženýři efektivně spravovat adresář komponent a vytvořit konzistentní UŽIVATELSKÉ ROZHRANÍ napříč webová aplikace . Vzhledem k významu údaje o uživateli bezpečnosti a výkonu, je nezbytné posoudit dopad obou přístupů na konečnou velikost svazku a dobu načítání. V konečném důsledku je třeba se rozhodnout mezi SCSS a stylizované komponenty by měly vycházet z konkrétních potřeb projektu, dovedností a schopností vývojový tým a celkové cíle projektu webová aplikace . Je vhodné, aby vývojáři vyhodnotili všechny faktory, aktualizovali je prostřednictvím příspěvky na blogu a oborových diskusí a učinit informované rozhodnutí, které bude v souladu s jejich požadavky na projekt a zlepší celkový dojem z projektu. front-end proces vývoje .