Συμβουλές βέλτιστων πρακτικών Sass και εργαλεία για προγραμματιστές

Πολύ όπως το πώς jQuery επανάσταση της βανίλιας JavaScript, Η Sass έχει φέρει επανάσταση στην CSS της βανίλιας. Οι περισσότεροι προγραμματιστές που μαθαίνουν το Sass συμφωνούν ότι δεν θα ήθελαν ποτέ να επιστρέψουν. Πολλοί συμφωνούν επίσης ότι το μεγαλύτερο πρόβλημα με τους νέους προγραμματιστές είναι το τρόπος χρησιμοποιούν το Sass, όχι το ίδιο το Sass.

Έχω καθαρίσει τον ιστό και συνέταξα αυτό το άρθρο βέλτιστες πρακτικές για την εγγραφή του επεκτάσιμου και επαναχρησιμοποιήσιμου κώδικα Sass. Οι προτάσεις προέρχονται από τις δικές μου απόψεις και από αξιόπιστες ιστοσελίδες όπως οι οδηγίες Sass.

Σίγουρα δεν χρειάζεται να εφαρμόσετε όλα αυτά τα χαρακτηριστικά στη ροή εργασίας σας. Αλλά αξίζει τουλάχιστον να διασκεδάσουν αυτές τις ιδέες και να εξετάσουν τα πιθανά οφέλη.

Οργάνωση αρχείων

Το καλύτερο μέρος για να ξεκινήσετε με την ανάπτυξη του Sass είναι η οργάνωση αρχείων. Εάν είστε ήδη σε αρθρωτό κώδικα τότε θα πρέπει να καταλάβετε την αξία των εισαγωγών και των μερών (περισσότερα για αυτά αργότερα).

Αλλά για τώρα απλά ρίξτε μια ματιά σε αυτό το παράδειγμα δομής αρχείου από το DoCSSa. Αναδημιουργήσαμε αυτή τη δομή του αρχείου που μπορείτε να δείτε παρακάτω:

Αυτό είναι μόνο μια πρόταση και είναι ένας από τους πολλούς τρόπους με τους οποίους μπορείτε να οργανώσετε τα αρχεία σας. Μπορείτε να βρείτε άλλες μεθόδους που χρησιμοποιούν διαφορετικές δομές φακέλων όπως “globals” για το SCSS και το “σελίδες” για το συγκεκριμένο SCSS σελίδας.

Ας περάσουμε από αυτό το προτεινόμενο στυλ διοργάνωσης για να εξετάσουμε το σκοπό του κάθε φακέλου:

• / globals - περιέχει αρχεία Sass που εφαρμόζονται σε ολόκληρη την τοποθεσία όπως η τυπογραφία, τα χρώματα και τα πλέγματα
• /συστατικά - περιέχει αρχεία Sass με στυλ συστατικών όπως κουμπιά, πίνακες ή πεδία εισαγωγής
• / τμήματα - περιέχει αρχεία Sass αφιερωμένα σε συγκεκριμένες σελίδες ή περιοχές σε μια σελίδα (μπορεί να λειτουργούν καλύτερα σε συνδυασμό με το / components / folder)
• / utils - περιέχει βοηθητικά προγράμματα τρίτων όπως το Normalize που μπορούν να ενημερωθούν δυναμικά με εργαλεία όπως το Bower.
• main.scss - το πρωτεύον αρχείο Sass στο ριζικό φάκελο που εισάγει όλα τα υπόλοιπα.

Αυτό είναι απλώς ένα βασικό σημείο εκκίνησης και υπάρχει αρκετό περιθώριο για επέκταση με τις δικές σας ιδέες.

Αλλά ανεξάρτητα από το πώς επιλέγετε να οργανώσετε το SCSS σας, είναι σημαντικό να είστε εσείς έχετε κάποια οργάνωση με ξεχωριστό αρχείο (ή φάκελο) για βιβλιοθήκες όπως το Normalize που πρέπει να ενημερωθούν, καθώς και εξαρτήματα σε τμήματα Sass για το έργο σας.

Τα τμήματα Sass είναι ζωτικής σημασίας για τις σύγχρονες βέλτιστες πρακτικές. Αυτά συστήνονται ιδιαίτερα από την ομάδα σχεδιασμού του Zurb και από πολλούς άλλους επαγγελματίες προγραμματιστές frontend.

