Perché usare SCSS invece dei componenti con stile?

Dopo aver confrontato le soluzioni più diffuse, come i semplici CSS, Emotion, SCSS e Componenti in stileAlla fine ho selezionato l'ultimo. Tutto sembrava andare bene. Ha una libreria molto popolare al giorno d'oggi, il che significa che
c'è già una grande comunità, quindi se dovessi incontrare qualche problema, probabilmente troverei una soluzione da qualche parte su Stack Overflow o GitHub. Oltre a questo, Componenti in stile hanno alcune funzioni di ottimizzazione, il che significa che eseguono il rendering solo quando è necessario. Il progetto era previsto che venisse costruito usando React e Typescript. Questa libreria offre un ottimo supporto per entrambe le tecnologie. Sembra fantastico, vero?

A quel punto ho iniziato a codificare. Dopo un mese, quando l'applicazione è cresciuta, il front-end squadra e io ci siamo concentrati sulla fornitura di funzionalità, abbiamo scoperto che l'incredibile Componenti in stile La biblioteca ha avuto un autogol e vi spiego perché.

Prima di tutto, la convenzione di denominazione. Per differenziare Componenti in stile da componenti React, ho dovuto usare il Stile prefisso che è diminuito codice leggibilità. E poi (cosa forse strana), il supporto di Typescript. Componenti in stilecome forse sapete, si basano sull'approccio CSS-in-JS. Ciò significa che è possibile passare qualsiasi oggetto ad essi e cambiare lo stile, cioè l'input, in base a questo oggetto e personalmente penso che questa caratteristica sia fantastica. In Typescript, si dovrebbe anche implementare il tipo di questo oggetto, in modo da rendere più lungo il codice di ogni Componente stilizzato. "Ma ci vorrebbero altri 5 secondi, quindi qual è il problema?", si potrebbe dire. Avete ragione, anche se quando l'applicazione scala velocemente e il numero di componenti è
aumentando, questi 5 secondi possono essere facilmente moltiplicati per centinaia di volte. Un altro problema è il posizionamento del Componenti in stile.

Alcuni Sviluppatori JS li inseriscono nello stesso file del componente a cui appartengono, mentre altri creano file separati per loro. Entrambi gli approcci sono validi per molte ragioni. Dipende soprattutto dalla complessità del componente. Seguendo una di queste tecniche si può mantenere la coesione, ma unendole si ottiene esattamente il contrario. Abbiamo abbandonato l'approccio CSS-in-JS e siamo migrati a SCSS. Non è stato facile e veloce, ma con un po' di aiuto ce l'abbiamo fatta. Abbiamo iniziato a stilizzare i tag html secondo la metodologia BEM e, naturalmente, abbiamo inserito gli stili in file separati, uno per componente. Ho detto che il passaggio di oggetti JS a Componenti in stile è una funzione fantastica, ma in SCSS è impossibile. Penso che siamo tutti d'accordo sul fatto che la sintassi con cui React vuole codificare le classi condizionali è pessima.

Esiste una soluzione piuttosto interessante. Se si collega la metodologia BEM con la metodologia clsx si otterrà qualcosa di simile a questo (un grande ringraziamento al mio amico Przemek Adamczyk per avermi mostrato questa libreria)

Sembra molto più pulito, non credete?

La cosa migliore è che è sufficiente digitare la variabile di condizione a livello di componente e
non a livello di stile. In questo modo si risparmia davvero tempo. Purtroppo, questa soluzione ha i suoi svantaggi.
SCSS è semplice e amichevole, ma bisogna fare attenzione quando lo si usa con Next.js. Questo framework non
permettono di importare i file di stile direttamente nel file del componente (solo i moduli CSS).

Se si preferisce un file per ogni componente, è necessario creare index.scss contenente tutti i vostri SCSS e
importarlo nella cartella _app.tsx file. L'unico problema è che è necessario importare manualmente ogni file SCSS creato. Nell'React, invece, questo problema non esiste e si può importare il file SCSS file dove si vuole. Non fraintendetemi. Componenti in stile sono davvero ottimi. Come ho già detto, il passaggio di variabili JS e il tema globale sono caratteristiche sorprendenti. Quando si costruisce un'applicazione di grandi dimensioni in cui l'ottimizzazione è fondamentale, questa libreria probabilmente soddisferà le vostre esigenze. Nel nostro caso, però, la migrazione a SCSS ha vinto il jackpot.

Riassunto

In conclusione, sebbene vi siano validi argomenti a favore di entrambi SCSS e componenti stilizzati in sviluppo web La decisione finale dipende da diversi fattori. SCSS offre una sintassi più familiare per sviluppatori esperti in CSS tradizionali e fornisce una perfetta integrazione con i sistemi di basi di codice e librerie di componenti .

D'altra parte, Componenti in stile offrire una maggiore esperienza di sviluppatore con la sua capacità di incapsulare gli stili all'interno dei componenti e di semplificare il processo di styling. Promuove inoltre la modularità e la riutilizzabilità del codice, consentendo agli ingegneri di front-end di gestire in modo efficiente la directory dei componenti e creare un'interfaccia utente coerente in tutto il applicazione web . Considerando l'importanza di dati utente sicurezza e prestazioni, è fondamentale valutare l'impatto di entrambi gli approcci sulle dimensioni finali del bundle e sui tempi di caricamento. In definitiva, la scelta tra SCSS e componenti stilizzati dovrebbe essere basata sulle esigenze specifiche del progetto, sulle competenze del team di sviluppo e gli obiettivi generali del progetto applicazione web . È consigliabile che gli sviluppatori valutino tutti i fattori, restino aggiornati tramite post sul blog e le discussioni di settore, e prendere una decisione informata che sia in linea con i requisiti del progetto e che migliori l'insieme del progetto. processo di sviluppo front-end .