6 Βέλτιστες Πρακτικές & Συμβουλές κατά τη χρήση γωνιακού CLI

Το μέλλον είναι τώρα ( από τον Sébastien Jermer)
Αποποίηση ευθυνών: Το άρθρο επικεντρώνεται στη γωνιακή CLI έκδοση Λιγότερο από 6.0.0 η οποία κυκλοφόρησε τον Απρίλιο του 2018, όλα είναι λίγο πολύ έγκυρα, το μόνο που άλλαξε είναι οι προεπιλεγμένες σημαίες του build build, παρακαλώ ρίξτε μια ματιά στην επίσημη γωνιακή CLI ng build απόδειξη με έγγραφα.
Ακολουθήστε την έκδοση Butler, ένα bot twitter που δημιούργησα για να σας βοηθήσω να μείνετε ενημερωμένοι με τις απελευθερώσεις των γωνιακών CLI, γωνιακών και πολλών δημοφιλών βιβλιοθηκών frontend ...

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

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

Παρόλο που το Angular CLI λειτουργεί πολύ καλά από το get go, υπάρχουν μερικές πιθανές βελτιώσεις διαμόρφωσης και βέλτιστες πρακτικές που μπορούμε να χρησιμοποιήσουμε για να κάνουμε τα έργα μας ακόμα καλύτερα!

Τι πρόκειται να μάθουμε

  1. Βέλτιστες πρακτικές για την αρχιτεκτονική με βασικές, κοινές και τεμπέλης λειτουργίες
  2. Χρησιμοποιώντας ψευδώνυμα για τους φακέλους εφαρμογών και περιβαλλόντων για την υποστήριξη εισαγωγών καθαρότερων
  3. Γιατί και πώς να χρησιμοποιείτε το Sass και το γωνιακό υλικό
  4. Πώς να ρυθμίσετε την καλή παραγωγή
  5. Πώς να κυλήσει το αντίο PhantomJS και να χρησιμοποιήσει το Chrome χωρίς κεφαλίδες (δοκιμή)
  6. Πώς να απελευθερώσετε το έργο μας με αυτόματα δημιουργημένο changelog και σωστό χτύπημα έκδοσης

1. Ένα κομμάτι της αρχιτεκτονικής

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

Μια καλή κατευθυντήρια γραμμή που πρέπει να ακολουθήσουμε είναι να χωρίσουμε την αίτησή μας σε τουλάχιστον τρεις διαφορετικές ενότητες - Core, Shared και Feature (πιθανώς θα χρειαστούμε περισσότερες από μία λειτουργικές μονάδες εν τούτοις).

CoreModule

Πρέπει να εφαρμοστούν εδώ όλες οι υπηρεσίες που πρέπει να έχουν μόνο μία εμφάνιση ανά εφαρμογή (υπηρεσίες singleton). Χαρακτηριστικό παράδειγμα είναι η υπηρεσία ελέγχου ταυτότητας ή η υπηρεσία χρήστη. Ας δούμε ένα παράδειγμα εφαρμογής του CoreModule.

SharedModule

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

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

Πώς να προετοιμάσετε τη δομή του έργου χρησιμοποιώντας το γωνιακό CLI

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

Εκτελέστε τον κεντρικό πυρήνα της μονάδας. Στη συνέχεια, δημιουργήστε το αρχείο index.ts στον κεντρικό φάκελο και επανεκκινήστε το ίδιο το CoreModule. Θα επανεξαγάγουμε πρόσθετες δημόσιες υπηρεσίες οι οποίες θα πρέπει να είναι διαθέσιμες σε ολόκληρη την εφαρμογή κατά τη διάρκεια της περαιτέρω ανάπτυξής τους.

Αυτό γίνεται, μπορούμε να κάνουμε το ίδιο και για την κοινόχρηστη ενότητα.

FeatureModule

Θα δημιουργήσουμε πολλαπλές λειτουργικές μονάδες για κάθε ανεξάρτητο χαρακτηριστικό της εφαρμογής μας. Οι λειτουργικές μονάδες πρέπει να εισάγουν υπηρεσίες μόνο από το CoreModule. Εάν η λειτουργική μονάδα A χρειάζεται να εισάγει υπηρεσία από τη λειτουργική μονάδα Β, μπορείτε να μετακινήσετε αυτήν την υπηρεσία σε πυρήνα.

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

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

