Γιατί το TypeScript είναι ο καλύτερος τρόπος για να γράψετε Front-end το 2019

Και γιατί πρέπει να πείσετε όλους να το χρησιμοποιήσουν.

Το TypeScript γίνεται όλο και πιο δημοφιλές στο περιβάλλον Front-end. Ήδη το 80% των προγραμματιστών παραδέχονται ότι θα ήθελαν να χρησιμοποιήσουν ή να μάθουν το TypeScript στο επόμενο έργο τους. Ο εαυτός μου, το αγάπησα από τη στιγμή που το χρησιμοποίησα για πρώτη φορά. Και θα συνεχίσω να το χρησιμοποιώ σε όλα τα επόμενα έργα μου με βεβαιότητα.

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

Μια ιστορία ενός "δυναμικά πληκτρολογούμενου γλώσσας"

Για τα περισσότερα 18 χρόνια της καριέρας μου στον προγραμματισμό, δεν είχα ποτέ άρεσε στατικά γραπτά γλώσσες. Από τότε που άρχισα να προγραμματίζω το 2001, οι γλώσσες της επιλογής μου ήταν πάντα δυναμικά δακτυλογραφημένες: PHP, JS, Ruby, Elixir. Είχα κάνει κάποια προγράμματα σε C ++ και Java εδώ και εκεί, αλλά πάντα μίσησα αυτά τα περιβάλλοντα. ("Γιατί πρέπει να περάσω τον τύπο παντού; Αυτό είναι χάλια, μπορώ να το φροντίσω εγώ ο ίδιος.")

Όλα άλλαξαν πριν από περίπου 2 χρόνια. Ήταν όταν χρησιμοποίησα το TypeScript για πρώτη φορά. Ωστόσο, δεν είχα ερωτευτεί από την αρχή. Τις πρώτες μέρες ήταν πραγματικά ενοχλητικό για μένα. Η κατάσταση όμως άλλαξε γρήγορα. Όσο περισσότεροι ορισμοί τύπων βάζω στον κώδικα, τόσο πιο συχνά παρατηρούσα ότι με εξοικονομούσε από το να σπαταλάω χρόνο στο χέρι να σφαλίζω τα ανόητα σφάλματα στην κονσόλα. Αρχίζω να εκτιμώ τους τύπους.

Στα επόμενα δύο χρόνια, κάθε φορά που συνεργάζομαι σε εφαρμογές front-end, είτε ήταν Γωνιακή είτε React, παρατήρησα ότι ανεξάρτητα από το πλαίσιο που χρησιμοποιούσα, υπήρχε πάντα αυτό το πράγμα που μου έλειπε σε όλα τα projects .js: TypeScript .

Τώρα πρέπει να παραδεχτώ. Δεν μου αρέσουν πλέον οι δυναμικά δακτυλογραφημένες γλώσσες. Μπορώ ακόμα να δουλέψω πολύ αποτελεσματικά σε αυτά, αλλά με κάνει να δυστυχώς όταν δεν μπορώ απλώς να αναζητήσω ορισμούς τύπων στον IDE ή να εμπιστευτώ τον μεταγλωττιστή ενώ παράλληλα δημιουργώ τον κώδικα. (Το μόνο πράγμα που μου λείπει το Elixir είναι οι ισχυροί τύποι.)

Ευτυχώς, δεν ειναι απαραίτητο να περιμένουμε μέχρι το Ecma TC39 commitee να εισαγάγει σύστημα στατικού τύπου σε JavaScript. Μπορούμε να χρησιμοποιήσουμε το TypeScript αντ 'αυτού. Ειδικά στα νέα έργα, όταν η ταλαιπωρία της χρήσης είναι ελάχιστη.

Αντίγραφα τύπου

