Salut les amis ! C'est moi, Daniel.
Si tu me connais IRL, tu m'as probablement déjà entendu parler longuement de quelque chose en rapport avec JavaScript. Mon premier travail de programmation professionnelle était presque entièrement consacré à Vanilla JavaScript, alors j'aime JS depuis longtemps. Contrairement à d'autres, je trouve ses bizarreries et ses excentricités attachantes. L'héritage prototypique est un peu farfelu au début, mais il est en fait assez simple pour les besoins quotidiens. J'ai vu beaucoup de modes aller et venir (je te regarde, Coffeescript). Cela dit, il m'a fallu beaucoup de temps pour prendre le train Typescript en marche. Mais maintenant que j'y suis ? Je suis TOUT LE MONDE S'EN MÊLE.
I amour Typescript. Tu peux établir des contrats clairement compréhensibles pour tes structures de données, tes fonctions et tes classes, puis les appliquer au moment de la compilation. Cela signifie que si quelqu'un fait un mauvais usage de quelque chose, ou si un contrat ou une interface change, cela est pris en compte avant et de nuire à tes utilisateurs. C'est un code qui explique comment il est censé être utilisé. Qu'est-ce qui ne te plaît pas dans tout ça ? Je pensais déjà à la JS de cette façon, pourquoi ne pas ajouter une couche pour expliquer mes pensées ? Cela brille vraiment pour les équipes ou la transversalité, mais c'est aussi génial pour le futur-moi (après que j'ai dormi et tout oublié).
Nous utilisons Typescript dans mon travail de jour™ mais il n'en a pas toujours été ainsi. Je travaille dans une application qui est mumble-mumble ans avec de nombreuses générations de code - depuis l'époque de React basé sur les classes avec Redux+Thunks jusqu'aux composants fonctionnels plus modernes basés sur React Hooks. C'est comme creuser dans des couches de sédiments rocheux pour découvrir le pourquoi et le comment historiques. Tout ce qui est nouveau est écrit en Typescript et ça fait du bien - mais ça n'a pas aidé quand nous avons dû creuser plus profondément dans les anciennes fonctionnalités (ou *gasp* nettoyer la dette). Alors que nous réalisions la joie d'utiliser nos nouveaux composants (et la douleur d'utiliser les anciens), je voulais y arriver plus rapidement. Je voulais vivre dans le futur, pas dans le passé.
Entrer L'outil incroyablement pratique d'AirBnB, ts-migrate.
Je voulais arriver plus vite. Je voulais vivre dans le futur, pas dans le passé.
Cet outil radical passera en revue l'ensemble de ta base de code, en convertissant tous les éléments de ta base de code. .js(x) fichiers à .ts(x).
Je sais, je sais, c'est un peu sale. Il utilise par défaut le redoutable n'importe laquelle type de données, ce qui est une interdiction préférentielle. Aux endroits où il ne peut pas déterminer comment les types doivent interagir, il insère un commentaire indiquant à Typescript d'ignorer la ligne suivante. Encore une fois, je sais, je sais, ce n'est pas moins sale.
MAIS écoute. Ces fichiers JS se comportent déjà essentiellement de cette façon. Il n'y a pas de types, donc tout est déjà un n'importe laquelle.
Donc, indépendamment de l'irritation, cela présente au moins deux avantages stratégiques immédiats :
- L'intégration de nouveaux composants dans d'anciens composants est maintenant sécurisée. Avant ce changement, ils auraient tout aussi bien pu être du bon vieux JS lorsque nous devions les intégrer dans du vieux code.
- Cela signifie que notre nouveau code Typescript tire vers le haut la qualité de ces anciens fichiers plutôt que les anciens fichiers tirent vers le bas l'ensemble de la base de code.
- Chaque endroit qui nécessite de l'attention pour être vraiment prêt pour Typescript est maintenant marqué par un commentaire ou un n'importe laquelle type de données. Nous essayons de nettoyer tous les vieux fichiers qui sont touchés, un fichier à la fois. L'énumération de l'ampleur d'un problème peut elle-même prendre du temps - avec cette approche, c'est déjà fait.
C'est un code qui explique comment il est censé être utilisé. Qu'est-ce qui ne te plaît pas dans tout ça ?
Je sais qu'une partie de ce sentiment "sale" persistera pour certains d'entre vous, mais je vous le dis - Ta vie en sera améliorée. Le nôtre est définitivement meilleur. Nous avons pu interdire les fichiers JS, ce qui a permis de forcer davantage l'adoption. Nous avons une énumération claire de notre dette JS restante. Et le nettoyage des anciens fichiers est devenu un ajout facile au travail existant plutôt qu'un gâchis insurmontable.
Les avantages l'emportent largement sur les inquiétudes concernant le désordre créé par un processus automatisé. Ce n'était pas clair avant que nous l'utilisions, mais c'est clair comme de l'eau de roche avec le recul. N'est-ce pas toujours le cas ?
Embrasse l'avenir - cela ne prend qu'un peu de temps et tu ne le regretteras pas.
FR 
EN 
ES 
DE 
DE_AT 
IT
C'est une excellente lecture pour tout développeur JS qui hésite à migrer vers TypeScript. Le point de vue honnête des auteurs sur le sentiment sale de la conversion automatisée et la façon dont elle améliore finalement la qualité du code est relatable et inspirant. Je te le recommande vivement !