Kāpēc jums vajadzētu izmantot SCSS, nevis stilizētus komponentus?

Pēc populāru risinājumu, piemēram, vienkārša CSS, Emotion, salīdzināšanas, SCSS un Stilizēti komponenti, es beidzot izvēlējos pēdējo. Šķita, ka viss ir kārtībā. Mūsdienās tai ir ļoti populāra bibliotēka, kas nozīmē, ka
tur jau ir liela kopiena, tāpēc, ja man rastos kādas problēmas, es, iespējams, atradīšu risinājumu kaut kur Stack Overflow vai GitHub. Bez tam, Stilizēti komponenti ir dažas optimizācijas funkcijas, kas nozīmē, ka tās tiek atveidotas tikai tad, kad tas ir nepieciešams. Portāls projekts bija paredzēts būvēt, izmantojot React un Mašīnraksts. Šī bibliotēka nodrošina lielisku atbalstu abām tehnoloģijām. Izklausās lieliski, vai ne?

Tad es sāku kodēt. Pēc mēneša, kad lietotne bija izaugusi, frontend komanda un es koncentrējāmies uz funkciju nodrošināšanu, mēs atklājām, ka pārsteidzošā Stilizēti komponenti bibliotēkai bija savi mērķi, un es jums pastāstīšu, kāpēc.

Pirmkārt, nosaukuma piešķiršanas konvencija. Lai nošķirtu Stilizēti komponenti no React komponenti, man bija jāizmanto Stilizēts priedēklis, kas samazinājās kods lasāmība. Tad (kas varētu būt dīvaini), Typescript atbalsts. Stilizēti komponenti, kā jūs, iespējams, zināt, ir balstīta uz CSS-in-JS pieeju. Tas nozīmē, ka jūs varat tām nodot jebkuru rekvizītu un mainīt stilu, t. i., ievades stilu, pamatojoties uz šo rekvizītu, un es personīgi uzskatu, ka šī funkcija ir lieliska. In Typescript, jums vajadzētu arī īstenot šo prop tips padara to kods ilgāk jebkuru Stilizēts komponents. “Bet tas aizņemtu vēl 5 sekundes, kāda ir jūsu problēma?” - jūs varētu teikt. Jums ir taisnība, lai gan, ja lietojumprogramma ātri mērogojas un komponentu skaits ir
palielinot šo 5 sekunžu skaitu, to var viegli reizināt simtiem reižu. Vēl viena problēma ir izvietojums Stilizēti komponenti.

Daži JS izstrādātāji tos ievieto vienā failā ar komponentu, kuram tie pieder, bet citi tiem izveido atsevišķus failus. Abas pieejas ir labas daudzu iemeslu dēļ. Tas galvenokārt ir atkarīgs no komponenta sarežģītības. Ievērojot vienu no šīm metodēm, var saglabāt kohēziju, bet to apvienošana dod tieši pretēju rezultātu. Mēs atteicāmies no CSS-in-JS pieejas un pārgājām uz SCSS. Tas nebija viegli un ātri, bet ar nelielu palīdzību mums tas izdevās. Mēs sākām veidot html tagus BEM metodoloģijā un, protams, ielikām stilus atsevišķos failos, pa vienam katram komponentam. Es teicu, ka JS rekvizītu nodošana Stilizēti komponenti ir lieliska funkcija, bet SCSS tas nav iespējams. Es domāju, ka mēs visi esam vienisprātis arī par to, ka React pieprasītā nosacījuma klašu kodēšanas sintakse ir briesmīga.

Ir viens diezgan interesants risinājums. Ja jūs savienojat BEM metodoloģiju ar clsx bibliotēku, jūs iegūsiet kaut ko līdzīgu (liels paldies manam draugam Pšemekam Adamčikam par šīs bibliotēkas parādīšanu).

Izskatās daudz tīrāk, vai ne?

Vislabākais ir tas, ka nosacījuma mainīgais ir jāievada tikai komponenta līmenī un
ne stila līmenī. Tas patiešām ietaupa laiku. Diemžēl šādam risinājumam ir arī trūkumi.
SCSS ir vienkāršs un ērts, taču, lietojot to kopā ar Next.js, jābūt uzmanīgiem. Šis ietvars nav
ļauj importēt stila failus tieši komponenta failā (tikai CSS moduļi).

Ja vēlaties, lai katram komponentam būtu viens fails, jums ir jāizveido index.scss kurā ir visi jūsu SCSS failus un
importēt to _app.tsx failu. Vienīgā problēma ir tā, ka jums ir manuāli jāimportē katrs SCSS izveidoto failu. Tomēr React šī problēma nepastāv, un jūs varat importēt SCSS failus, kur vien vēlaties. Nesaprotiet mani nepareizi. Stilizēti komponenti ir patiešām labi. Kā jau teicu iepriekš, JS mainīgo nodošana, kā arī globālā tēma ir pārsteidzošas funkcijas. Ja veidojat lielu lietojumprogrammu, kurā optimizācija ir ļoti svarīga, šī bibliotēka, iespējams, apmierinās jūsu vajadzības. Tomēr mūsu gadījumā migrācija uz SCSS trāpīja džekpotu.

Rezumējot

Nobeigumā jāsecina, ka, lai gan ir pamatoti argumenti par labu gan SCSS un stilizēti komponenti vietnē tīmekļa izstrāde , galīgais lēmums ir atkarīgs no dažādiem faktoriem. SCSS piedāvā pazīstamāku sintaksi pieredzējuši izstrādātāji tradicionālajā CSS un nodrošina nevainojamu integrāciju ar esošo kodu bāzes un komponentu bibliotēkas .

No otras puses, Stilizēti komponenti piedāvā uzlabotu izstrādātāja pieredze ar tās spēju iekapsulēt stilus komponentos un vienkāršot stilizēšanas procesu. Tas arī veicina koda modularitāti un atkalizmantojamību, ļaujot front-end inženieri efektīvi pārvaldīt komponentu katalogs un izveidot konsekventu lietotāja interfeisu visā tīmekļa vietne lietotne . Ņemot vērā nozīmi lietotājs dati drošību un veiktspēju, ir būtiski novērtēt abu pieeju ietekmi uz galīgo paketes lielumu un ielādes laiku. Galu galā izvēle starp SCSS un stilizēti komponenti jābalstās uz projekta īpašajām vajadzībām, prasmēm, kas nepieciešamas, lai izstrādes komanda , un vispārējiem mērķiem, kas izvirzīti tīmekļa lietojumprogramma . Izstrādātājiem ir ieteicams izvērtēt visus faktorus, atjaunināt informāciju, izmantojot emuāra ieraksti un nozares diskusijām, un pieņemt pamatotu lēmumu, kas atbilst viņu projekta prasībām un uzlabo vispārējo kvalitāti. front-end izstrādes process .