Ωστόσο, ορισμένοι εξακολουθούν να τολμούν να υποστηρίξουν ότι η μεταφορά του TypeScript στο έργο σας θα:

  • να αυξήσει τη διάρκεια της επιβίβασης των νέων προγραμματιστών,
  • περιπλέκουν τη συντήρηση,
  • εισάγουν πολλές συγκρούσεις με το React,
  • αύξηση του χρόνου ανάπτυξης,
  • lock-in στο έργο σε κάποια τεχνολογία hipstery που δεν θα υπάρχει σε ένα χρόνο από τώρα,
  • να αποτρέψει την πρόσληψη καλών ανθρώπων JS,
  • καθιστούν αδύνατη την εισαγωγή κώδικα από μη-κωδικούς βάσης TS,
  • καθιστούν δύσκολη την επεξεργασία της εφαρμογής στο μακρινό μέλλον.

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

Αυτός είναι ο λόγος για τον οποίο αποφάσισα να γράψω αυτό το άρθρο. Ίσως θα σας βοηθήσει να πείσετε εσάς, τους φίλους σας, τους συνεργάτες σας ή τον ΚΟΤ σας, σε αυτή την εκπληκτική γλώσσα.

Σημείωση: Δεν θα εξηγήσω "τι είναι το TypeScript" σε αυτό το άρθρο. Θα επικεντρωθώ μόνο στο "γιατί" θα πρέπει να το χρησιμοποιείτε. Εάν δεν είστε ακόμα εξοικειωμένοι με το τι πραγματικά είναι το TypeScript, σας προτείνω να διαβάσετε πρώτα μερικές από τις παρακάτω συνδέσεις:

  • "Τι είναι το TypeScript και γιατί να το χρησιμοποιήσω στη θέση του JavaScript;" - Bogaards του Lodewijk, StackOverflow
  • Ο επίσημος δικτυακός τόπος γλώσσας TypeScript
  • "TypeScript - JavaScript με υπερδυνάμεις" - Indrek Lasn, Medium
  • "Deep Dive TypeScript" - Ηλεκτρονικό βιβλίο από τον Basarat Ali Syed

Τα πλεονεκτήματα του TypeScript

1. Κώδικας πιο κατανοητός

Συνήθως όταν εργάζεστε σε ένα κομμάτι κώδικα, για παράδειγμα ένας κώδικας λειτουργίας, για να το καταλάβετε πλήρως, πρέπει να καταλάβετε:

  1. Ποια επιχειρήματα δέχεται;
  2. Ποια αξία επιστρέφει;
  3. Ποια εξωτερικά δεδομένα απαιτεί;
  4. Τι κάνει με αυτά τα επιχειρήματα και τα εξωτερικά δεδομένα για να παράγει την αξία επιστροφής;

Σε γλώσσες με δυναμική γλώσσα, πολύ συχνά είναι δύσκολο να απαντηθούν οι τρεις πρώτες ερωτήσεις. Εάν μια συνάρτηση λαμβάνει το επιχείρημα του άρθρου, τι ακριβώς είναι αυτό; Είναι ένα αντικείμενο με κάποια ιδιότητες του άρθρου; Ποιες είναι οι ακριβείς ιδιότητες; Υπάρχει article.title ή article.name; Μπορώ πάντα να υποθέσω ότι το άρθρο υπάρχει; Τι λέτε για το article.isPublished; Μπορεί να γνωρίζω ότι αυτό το χαρακτηριστικό συγχωνεύεται στο αντικείμενο του άρθρου στα περισσότερα σημεία της εφαρμογής, αλλά μπορώ να είμαι βέβαιος ότι είναι πάντα παρούσα σε αυτό το σημείο;

Για να απαντήσετε σε όλες αυτές τις ερωτήσεις, συνήθως θα χρειαστεί να κάνετε ένα από τα παρακάτω:

α) βάλτε ένα console.log (άρθρο), εκτελέστε τη δέσμη ενεργειών στο πρόγραμμα περιήγησής σας (ίσως κάντε κλικ μέσα από το περιβάλλον χρήστη) και διαβάστε το αρχείο καταγραφής.

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

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