Ακολουθεί ένα απόσπασμα από την ιστοσελίδα του Sass που εξηγεί τα μέρη:

“Μπορείτε να δημιουργήσετε μερικά αρχεία Sass που περιέχουν μικρά αποσπάσματα CSS που μπορείτε να συμπεριλάβετε σε άλλα αρχεία Sass. Αυτός είναι ένας πολύ καλός τρόπος να να μοντελοποιήσετε το CSS σας και να βοηθήσετε να διατηρήσετε τα πράγματα ευκολότερα. Ένα μερικό είναι απλά ένα αρχείο Sass που ονομάζεται με μια κορυφαία υπογράμμιση. Ίσως να το ονομάσετε κάτι σαν _partial.scss. Η υπογράμμιση επιτρέπει στον Sass να γνωρίζει ότι το αρχείο είναι μόνο ένα μερικό αρχείο και ότι δεν πρέπει να δημιουργηθεί σε ένα αρχείο CSS. Τα τμήματα Sass χρησιμοποιούνται με το @εισαγωγή διευθυντικός.”

Επίσης, ρίξτε μια ματιά σε αυτές τις άλλες θέσεις σχετικά με τη δομή αρχείων Sass:

• Πώς Δομήσα τα Έργα Sass μου
• Αισθητική Sass: Οργάνωση Αρχιτεκτονικής και Στυλ
• Δομές καταλόγου που σας βοηθούν να διατηρήσετε τον κώδικα σας

Στρατηγικές εισαγωγής

Δεν μπορούμε να πούμε αρκετά για την αξία της εισαγωγής Sass και των μερισμάτων. Η οργάνωση κώδικα είναι το κλειδί για να αποκτήσετε μια δομή εισαγωγής και μια ροή εργασίας που λειτουργεί απλά.

Το καλύτερο μέρος για να ξεκινήσετε είναι ένα φύλλο globals που περιέχει εισαγωγές, μεταβλητές και mixins μαζί. Πολλοί προγραμματιστές προτιμούν να διαχωρίζουν μεταβλητές και mixins, αλλά αυτό έρχεται κάτω από τη σημασιολογία.

Λάβετε υπόψη σας ότι υπάρχουν μείγματα έναν τρόπο εισαγωγής, ή μάλλον αντίγραφο, κώδικα Sass. Είναι απίστευτα ισχυρό αλλά δεν πρέπει να το χρησιμοποιείτε “στατικός” κώδικας. Λάβετε υπόψη ότι υπάρχει μια διαφορά μεταξύ mixins, extends και placeholders, τα οποία έχουν τη χρήση τους στην ανάπτυξη του Sass.

Τα Mixins χρησιμοποιούνται καλύτερα με δυναμικές τιμές που μεταφέρονται στο mixin για αλλοιώσεις κώδικα. Για παράδειγμα, ελέγξτε αυτό το Sass mixin που δημιουργεί κλίση φόντου μεταξύ δύο χρωμάτων.

@mixin linearGradient ($ κορυφή, $ κάτω) φόντο: $ κορυφή; / * Παλιά προγράμματα περιήγησης * / background: -moz-linear-gradient (κορυφή, $ κορυφή 0%, κάτω 100%)? / * FF3.6 + / φόντο: -webkit-gradient (γραμμική, αριστερή κορυφή, αριστερό κάτω μέρος, στάση χρωμάτων (0%, κορυφή $), στάση χρώματος (100%, κάτω μέρος))? / * Chrome, Safari4 + * / φόντο: -webkit-γραμμική κλίση (κορυφή, κορυφή $ 0%, κάτω 100%)? / * Chrome10 +, Safari5.1 + * / φόντο: -ο-γραμμική κλίση (κορυφή, κορυφή 0%, κάτω 100%). / * Opera 11.10+ * / φόντο: -ms-γραμμική κλίση (κορυφή, $ κορυφή 0%, κάτω 100%); / * IE10 + * / υπόβαθρο: γραμμική κλίση (προς τα κάτω, $ κορυφή 0%, κάτω 100%). / * W3C * / φίλτρο: progid: DXImageTransform.Microsoft.gradient (startColorstr = "# ffffff", endColorstr = "# 000000", GradientType = 0). / * IE6-9 * /

