window.pipedriveLeadboosterConfig = { base: 'leadbooster-chat.pipedrive.com', companyId: 11580370, playbookUuid: '22236db1-6d50-40c4-b48f-8b11262155be', version: 2, } ;(function () { var w = window if (w.LeadBooster) { console.warn('LeadBooster υπάρχει ήδη') } else { w.LeadBooster = { q: [], on: function (n, h) { this.q.push({ t: 'o', n: n, h: h }) }, trigger: function (n) { this.q.push({ t: 't', n: n }) }, } } })() Γιατί θα πρέπει να χρησιμοποιήσετε το SCSS αντί για Styled Components; - The Codest
The Codest
  • Σχετικά με εμάς
  • Υπηρεσίες
    • Ανάπτυξη λογισμικού
      • Ανάπτυξη Frontend
      • Backend Ανάπτυξη
    • Staff Augmentation
      • Frontend Developers
      • Backend Developers
      • Μηχανικοί δεδομένων
      • Μηχανικοί cloud
      • Μηχανικοί QA
      • Άλλα
    • Συμβουλευτική
      • Έλεγχος & Συμβουλευτική
  • Βιομηχανίες
    • Fintech & Τραπεζική
    • E-commerce
    • Adtech
    • Healthtech
    • Κατασκευή
    • Εφοδιαστική
    • Αυτοκίνητο
    • IOT
  • Αξία για
    • CEO
    • CTO
    • Διευθυντής παράδοσης
  • Η ομάδα μας
  • Case Studies
  • Μάθετε πώς
    • Blog
    • Συναντήσεις
    • Διαδικτυακά σεμινάρια
    • Πόροι
Καριέρα Ελάτε σε επαφή
  • Σχετικά με εμάς
  • Υπηρεσίες
    • Ανάπτυξη λογισμικού
      • Ανάπτυξη Frontend
      • Backend Ανάπτυξη
    • Staff Augmentation
      • Frontend Developers
      • Backend Developers
      • Μηχανικοί δεδομένων
      • Μηχανικοί cloud
      • Μηχανικοί QA
      • Άλλα
    • Συμβουλευτική
      • Έλεγχος & Συμβουλευτική
  • Αξία για
    • CEO
    • CTO
    • Διευθυντής παράδοσης
  • Η ομάδα μας
  • Case Studies
  • Μάθετε πώς
    • Blog
    • Συναντήσεις
    • Διαδικτυακά σεμινάρια
    • Πόροι
Καριέρα Ελάτε σε επαφή
Πίσω βέλος GO BACK
2021-10-05
Ανάπτυξη λογισμικού

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

The Codest

Jacek Ludzik

Σχεδιαστής προϊόντων

Τους τελευταίους δύο μήνες εργάζομαι σε ένα έργο για έναν από τους πελάτες μας. Όταν βρισκόμουν στην αρχή, αντιμετώπισα μια επιλογή της βιβλιοθήκης για το styling.

Αφού συγκρίναμε δημοφιλείς λύσεις όπως το απλό 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 για να κωδικοποιήσει τις κλάσεις υπό συνθήκη είναι απαίσια.

κώδικας του react classnames

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

κωδικός clsx

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

Το καλύτερο είναι ότι χρειάζεται να πληκτρολογήσετε μόνο τη μεταβλητή συνθήκης σε επίπεδο συστατικού και
όχι στο επίπεδο του στυλ. Πραγματικά εξοικονομεί χρόνο. Δυστυχώς, μια τέτοια λύση έχει τα μειονεκτήματά της.
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 .

Σχετικά άρθρα

Ανάπτυξη λογισμικού

Η σύγκριση των πρωταθλητών: Angular vs Vue

Επί του παρόντος, υπάρχουν μερικά frontend frameworks που χρησιμοποιούνται συνήθως και αναπτύσσονται συνεχώς από τους δημιουργούς τους, το καθένα ελαφρώς διαφορετικό από το άλλο. Και όμως, μπορεί να έχουν κάτι κοινό. Εδώ...

Oliwia Oremek

Εγγραφείτε στη βάση γνώσεών μας και μείνετε ενήμεροι για την τεχνογνωσία από τον τομέα της πληροφορικής.

    Σχετικά με εμάς

    The Codest - Διεθνής εταιρεία ανάπτυξης λογισμικού με κέντρα τεχνολογίας στην Πολωνία.

    Ηνωμένο Βασίλειο - Έδρα

    • Γραφείο 303B, 182-184 High Street North E6 2JA
      Λονδίνο, Αγγλία

    Πολωνία - Τοπικοί κόμβοι τεχνολογίας

    • Πάρκο γραφείων Fabryczna, Aleja
      Pokoju 18, 31-564 Κρακοβία
    • Πρεσβεία του εγκεφάλου, Konstruktorska
      11, 02-673 Βαρσοβία, Πολωνία

      The Codest

    • Αρχική σελίδα
    • Σχετικά με εμάς
    • Υπηρεσίες
    • Case Studies
    • Μάθετε πώς
    • Καριέρα
    • Λεξικό

      Υπηρεσίες

    • Συμβουλευτική
    • Ανάπτυξη λογισμικού
    • Backend Ανάπτυξη
    • Ανάπτυξη Frontend
    • Staff Augmentation
    • Backend Developers
    • Μηχανικοί cloud
    • Μηχανικοί δεδομένων
    • Άλλα
    • Μηχανικοί QA

      Πόροι

    • Γεγονότα και μύθοι σχετικά με τη συνεργασία με εξωτερικό συνεργάτη ανάπτυξης λογισμικού
    • Από τις ΗΠΑ στην Ευρώπη: Γιατί οι αμερικανικές νεοσύστατες επιχειρήσεις αποφασίζουν να μετεγκατασταθούν στην Ευρώπη
    • Σύγκριση υπεράκτιων κόμβων ανάπτυξης τεχνολογίας: Ευρώπη (Πολωνία), ASEAN (Φιλιππίνες), Ευρασία (Τουρκία)
    • Ποιες είναι οι κορυφαίες προκλήσεις των CTOs και των CIOs;
    • The Codest
    • The Codest
    • The Codest
    • Privacy policy
    • Website terms of use

    Πνευματικά δικαιώματα © 2025 από The Codest. Όλα τα δικαιώματα διατηρούνται.

    elGreek
    en_USEnglish de_DEGerman sv_SESwedish da_DKDanish nb_NONorwegian fiFinnish fr_FRFrench pl_PLPolish arArabic it_ITItalian jaJapanese ko_KRKorean es_ESSpanish nl_NLDutch etEstonian elGreek