δ) υποθέστε ότι το άρθρο είναι σαν αυτό που νομίζετε ότι είναι και απλώς ελπίζετε ότι θα λειτουργήσει.

Μήπως αυτό ακούγεται γνωστό σε σας;

Για μένα, αυτό μοιάζει με μια τυπική ροή εργασίας web dev σε οποιαδήποτε δυναμικά πληκτρολογημένη γλώσσα όπως JS, PHP, Ruby, Python, Elixir.

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

2. Κώδικα πιο εύκολη και ταχύτερη στην εφαρμογή

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

  1. Ξεκινήστε την λειτουργία συνιστωσών, δημιουργήστε τα επιχειρήματά της κατασκευαστή, γράψτε τον υπόλοιπο κωδικό.
  2. Εάν απαιτεί εξωτερικά ή εξελιγμένα δεδομένα (όπως χρήστη ή άρθρα), μαντέψτε πώς θα μοιάζει, κρατήστε το στη δική σας μνήμη και χρησιμοποιήστε το όπως και στον κώδικα.
  3. Τοποθετήστε το στοιχείο στην εφαρμογή σας και περάστε στηρίγματα σε αυτό.
  4. Δοκιμάστε το, είτε με το χέρι είτε με δοκιμές μονάδας. (Πρέπει να σιγουρευτείτε ότι λαμβάνει τα στηρίγματα που πρέπει να έχει και ότι λειτουργεί όπως θα έπρεπε να λειτουργήσει.)
  5. Αν κάτι δεν είναι σωστό, επιστρέψτε στον κώδικα σας, προσπαθήστε να υπολογίσετε τι είναι λάθος με αυτό, διορθώστε το και επιστρέψτε στο βήμα αριθ. 4.

Στο TypeScript, είναι παρόμοια, αλλά πιο εύκολη και ταχύτερη:

  1. Ξεκινήστε την λειτουργία συνιστωσών, καθορίστε τον ορισμό του τύπου και εφαρμόστε την.
  2. Αν απαιτεί εξωτερικά ή εξελιγμένα δεδομένα, αναζητήστε τις διεπαφές τους και επαναχρησιμοποιήστε τα (πλήρως ή εν μέρει).
  3. Τοποθετήστε το στοιχείο στην εφαρμογή σας και περάστε στηρίγματα σε αυτό.
  4. Αυτό είναι. (Εάν συμφωνήσατε σωστά τα typedef μεταξύ του καλούντος και του καλούντος, όλα θα πρέπει να λειτουργούν άψογα. Το μόνο πράγμα που πρέπει να δοκιμάσετε τώρα είναι η πραγματική επιχειρησιακή λογική του εξαρτήματος σας.)

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

3. Κωδικός ευκολότερος στο refactor

Υπάρχουν συχνά πολλά πράγματα που θα θέλατε να επαναπροσδιορίσετε, αλλά επειδή αγγίζουν τόσα πολλά πράγματα και αρχεία, φοβάστε απλά να τα αλλάξετε.

Στο TypeScript, τέτοια πράγματα μπορούν συχνά να επαναδιατυπωθούν με ένα μόνο κλικ της εντολής "Rename Symbol" στο IDE.

Μετονομασία

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

Σε στατικώς δακτυλογραφημένες γλώσσες, η Αναζήτηση & Αντικατάσταση δεν είναι πια απαραίτητη. Με εντολές IDE όπως "Εύρεση όλων των συμβάντων" και "Μετονομασία συμβόλου", μπορείτε να δείτε όλες τις εμφανίσεις στην εφαρμογή της δεδομένης συνάρτησης, κλάσης ή ιδιότητας μιας διεπαφής αντικειμένου.

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

4. Λιγότερα σφάλματα