Το mixin παίρνει δύο τιμές: ένα κορυφαίο χρώμα και ένα κάτω χρώμα. Θα μπορούσατε να γράψετε διαφορετικά mixins για διαφορετικούς τύπους κλίσεων που περιλαμβάνουν 3 ή 4+ διαφορετικά χρώματα. Αυτό σας επιτρέπει να εισάγετε και να κλωνοποιήσετε τον κώδικα mixin ενώ αλλάζετε τις παραμέτρους για προσαρμοσμένες επιλογές.

Το παράδειγμα από τον υπεύθυνο κώδικα μοιάζει με αυτό:

.κουμπί @ περιλαμβάνει γραμμικήΓραμμή (#cccccc, # 666666). 

Σχετικά με το mixin είναι το σύμβολο κράτησης του Sass, το οποίο είναι κυρίως χρήσιμο με την οδηγία επέκτασης. Είναι βέβαια πιο περίπλοκο από τα mixins, αλλά αυτό μπορεί να είναι ένας τρόπος για να συνδυάστε τους επιλογείς χωρίς να ξαναγράψετε τον υπερβολικό κωδικό.

Παρόλο που ο Sass διαθέτει μόνο μία μέθοδο @import, έχω συμπεριλάβει mixins και placeholder για να δείξω την ευελιξία του κώδικα που μπορεί να γραφτεί σε ένα αρχείο αλλά συμπεριλαμβάνεται οπουδήποτε.

Κατά την οικοδόμηση μιας δομής εισαγωγής απλά θυμηθείτε να ακολουθήσετε τις έννοιες της DRY κωδικοποίησης (Do not Repeat Yourself).

Συμβάσεις ονοματολογίας

Οι γενικοί κανόνες για συμβάσεις ονομασίας ισχύουν για μεταβλητές, λειτουργίες και mixins. Όταν ονομάζετε οτιδήποτε στο Sass συνιστάται να κάνετε χρησιμοποιήστε όλα τα πεζά γράμματα με παύλες για διαχωρισμό.

Η σύνταξη κώδικα Sass βασίζεται στην σειρά κανόνων κανόνων CSS. Ακολουθούν μερικές συνιστώμενες βέλτιστες πρακτικές που πρέπει να έχετε κατά νου:

• δύο (2) εσοχές, χωρίς ετικέτες
• ιδανικά, ευρείες γραμμές 80 χαρακτήρων ή λιγότερες
• ουσιαστική χρήση των λευκών χώρων
• χρησιμοποιήστε σχόλια για να εξηγήσετε τις λειτουργίες CSS

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

Αλλά όσον αφορά τις συμβάσεις ονομασίας μπορεί να καταλήξετε σε δύο διαφορετικές δομές: μία για ονόματα Sass και άλλη για ονόματα κλάσεων CSS. Μερικοί προγραμματιστές προτιμούν τις προτάσεις της BEM έναντι των προτάσεων Sass. Κανείς δεν είναι περισσότερο ή λιγότερο σωστός. διαφορετικά με διαφορετικές διαδικασίες λειτουργίας.

Το πρόβλημα είναι ότι το BEM δεν μεταφέρει καλά στις μεταβλητές Sass ή στο mixins επειδή δεν έχουν τη δομή block / element / modifier (BEM). Προσωπικά προτιμώ να χρησιμοποιήσω τις συμβάσεις ονομασίας Sass, αλλά θα μπορούσατε να δοκιμάσετε οτιδήποτε από την camelCase με τη δική σας εσωτερική σύνταξη.

Κατά την οργάνωση των μεταβλητών και των mixins σας συνιστάται να χωρίστε τα ανά κατηγορία και, στη συνέχεια, ταξινομήστε τα με αλφαβητική σειρά. Αυτό καθιστά ευκολότερη την επεξεργασία, επειδή γνωρίζετε ακριβώς πού να βρείτε κάτι.

Για παράδειγμα, για να αλλάξετε ένα χρώμα συνδέσμου θα ανοίξετε το αρχείο μεταβλητών σας (ίσως _variables.scss) και εντοπίστε την ενότητα για μεταβλητές χρώματος. Στη συνέχεια, βρείτε τον σύνδεσμο με το όνομα (σύνδεσμος κεφαλίδας, σύνδεσμος κειμένου, κ.λπ.) και ενημερώστε το χρώμα. Απλός!

Για να πάρετε μια ιδέα για το πώς μπορείτε να διαρθρώσετε έναν πίνακα περιεχομένων για τα αρχεία Sass, ελέγξτε το αρχείο ρυθμίσεων του Foundation.

 // Ίδρυμα Ρυθμίσεων Ιστοτόπων // ----------------------------- // // Πίνακας Περιεχομένων: // // 1 Παγκόσμια // 2. Σημεία διακοπής // 3. Το πλέγμα // 4. Βασική τυπογραφία // 5. Βοηθοί τυπογραφίας ... // 1. Παγκόσμια // --------- $ global-font-size: 100 %; $ σφαιρικό πλάτος: rem-calc (1200); $ global-lineheight: 1.5; // και τα λοιπα

Μια άλλη ονομασία πρακτική σχετίζεται με αντανακλαστικά σημεία διακοπής. Όταν ονομάζετε σημεία διακοπής Sass, προσπαθήστε να αποφύγετε τα συγκεκριμένα ονόματα συσκευών. Είναι καλύτερα να γράφετε ονόματα όπως μικρά, med, lg και xlg επειδή είναι σε σχέση με το άλλο.

Αυτό είναι καλύτερο για τις εσωτερικές σχέσεις μεταξύ των σημείων διακοπής, αλλά και για τις ομάδες όπου οι προγραμματιστές μπορεί να μην γνωρίζουν ποιες συσκευές σχετίζονται μεταξύ τους.

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

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

Αλλά υπάρχει ένα λεπτή γραμμή μεταξύ της ειδικότητας και της συνέλιξης. Η πρακτική θα σας βοηθήσει να βρείτε αυτή τη γραμμή και να γράψετε πιο αξιομνημόνευτα ονόματα καθιστά ευκολότερη την αντιγραφή κώδικα σε άλλα έργα.

Φωτισμός και βρόχος

Αυτές οι δύο τεχνικές Sass είναι πολύ διαφορετικές στη δράση, αλλά και οι δύο έχουν το δυνατότητα να γίνεται κατάχρηση εάν δεν χρησιμοποιείται με αξιοπιστία.

Φωτισμός είναι η διαδικασία του προσθέτοντας τους επιλογείς ενωμένους μεταξύ τους μέσω της εσοχής για να δημιουργήσετε περισσότερη ειδικότητα με λιγότερους κώδικες. Το Sass έχει έναν οδηγό φωλεοποίησης, ο οποίος απεικονίζει παραδείγματα κωδικοποίησης φωλιάσματος σε δράση. Αλλά είναι εύκολο να παρασυρθούμε με τη φωλιά. Εάν είστε υπερβολικός, μπορείτε να καταλήξετε με κώδικα που μοιάζει με αυτό:

...         

Πάρα πολύ συγκεκριμένο και σχεδόν αδύνατο να αντικατασταθεί, αυτός ο τύπος κώδικα καταστρέφει το σκοπό των cascading stylesheets.

Χρησιμοποιώντας τον Οδηγό SitePoint, θα βρείτε τρεις χρυσούς κανόνες για τη φωλιά:

• Ποτέ μην πάτε περισσότερα από 3 επίπεδα βαθιά.
• Βεβαιωθείτε ότι η έξοδος CSS είναι καθαρή και επαναχρησιμοποιήσιμη.
• Χρησιμοποιήστε το φωτισμό όταν έχει νόημα, όχι ως προεπιλεγμένη επιλογή.

Ο προγραμματιστής Josh Broton προτείνει τη φωλιά όταν είναι απαραίτητο, το υπόλοιπο ως γενικό κανόνα σύνταξης.

Η εσοχή των επιλογέων σας δεν θα προκαλέσει τυχόν επικαλυπτόμενα εφέ CSS. Αλλά θα έχετε έναν πιο εύκολο χρόνο να απομακρύνετε το αρχείο Sass σας, προσδιορίζοντας ποιες κλάσεις σχετίζονται μεταξύ τους.

Οι βρόχοι μπορούν επίσης να χρησιμοποιηθεί υπερβολικά εάν δεν εφαρμοστεί σωστά. Οι τρεις βρόχοι Sass είναι @Για, @ενώ, και @καθε. Δεν θα μπω σε λεπτομέρειες για το πώς όλοι δουλεύουν, αλλά αν σας ενδιαφέρει δείτε αυτό το post.

Αντ 'αυτού θα ήθελα να καλύψω το σκοπό για τη χρήση βρόχων και πώς λειτουργούν στο Sass. Αυτά θα πρέπει να χρησιμοποιούνται για να εξοικονομήσετε χρόνο κώδικα που μπορεί να αυτοματοποιηθεί. Για παράδειγμα, εδώ είναι ένα απόσπασμα κώδικα από την ανάρτηση του Clubmate που δείχνει κάποιο κώδικα Sass που ακολουθείται από την έξοδο:

/ * Κωδικός Sass * / @ για $ i από 1 έως 8 $ width:% (1 / $ i) .col - # $ i width: $ width;  / * εξόδου * / .col-1 πλάτος: 100%; .col-2 πλάτος: 50%; .col-3 πλάτος: 33.333% .col-4 πλάτος: 25%;  .col-5 πλάτος: 20% · .col-6 πλάτος: 16.666% · .col-7 πλάτος: 14.285% .col-8 πλάτος: 12.5%

Αυτές οι κατηγορίες στήλης μπορούν να χρησιμοποιηθούν σε συνδυασμό με ένα σύστημα πλέγματος. Θα μπορούσατε ακόμη να προσθέσετε περισσότερες στήλες ή να αφαιρέσετε κάποιες μόνο με την επεξεργασία του κώδικα βρόχου.

Βρόχους πρέπει δεν να χρησιμοποιηθεί για την αντιγραφή επιλογών ή ιδιοτήτων για έναν επιλογέα. αυτό είναι που mixins για.

Επίσης, όταν βρόχο υπάρχει κάτι που ονομάζεται Sass χάρτες που αποθηκεύουν κλειδί: αξία ζεύγη δεδομένων. Οι προηγμένοι χρήστες θα πρέπει να επωφεληθούν από αυτές όποτε είναι δυνατόν.

Αλλά οι κανονικοί βρόχοι Sass είναι απλοί και αποτελεσματικοί στην παροχή εξόδου κώδικα χωρίς επανάληψη. Ο καλύτερος λόγος για τη χρήση βρόχων είναι με Ιδιότητες CSS που μεταβάλλουν την έξοδο δεδομένων.

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

Εάν είστε ποτέ μπερδεμένοι ή θέλετε ανατροφοδότηση σχετικά με τις θύλακες φωτισμού ή Sass, θα πρέπει να δημοσιεύσετε μια ερώτηση είτε σε / r / sass / ή / r / css /, ενεργές κοινότητες Reddit με πολύ ενημερωμένους προγραμματιστές Sass.

Μοντελοποίηση

Η πρακτική της συγγραφής αρθρωτών Sass είναι απόλυτη ανάγκη για τα περισσότερα έργα (θα υποστήριζα, κάθε έργο). Η τυποποίηση είναι η διαδικασία του καταργώντας ένα έργο σε μικρότερες ενότητες. Αυτό μπορεί να επιτευχθεί με τη χρήση του Sass μερικά.

Η ιδέα του αρθρωτού Sass είναι να γράφει ξεχωριστά αρχεία SCSS με συγκεκριμένο σκοπό που στοχεύει σε παγκόσμιο περιεχόμενο (τυπογραφία, πλέγματα) ή στοιχεία σελίδας (καρτέλες, φόρμες).

Ο ορισμός της μονάδας Sass είναι αρκετά σαφής και κάνει μια πολύ συγκεκριμένη πρόταση: η εισαγωγή μιας ενότητας δεν πρέπει ποτέ να εξάγει κώδικα.

Η ιδέα της υποχρεωτικής παραγωγής για όλες τις ενότητες θα ήταν ένας εφιάλτης για βελτιστοποίηση. Αντ 'αυτού θα πρέπει να δημιουργήσετε μονάδες μεμονωμένα και καλέστε μόνο αυτά που χρειάζεστε. Οι ενότητες μπορούν να οριστούν από mixins ή λειτουργίες, αλλά είναι δυνατή η δημιουργία μονάδων που περιέχουν και επιλογείς.

Ωστόσο, ένα άρθρο Sass Way προτείνει να γράψετε όλους τους επιλογείς ως mixins και να τους καλείτε όποτε είναι απαραίτητο. Είτε υιοθετήσετε αυτό είτε όχι, είναι τελικά η επιλογή σας. Νομίζω ότι εξαρτάται από το μέγεθος του έργου και την άνεση σας με το χειρισμό mixins.

Αναφερόμενος στον John Long από τη θέση του στο The Sass Way:

“Για μένα, οι ενότητες έχουν γίνει οι βασικές μονάδες ή τα δομικά στοιχεία των έργων μου Sass.”

Εάν πραγματικά ψάχνετε για μια ρουτίνα Sass σας συνιστώ να πηγαίνετε πλήρως αρθρωτό. Δοκιμάστε να οικοδομήσετε σχεδόν τα πάντα ως ένα αρθρωτό τμήμα που συμπεριλαμβάνεται σε ένα κύριο αρχείο CSS. Στην αρχή αυτή η ροή εργασίας μπορεί να φανεί τρομακτική, αλλά έχει νόημα σε μεγαλύτερη κλίμακα - ειδικά με μεγάλα έργα.

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

Για να μάθετε περισσότερα σχετικά με τις λειτουργικές μονάδες Sass και τις τεχνικές μοντελοποίησης, δείτε αυτές τις αναρτήσεις:

• Ενότητες CSS: Καλώς ήλθατε στο μέλλον
• Τα πλεονεκτήματα και τα μειονεκτήματα της Modular Sass
• Αρθρωτός οργανισμός CSS με SMACSS & SASS

Βρείτε την τέλεια ροή εργασιών σας

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

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

Απελευθερώστε τις βιβλιοθήκες του Open Source όπως το SCSS του Foundation στο GitHub για να μάθετε περισσότερα σχετικά με τις βέλτιστες πρακτικές που χρησιμοποιούνται από άλλες βιβλιοθήκες.

Το θέμα των βέλτιστων πρακτικών είναι ότι βελτιώνουν πραγματικά την εργασία σας τις περισσότερες φορές, αλλά υπάρχουν πολλές εναλλακτικές λύσεις. Απλά δοκιμάστε τα πράγματα και δείτε πώς αισθάνονται. Θα μάθετε πάντα, έτσι ώστε οι βέλτιστες πρακτικές σας να αλλάξουν γρήγορα κατά τη διάρκεια των 5 ετών.

Μια τελευταία πρόταση που έχω για όλη τη διαδικασία Sass είναι να να λαμβάνουν αποφάσεις με σαφήνεια. Γράψτε κώδικα που διευκολύνει την εργασία σας. Μην περιπλέξετε υπερβολικά ένα έργο εάν υπάρχει ένας απλούστερος τρόπος για να το κάνετε.

Το Sass έχει σκοπό να ενισχύσει την εμπειρία ανάπτυξης CSS, έτσι εργασία με σαφήνεια και βέλτιστες πρακτικές για να έχετε την καλύτερη δυνατή εμπειρία.

Τύλιξε

Η συμφόρηση σε μια ροή εργασίας του Sass μπορεί να διορθωθεί με στυλ κώδικα μικροαλλαγής και ακολουθώντας τις βέλτιστες πρακτικές. Έχω περιγράψει μια χούφτα των προτάσεων σε αυτό το post που δίνεται από τα blogs Sass και επαγγελματίες προγραμματιστές.

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

Ελέγξτε αυτές τις συνδέσεις για να βρείτε περισσότερες συμβουλές και βέλτιστες πρακτικές για την ανάπτυξη του Sass:

• Οδηγίες Sass
• Ένα όραμα για το Sass
• 8 συμβουλές για να σας βοηθήσουν να απολαύσετε το καλύτερο από το Sass
• Επέκταση σε Sass χωρίς να δημιουργήσετε ένα χάος
• Βέλτιστες πρακτικές Sass - Βάζοντας πάνω από 3 επίπεδα βαθιά