LazyLoading

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

2. Ψευδώνυμα για εφαρμογές και περιβάλλοντα

Η αλλοίωση των φακέλων των εφαρμογών και των περιβαλλόντων θα μας επιτρέψει να εφαρμόσουμε καθαρές εισαγωγές, οι οποίες θα είναι συνεπείς σε όλη την εφαρμογή μας.

Εξετάστε την υποθετική, αλλά συνηθισμένη κατάσταση. Εργαζόμαστε σε ένα στοιχείο το οποίο βρίσκεται τρεις φάκελοι βαθιά σε ένα χαρακτηριστικό A και θέλουμε να εισάγουμε υπηρεσίες από τον πυρήνα που βρίσκεται δύο βάσεις βαθιά. Αυτό θα οδηγούσε στη δήλωση εισαγωγής που έμοιαζε με την εισαγωγή {SomeService} από το "../../../core/subpackage1/subpackage2/some.service".

Σίγουρα δεν είναι η καθαρότερη εισαγωγή ποτέ ...

Και τι είναι ακόμη χειρότερο, κάθε φορά που θέλουμε να αλλάξουμε τη θέση οποιουδήποτε από αυτά τα δύο αρχεία, η δήλωση εισαγωγής θα σπάσει. Συγκρίνετε αυτό με πολύ μικρότερη εισαγωγή {SomeService} από το "@ app / core". Φαίνεται καλύτερα, έτσι δεν είναι;

Για να μπορέσουμε να χρησιμοποιήσουμε ψευδώνυμα, πρέπει να προσθέσουμε τις ιδιότητες baseUrl και διαδρομές στο αρχείο tsconfig.json όπως αυτό ...

Επίσης, προσθέτουμε alias @env για να έχουμε εύκολη πρόσβαση στις μεταβλητές περιβάλλοντος από οπουδήποτε στην εφαρμογή μας χρησιμοποιώντας την ίδια εισαγωγή {environment} από τη δήλωση "@ env / environment". Θα λειτουργήσει για όλα τα καθορισμένα περιβάλλοντα, διότι αυτό θα επιλύσει αυτόματα το σωστό αρχείο περιβάλλοντος που βασίζεται στη σημαία -env που μεταβιβάζεται στην εντολή ng build.

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

Μπορεί να έχετε παρατηρήσει ότι εισάγουμε οντότητες (όπως SomeSingletonService στο παραπάνω παράδειγμα) απευθείας από το @ app / core instead of @ app / core / some-package / some-singleton.service. Αυτό είναι δυνατό χάρη στην επανεξαγωγή κάθε δημόσιας οντότητας στο κύριο αρχείο index.ts. Δημιουργούμε ένα αρχείο index.ts ανά πακέτο (φάκελο) και μοιάζουν με κάτι τέτοιο ...

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

Σε αυτή την περίπτωση θα καταλήξουμε σε κάτι σαν εισαγωγή {SomeService} από το '@ app / shared-feature'. Ομοίως με το πυρήνα, το κοινόχρηστο στοιχείο έχει επίσης πρόσβαση χρησιμοποιώντας το ψευδώνυμο @app.

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

3. Χρησιμοποιώντας το Sass

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

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

Για να χρησιμοποιήσουμε το Sass, πρέπει να δημιουργήσουμε το έργο μας χρησιμοποιώντας νέα γωνιακή CLI ng νέα εντολή με σημαία -style scss. Αυτό ορίζει τις περισσότερες από τις απαραίτητες ρυθμίσεις. Ένα πράγμα που δεν προστίθεται από προεπιλογή είναι το stylePreprocessorOptions με includePaths και μπορούμε να το ορίσουμε με τις υποχρεωτικές τιμές "./" και προαιρετικές "./themes".

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