Καθ 'όλη τη διάρκεια πολλών ετών δημιουργίας ιστού στο front-end, έχω παρατηρήσει ότι θα μπορούσα να εξοικονομήσω μέχρι περίπου το 50% του χρόνου μου στο να διορθώσω το σφάλμα κάνοντας κάποιον να κάθεται δίπλα μου που θα μου φωνάζονταν αμέσως κάθε φορά που έκανα τυπογραφικό λάθος μια τιμή που μπορεί να είναι μηδενική ή να περάσει ένα αντικείμενο σε ένα μέρος όπου θα έπρεπε να είναι ένας πίνακας αντί.

Είμαι στην ευχάριστη θέση να πω ότι τελικά συνάντησα αυτό το φίλε: ονομάζεται TypeScript.

Χάρη σε αυτό, είναι πλέον πολύ πιο δύσκολο να γράψετε μη έγκυρο κώδικα. Εάν συντάσσεται, μπορεί να είστε σίγουροι ότι πραγματικά λειτουργεί.

5. Δοκιμές μικρότερης διατομής

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

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

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

6. Κωδικοποιήστε ευκολότερα τη συγχώνευση

Νέος νέος προγραμματιστής στην ομάδα σας έχει μόλις εκδώσει ένα PR που εισάγει νέο κώδικα. Με μια πρώτη ματιά όλα φαίνονται o'right: ο κώδικας φαίνεται καλό, οι δοκιμές μονάδας είναι εκεί, όλα περνούν πράσινα.

Μπορείτε να είστε σίγουροι αυτή τη στιγμή ότι λειτουργεί; Τι γίνεται αν δεν έχει τις κατάλληλες δοκιμές μονάδας; (Ναι, ας συναντήσουμε τους ανθρώπους της πραγματικότητας, πολλοί από εμάς εξακολουθούν να μην γράφουν επαρκή αριθμό από αυτούς.) Θα εμπιστευτείτε μόνο τον δημιουργό του PR; Ή θα εστιάσετε τα πολύτιμα 5 λεπτά για να εκτελέσετε τον κώδικα μόνος του και να το δοκιμάσετε;

Εάν έχετε TypeScript στην εργαλειομηχανή σας, σας δίνει έναν άλλο έλεγχο αξιοπιστίας: τον έλεγχο compilation typedef.

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

Το TypeScript διευκολύνει την εμπιστοσύνη των άλλων προγραμματιστών. Μπορεί να βελτιώσει τον ρυθμό με τον οποίο εξετάζετε και συγχωνεύετε PRs.

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

7. Βοηθά τον προγραμματιστή να έχει τη σωστή ροή εργασίας

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

Πολλοί άνθρωποι θα ποντάρουν στη ζωή τους ότι αυτή είναι η σωστή ροή εργασίας κωδικοποίησης.

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

Ή, όποτε κάνετε TDD, πρέπει πρώτα να σκεφτείτε πώς θα λειτουργήσει ο κώδικας σας στην πραγματικότητα (ποια δεδομένα θα λάβει και ποια δεδομένα θα παράγει), γράψτε ως δοκιμές και, στη συνέχεια, εφαρμόστε τον πραγματικό κώδικα.

Το ίδιο ισχύει για το TypeScript. Σας ενθαρρύνει να σκεφτείτε τη διεπαφή του κώδικα σας προτού καθίσετε στην εσωτερική του εφαρμογή.

Ζητήματα TypeScript

1. "Θα βλάψει την πρόσληψή μας"

Θα το κάνει;

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

https://2018.stateofjs.com/javascript-flavors/typescript/

Η παραπάνω έρευνα το αποδεικνύει: από το 2018, το 80% των πρωτοπόρων προγραμματιστών θα ήθελε να εργαστεί στο TypeScript.

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

2. "Η επιβίβαση στο σκάφος θα διαρκέσει περισσότερο"

Η αλήθεια είναι ότι, αν και το TypeScript είναι ένα υπερσύγχρονο JavaScript, είναι κάτι νέο που όλοι πρέπει να μάθουν. Ένας προγραμματιστής που δεν είναι εξοικειωμένος με την TS θα πρέπει να διαβάσει γι 'αυτό για τουλάχιστον μια ώρα ή δύο, πριν αρχίσει να συνεργάζεται σε ένα τέτοιο έργο.

