Γιατί θα πρέπει να χρησιμοποιήσετε το SCSS αντί για Styled Components;

Αφού συγκρίναμε δημοφιλείς λύσεις όπως το απλό CSS, το Emotion, SCSS και Στοιχεία με στυλ, επέλεξα τελικά το τελευταίο. Όλα φαίνονταν να είναι εντάξει. Έχει μια πολύ δημοφιλή βιβλιοθήκη σήμερα, πράγμα που σημαίνει
υπάρχει ήδη μια μεγάλη κοινότητα, οπότε αν αντιμετωπίσω κάποιο πρόβλημα, θα βρω πιθανώς μια λύση κάπου στο Stack Overflow ή στο GitHub. Εκτός από αυτό, Στοιχεία με στυλ διαθέτουν ορισμένα χαρακτηριστικά βελτιστοποίησης που σημαίνουν ότι αποδίδουν μόνο όταν χρειάζονται. Το έργο αναμενόταν να κατασκευαστεί με τη χρήση του React και της Typescript. Αυτή η βιβλιοθήκη έχει μεγάλη υποστήριξη και για τις δύο τεχνολογίες. Ακούγεται φοβερό, σωστά;

Τότε άρχισα να κωδικοποιώ. Μετά από ένα μήνα, όταν η εφαρμογή μεγάλωσε, το frontend ομάδα και εγώ επικεντρώθηκα στην παροχή λειτουργιών, ανακαλύψαμε ότι η καταπληκτική Στοιχεία με στυλ Η βιβλιοθήκη είχε το δικό της στόχο και θα σας πω γιατί.

Πρώτα απ' όλα, η σύμβαση ονοματοδοσίας. Για να διαφοροποιήσετε Στοιχεία με στυλ από εξαρτήματα React, έπρεπε να χρησιμοποιήσω το Styled πρόθεμα το οποίο μειώθηκε κωδικός αναγνωσιμότητα. Στη συνέχεια (αυτό που μπορεί να είναι παράξενο), υποστήριξη Typescript. Στοιχεία με στυλ, όπως ίσως γνωρίζετε, βασίζονται στην προσέγγιση CSS-in-JS. Αυτό σημαίνει ότι μπορείτε να περάσετε οποιοδήποτε prop σε αυτά και να αλλάξετε το στυλ, π.χ., της εισόδου με βάση αυτό το prop και προσωπικά πιστεύω ότι αυτό το χαρακτηριστικό είναι φοβερό. Στην Typescript, θα πρέπει επίσης να υλοποιήσετε τον τύπο αυτού του prop καθιστά τον κώδικα πλέον οποιοδήποτε Στοιχείο με στυλ. "Αλλά θα χρειαζόταν 5 δευτερόλεπτα ακόμα, οπότε ποιο είναι το πρόβλημά σας;" - θα μπορούσατε να πείτε. Έχετε δίκιο, αν και όταν η εφαρμογή κλιμακώνεται γρήγορα και ο αριθμός των στοιχείων είναι
αυξάνοντας, αυτά τα 5 δευτερόλεπτα μπορούν εύκολα να πολλαπλασιαστούν εκατοντάδες φορές. Ένα άλλο πρόβλημα είναι η τοποθέτηση του Στοιχεία με στυλ.

Μερικά Προγραμματιστές JS τα τοποθετούν στο ίδιο αρχείο με το στοιχείο στο οποίο ανήκουν, ενώ άλλοι δημιουργούν ξεχωριστά αρχεία γι' αυτά. Και οι δύο προσεγγίσεις είναι καλές για πολλούς λόγους. Εξαρτάται κυρίως από την πολυπλοκότητα του συστατικού. Ακολουθώντας μία από αυτές τις τεχνικές μπορεί να διατηρηθεί η συνοχή, αλλά η συγχώνευσή τους δίνει ακριβώς το αντίθετο. Παραιτηθήκαμε από την προσέγγιση CSS-in-JS και μεταβήκαμε στο SCSS. Δεν ήταν εύκολο και γρήγορο, αλλά με λίγη βοήθεια τα καταφέραμε. Ξεκινήσαμε να διαμορφώνουμε τις ετικέτες html με τη μεθοδολογία BEM και, φυσικά, τοποθετήσαμε τα στυλ σε ξεχωριστά αρχεία, ένα ανά στοιχείο. Είπα ότι το πέρασμα των JS props σε Στοιχεία με στυλ είναι ένα φοβερό χαρακτηριστικό, αλλά στο SCSS είναι αδύνατον. Νομίζω ότι όλοι συμφωνούμε επίσης ότι η σύνταξη που θέλει το React για να κωδικοποιήσει τις κλάσεις υπό συνθήκη είναι απαίσια.