Όταν χρησιμοποιείτε εφαρμογές Γωνιακού Υλικού, είναι καλή πρακτική να εξάγετε ορισμούς θεμάτων σε χωριστούς φακέλους θεμάτων, ένα θέμα ανά αρχείο.
Παρακολουθήστε με στο Twitter για να λαμβάνετε ειδοποιήσεις σχετικά με τις πιο πρόσφατες αναρτήσεις ιστολογίου και ενδιαφέροντα πράγματα για τα frontend

4. Η κατασκευή "PROD"

Το έργο που παράγεται από το γωνιακό CLI έρχεται μόνο με ένα πολύ απλό script build ng έξω από το κουτί. Για να δημιουργήσουμε αντικείμενα ποιότητας παραγωγής, πρέπει να κάνουμε λίγο κομμάτι της προσαρμογής τους εαυτούς μας.

Προσθέτουμε το "build: prod": "ng build - target production - building optimizer - vendor-chunk" στα πακέτα package.json.

Παραγωγή στόχων

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

  • - περιβάλλον περιβάλλοντος prod -use περιβάλλοντος.prod.ts για μεταβλητές περιβάλλοντος
  • - aaot - ενεργοποίηση της σύνταξης Ahead-of-Time. Αυτό θα γίνει μια προεπιλεγμένη ρύθμιση σε μελλοντικές εκδόσεις του γωνιακού CLI, αλλά προς το παρόν πρέπει να το ενεργοποιήσουμε αυτόματα
  • - εξόφληση όλων των περιεχομένων κατακερματισμού των δημιουργηθέντων αρχείων και προσθήκη του hash στο όνομα του αρχείου για τη διευκόλυνση της απόσπασης της προσωρινής μνήμης του προγράμματος περιήγησης (οποιαδήποτε αλλαγή στο περιεχόμενο του αρχείου θα έχει ως αποτέλεσμα διαφορετικό hash και ως εκ τούτου ο περιηγητής αναγκάζεται να φορτώσει μια νέα έκδοση του αρχείου)
  • --extract-css true - εξαγάγετε όλο το css σε ξεχωριστό αρχείο φύλλου στυλ
  • --sourcemaps false - απενεργοποίηση της δημιουργίας χαρτών προέλευσης
  • --named-chunks false - απενεργοποιήστε τη χρήση αναγνωρίσιμων από το χρήστη ονομάτων για κομμάτια και χρησιμοποιήστε τους αριθμούς αντί

Άλλες χρήσιμες σημαίες

  • --build-optimizer - νέο χαρακτηριστικό που οδηγεί σε μικρότερες δέσμες αλλά πολύ περισσότερο χρόνο κατασκευής γι 'αυτό να χρησιμοποιείτε με προσοχή! (θα πρέπει επίσης να ενεργοποιηθεί από προεπιλογή στο μέλλον)
  • - κομμάτι προμηθευτή - εξαγάγετε τον κώδικα προμηθευτή (βιβλιοθήκη) σε χωριστό κομμάτι

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

5. Phantom JS είναι νεκρό! Ζήτω χωρίς Chrome!

PhantomJS είναι ένα πολύ γνωστό πρόγραμμα περιήγησης χωρίς κεφαλαία το οποίο ήταν defacto Η ΛΥΣΗ για τη διεξαγωγή δοκιμών frontend σε διακομιστές CI και πολλές μηχανές dev.

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

Ευτυχώς, δεν χρειάζεται να το αντιμετωπίζουμε πια!

Αδιάβροχο Chrome - Η δοκιμή του Frontend Renaissance έχει αρχίσει!

Όπως αναφέρει η επίσημη τεκμηρίωση ...

Το headless Chrome μεταφέρεται στο Chrome 59. Είναι ένας τρόπος για να εκτελέσετε το πρόγραμμα περιήγησης Chrome σε περιβάλλον χωρίς κεφαλές. Ουσιαστικά, τρέχοντας το Chrome χωρίς χρώμιο! Φέρνει όλες τις σύγχρονες λειτουργίες πλατφόρμας web που παρέχονται από το Chromium και την μηχανή rendering Blink στη γραμμή εντολών.
Μεγάλος! Πώς μπορούμε να το χρησιμοποιήσουμε στο γωνιακό CLI project;