Αντίθετα όμως, εάν έχετε ένα ήδη κατασκευασμένο έργο στο TypeScript, θα είναι εξαιρετικά εύκολο για τους νέους προγραμματιστές να ταιριάζουν. Το TS Syntax είναι διαισθητικό και πολύ εύκολο στην κατανόηση (που ίσως είναι ο λόγος για τον οποίο έχει γίνει τόσο δημοφιλής). Γενικές διασυνδέσεις λειτουργιών, τύποι φρουρών, τύποι υπό όρους; Δεν θα χρειαστεί ποτέ να αγγίξετε ούτε να καταλάβετε αυτούς στο 99% της καθημερινής εργασίας σας. Το υπόλοιπο 1% είναι συνήθως κάτι που πρέπει να γίνει μόνο στην αρχή, το οποίο μπορεί να προετοιμαστεί από έναν ήδη άπταινο προγραμματιστή TS.

Επιπλέον, χάρη στα πλεονεκτήματα της TS (τα οποία ανέφερα προηγουμένως), θα είναι πιο εύκολο για έναν νέο προγραμματιστή να ξεκινήσει να κάνει πράγματα στο υπάρχον κωδικό σας. Εάν χρειάζεται μόνο να αλλάξει ένα μικρό πράγμα ή να εφαρμόσει κάτι καινούργιο, δεν χρειάζεται να περιηγηθεί σε όλο το codebase πια για να καταλάβει ποια δεδομένα διαβιβάζονται και πού. Μπορεί να το διαβάσει άμεσα στο IDE του και να παίξει γύρω με τα δεδομένα. Ο μεταγλωττιστής TS θα του δώσει άμεση ανατροφοδότηση σχετικά με τις μεταβλητές που χρησιμοποιεί και θα τον καθοδηγήσει κάθε φορά που κάνει κάποιο λάθος.

3. "React / Redux και TS δεν ταιριάζουν μεταξύ τους"

Στοιχείο κουμπιών σε React και TypeScript

Ψευδής. Η TS είχε υποστήριξη TSX από πολύ καιρό. Επίσης, χάρη σε απλούς γενικούς τύπους όπως το React.Component , μπορείτε να απαλλαγείτε από τους PropTypes και να χρησιμοποιήσετε το σύστημα πραγματικού τύπου.

Είναι αλήθεια ότι πριν από περίπου ένα χρόνο ήταν υποχρεωμένος να γράψει ένα κομμάτι κώδικα boilerplate για να κάνει την εργασία TypeScript με δημιουργούς δράσης Redux. Αλλά επειδή το TS 2.8 απελευθερώθηκε τον Φεβρουάριο του 2018, αυτό δεν συμβαίνει πλέον. Μπορείτε να έχετε και δακτυλογραφημένο και απλό κώδικα React / Redux στο TypeScript. Το FYI, το React Contexts ή τα Hooks λειτουργούν άψογα με το TypeScript.

4. "Θα είναι αδύνατο να επαναχρησιμοποιηθεί ο κώδικας JS σε μια εφαρμογή TS"

Και πάλι, ψευδής. Οποιοσδήποτε κωδικός JS είναι ένας έγκυρος κωδικός TS.

Είναι αλήθεια ότι εάν χρησιμοποιείτε TS σε αυστηρή λειτουργία (noImplicitAny), θα πρέπει να προσθέσετε μερικούς τύπους εδώ και εκεί για να κάνετε τον κώδικα JS να λειτουργήσει. Αλλά αυτό είναι! Υπάρχει ακόμη και ένα plugin IDE που μπορεί να μετατρέψει αυτόματα τα εξαρτήματα JS React απευθείας σε TS.