Λοιπόν, υπάρχει μια αρκετά ενδιαφέρουσα λύση. Αν συνδέσετε τη μεθοδολογία BEM με τη clsx βιβλιοθήκη, θα έχετε κάτι σαν αυτό (ένα μεγάλο μπράβο στον φίλο μου Przemek Adamczyk που μου έδειξε αυτή τη βιβλιοθήκη)

Φαίνεται πολύ πιο καθαρό, δεν νομίζετε;

Το καλύτερο είναι ότι χρειάζεται να πληκτρολογήσετε μόνο τη μεταβλητή συνθήκης σε επίπεδο συστατικού και
όχι στο επίπεδο του στυλ. Πραγματικά εξοικονομεί χρόνο. Δυστυχώς, μια τέτοια λύση έχει τα μειονεκτήματά της.
SCSS είναι εύκολο και φιλικό, αλλά να είστε προσεκτικοί όταν το χρησιμοποιείτε με το Next.js. Αυτό το πλαίσιο δεν
επιτρέπει την εισαγωγή αρχείων στυλ απευθείας στο αρχείο συστατικού (μόνο CSS Modules).

Αν προτιμάτε ένα αρχείο ανά στοιχείο, πρέπει να δημιουργήσετε index.scss που περιέχει όλα τα SCSS αρχεία και
να το εισάγετε στο _app.tsx αρχείο. Το μόνο πρόβλημα είναι ότι πρέπει να εισάγετε χειροκίνητα κάθε SCSS αρχείο που δημιουργήσατε. Στο React, ωστόσο, αυτό το πρόβλημα δεν υπάρχει και μπορείτε να εισάγετε SCSS αρχεία όπου θέλετε. Μην με παρεξηγήσετε. Στοιχεία με στυλ είναι πραγματικά καλά. Όπως είπα και προηγουμένως, το πέρασμα μεταβλητών JS καθώς και το παγκόσμιο θέμα είναι εκπληκτικά χαρακτηριστικά. Όταν κατασκευάζετε μια μεγάλη εφαρμογή όπου η βελτιστοποίηση είναι ζωτικής σημασίας, αυτή η βιβλιοθήκη πιθανώς θα ικανοποιήσει τις ανάγκες σας. Στην περίπτωσή μας όμως, η μετάβαση σε SCSS χτύπησε το τζάκποτ.

Συνοψίζοντας

Εν κατακλείδι, ενώ υπάρχουν βάσιμα επιχειρήματα και για τις δύο SCSS και Styled Components στο ανάπτυξη ιστοσελίδων , η τελική απόφαση εξαρτάται από διάφορους παράγοντες. SCSS προσφέρει μια πιο οικεία σύνταξη για έμπειροι προγραμματιστές στο παραδοσιακό CSS και παρέχει απρόσκοπτη ενσωμάτωση με τις υπάρχουσες βάσεις κώδικα και βιβλιοθήκες συστατικών .

Από την άλλη πλευρά, Στοιχεία με στυλ προσφέρουν ενισχυμένη εμπειρία προγραμματιστή με την ικανότητά του να ενθυλακώνει στυλ μέσα σε συστατικά και να απλοποιεί τη διαδικασία διαμόρφωσης. Προωθεί επίσης την αρθρωτότητα και την επαναχρησιμοποίηση του κώδικα, επιτρέποντας στους μηχανικούς front-end να διαχειρίζονται αποτελεσματικά το Κατάλογος εξαρτημάτων και να δημιουργήσετε συνεπές UI σε όλο το διαδικτυακή εφαρμογή . Λαμβάνοντας υπόψη τη σημασία της δεδομένα χρήστη ασφάλειας και απόδοσης, είναι ζωτικής σημασίας να αξιολογηθεί ο αντίκτυπος και των δύο προσεγγίσεων στο τελικό μέγεθος της δέσμης και στους χρόνους φόρτωσης. Τελικά, η επιλογή μεταξύ SCSS και Styled Components θα πρέπει να βασίζεται στις ειδικές ανάγκες του έργου, στις δεξιότητες του ομάδα ανάπτυξης , και τους γενικούς στόχους του διαδικτυακή εφαρμογή . Είναι σκόπιμο για τους προγραμματιστές να αξιολογούν όλους τους παράγοντες, να ενημερώνονται μέσω αναρτήσεις στο ιστολόγιο και τις συζητήσεις του κλάδου, και να λάβουν μια τεκμηριωμένη απόφαση που ευθυγραμμίζεται με τις απαιτήσεις του έργου τους και ενισχύει τη συνολική διαδικασία ανάπτυξης front-end .