Προσθέτουμε την -browser ChromeHeadless σημαία στην εντολή δοκιμής μας, έτσι ώστε να καταλήξουμε με "test": "ng test -browser ChromeHeadless - single-run" και "watch": "ng test -browser ChromeHeadless" στο πακέτο μας. json scripts. Αρκετά απλό, χα!

6. Χρησιμοποιήστε τα τυποποιημένα μηνύματα commit & automatic generator changelog

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

Ας δώσουμε στους χρήστες μας την ίδια ευκολία!

Γράφοντας changelog χειροκίνητα θα ήταν εξαιρετικά κουραστικό επιρρεπές σφάλμα καθήκον έτσι είναι το καλύτερο να αυτοματοποιηθεί αυτή η διαδικασία αντ 'αυτού. Υπάρχουν πολλά διαθέσιμα εργαλεία που μπορούν να κάνουν τη δουλειά, αλλά ας επικεντρωθούμε στην βασική έκδοση.

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

Η συμβατική δέσμευση ορίζει τον υποχρεωτικό τύπο, προαιρετικό (πεδίο): ακολουθούμενο από το μήνυμα δέσμευσης. Είναι επίσης δυνατή η προσθήκη προαιρετικού σώματος και υποσέλιδου, και οι δύο χωρίζονται με κενή γραμμή. Ας δούμε πώς φαίνεται αυτό στην πράξη ελέγχοντας ένα παράδειγμα πλήρους μηνύματος commit της βιβλιοθήκης ngx-model.

fix (εξάρτηση): πολλαπλές εκδόσεις rxjs σε ένα έργο (TS90010)
ΔΙΑΚΟΠΗ ΑΛΛΑΓΗΣ: Το rxjs είναι πλέον peerDependency αντί για εξάρτηση
κλείνει # 1

Η βασική έκδοση θα διορθώσει σωστά την MAJOR έκδοση του έργου λόγω της παρουσίας λέξης κλειδιού BREAKING CHANGE στο σώμα της επιτροπής.

Το παραγόμενο CHANGELOG.md θα φανεί κάπως έτσι ....

Παράδειγμα αρχείου CHANGELOG.md που δημιουργείται από βιβλιοθήκη τυπικής έκδοσης

Φαίνεται γλυκό! Πώς μπορούμε να το χρησιμοποιήσουμε στο έργο μας;

Ξεκινάμε με την εγκατάσταση του npm install -D standard-version για να το αποθηκεύσετε στο devDependencies και προσθέστε "release": "standard-version" στα πακέτα package.json.

Μπορούμε επίσης να προσθέσουμε git push και npm publish για να αυτοματοποιήσουμε ολόκληρη τη διαδικασία. Σε αυτή την περίπτωση θα καταλήξουμε σε "απελευθέρωση": "standard-version && git push - follow-tags master && npm publish".

Σημειώστε ότι χρησιμοποιήσαμε && για την αλυσίδα των εντολών μας, η οποία εξαρτάται από την πλατφόρμα και λειτουργεί μόνο σε συστήματα βασισμένα στο Unix (και στα Windows με Cygwin, Gitbash ή νέο υποσύστημα Win10 για Linux).

BONUS: Χρήση της ρίζας πόρων (Intellij IDEA, Webstorm μόνο)

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

Ορίστε το φάκελο src ως Πηγές ρίζας

Μεγάλος! Το φτάσατε στο τέλος!

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

Ξεκινώντας ένα γωνιακό έργο; Ελέγξτε το γωνιακό υλικό εκκίνησης υλικού NgRx!
Γωνιακό υλικό NgRx Starter με ενσωματωμένες βέλτιστες πρακτικές, θέματα και πολλά άλλα!

Επίσης, μπορείτε να ελέγξετε μερικές άλλες ενδιαφέρουσες γωνιακές αναρτήσεις ...

Και δεν ξεχνά ποτέ, το μέλλον είναι λαμπρό
Προφανώς το λαμπρό μέλλον ( από τον Sven Scheuermeier)