Όταν πρέπει να αντιγράψετε κάποιον περίεργο παλιό πωλητή js lib στο έργο TS σας: απλά το κάνετε. Αν δεν υπάρχουν τυπογραφικές παραλλαγές TS (που συμβαίνει λιγότερο και λιγότερο συχνά τώρα), προσθέστε τους μόνοι τους ή απλώς χρησιμοποιήστε οποιεσδήποτε πληροφορίες κατά την αναφορά στον προμηθευτή. Δεν είναι σαν ξαφνικά να χάσετε ασφάλεια τύπου σε ολόκληρη την εφαρμογή σας. Θα το χάσετε μόνο στο στρώμα που αγγίζει τον πωλητή χωρίς ψήφο. Αλλά αυτό δεν εμποδίζει να πληκτρολογείτε εύκολα το στρώμα σας τουλάχιστον. Και για τον πωλητή, μπορείτε πάντα να προσθέσετε τα typedefs για αυτό αργότερα, όποτε αποφασίσετε ότι θα σας βοηθήσουν επίσης.

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

Το TypeScript χρησιμοποιείται αυτή τη στιγμή από τις Microsoft, Asana, Lyft, Slack, όλους τους προγραμματιστές του Angular 2+, πολλούς προγραμματιστές του React & Vue.js και χιλιάδες άλλες εταιρείες. Πολλοί άλλοι συμμετέχουν καθημερινά. Το TypeScript είναι η πιο δημοφιλής υπερσύγχρονη έκδοση του JS αυτή τη στιγμή και δεν πάει καθόλου σύντομα.

Ποια είναι η πιθανότητα να εγκαταλειφθεί αυτή η γλώσσα;

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

~ 5-10 χρόνια από τώρα μπορεί να είναι μια εποχή στην οποία κανείς δεν ξέρει React, Vue ούτε γωνιακή πια. Αλλά δεν βλέπετε κάποιο πρόβλημα με την προσκόλληση σε αυτά τα πλαίσια; ·)

6. "Τι γίνεται με τη ροή;"

Το TypeScript σας δίνει το ίδιο πράγμα με το Flow και πολλά άλλα. Είναι επίσης πιο δημοφιλές.

Συχνές ερωτήσεις σχετικά με τη ροή δεδομένων κατά τη διάρκεια των τελευταίων 2 ετών (npmtrends.com)

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

Εκ των υστέρων, η Flow ήταν εξίσου δημοφιλής με την TS περίπου πριν από 3 χρόνια, όταν και οι δύο ήταν νέοι παίκτες στην αγορά. Ένας από αυτούς προωθήθηκε από τη Microsoft και την γωνιακή κοινότητα, ενώ ο άλλος προτιμήθηκε από το Facebook και κάποια από την κοινότητα React.

Το TypeScript τελικά κέρδισε. Σήμερα όλο και περισσότεροι προγραμματιστές από όλα τα front-end πλαίσια αλλάζουν σε TypeScript.

Υπάρχουν και άλλες άλλες τυποποιημένες εναλλακτικές λύσεις JS (όπως το PureScript ή Elm), αλλά ας μην τις εξετάσουμε εδώ. Θέλω να μιλήσω για κάτι που έχει ευρεία κοινοτική υποστήριξη και πολλές εταιρείες που την χρησιμοποιούν ήδη στην παραγωγή, όχι μόνο μερικούς χομπίστες. (Λυπάμαι, λαοί.)

TypeScript μειονεκτήματα

1. Απαιτεί ένα βήμα σύνταξης

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

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

Δεν μπορώ να συμφωνήσω σε αυτό στο περιβάλλον Front-end. Όλοι συγκεντρώνουν την JS στο front-end στις μέρες μας. Χρειάζεστε υποστήριξη παλαιού προγράμματος περιήγησης; Χαρακτηριστικά ES7; CSS-in-JS; Για όλα αυτά πιθανότατα έχετε ήδη χρησιμοποιήσει τη βαβέλ. Το TypeScript μπορεί να συνταχθεί με τη Babel, όπως και κάθε άλλη σύνταξη του JS (συμπεριλαμβανομένου του ES7 ή του JSX).

Η προσθήκη του TypeScript στο έργο του front-end δεν φέρνει σχεδόν καθόλου έξοδα για την εγκατάσταση του build. (Μπορεί να φέρει επιβάρυνση μόνο σε περιπτώσεις που δεν συγκεντρώνετε καθόλου το JS σας, αλλά αυτό συμβαίνει πολύ σπάνια στο front-end).

2. Είναι λίγο δύσκολο να ρυθμιστεί

Μπορώ να συμφωνήσω σε αυτό. Για παράδειγμα, ποια είναι η διαφορά μεταξύ μιας εφαρμογής Next.js και μιας εφαρμογής Next.js στο TypeScript; Στη δεύτερη περίπτωση, θα πρέπει να κάνετε το διακομιστή Node.js, το webpack και το jest runner να λειτουργούν με το TypeScript. Επίσης, κάθε φορά που προσθέτετε βιβλιοθήκη όπως το React, Redux, Styled-Components, πρέπει να προσθέσετε typedefs για αυτό, όπως npm i @ types / styled-components (εκτός αν το lib έχει TS typedefs αρχείο που περιλαμβάνεται σε αυτό).

Η ερώτηση που πρέπει να απαντήσετε στον εαυτό σας, πόσο συχνά κάνετε κάτι τέτοιο; Είναι αυτή η μεγάλη προσπάθεια, να είναι άξιος να παραιτηθεί από όλα τα πλεονεκτήματα TypeScript;

Περίληψη

Λέω ότι όλοι μας πρέπει να αλλάξουμε ξαφνικά στο TypeScript; Οχι. Για παράδειγμα, η μετάβαση σε αυτό σε ένα υπάρχον έργο είναι σίγουρα πολλή δουλειά και πρέπει να το σκεφτεί κανείς πριν από αυτό.

Ωστόσο, εάν δημιουργείτε μια νέα εφαρμογή front-end, η οποία θα πρέπει να διατηρηθεί με την πάροδο του χρόνου, η περίπτωση είναι σαφής. Πηγαίνετε με TypeScript. Ειλικρινά, είμαι πρόθυμος να ακούσω ποιοι είναι οι λόγοι για τη μη χρήση της TS σε οποιοδήποτε από τα επόμενα έργα σας.

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

Ας κάνουμε συγγραφείς τύπου Script

Συνδέσεις

Σχετικά με το TypeScript

  • "Τι είναι το TypeScript και γιατί να το χρησιμοποιήσω στη θέση του JavaScript;" - Bogaards του Lodewijk, StackOverflow

"Μετάβαση στο TS" Case Studios

  • "ΤύποςScript στο Lyft" - Mohsen Azimi, Medium
  • "Τύπος σε Slack" - Felix Rieseberg, Medium
  • "Πώς μετεγκαταστάσαμε ένα έργο 200K + LOC στο TypeScript και επιβιώσαμε για να πούμε την ιστορία" - Kleo Petrov, Hashnode
  • "Μετατροπή γραμμών 600Κ σε TypeScript σε 72 ώρες" - Paul Draper & Ryan Stringham, LucidChard TechBlog

Άλλες αναθεωρήσεις του TS

  • "7 κακές δικαιολογίες μη χρήσης του TypeScript" - Dmitry Pashkevich, Medium
  • "Γιατί να χρησιμοποιήσετε το TypeScript, καλοί και κακοί λόγοι" - Charly Poly, Medium
  • "JavaScript vs. TypeScript εναντίον ReasonML" - Δρ. Axel Rauschmayer, 2ality
  • "Typescript - Γιατί πρέπει να το χρησιμοποιήσετε;" - Majid, Medium
  • "Γιατί το TypeScript μεγαλώνει πιο δημοφιλές" - Mary Branscombe, The New Stack