book

TypeScript efficace

by Dan Vanderkam

November 2024

Intermediate to advanced

264 pages

7h 6m

French

O'Reilly Media, Inc.

Book available

Read now

Unlock full access

À qui s'adresse ce livrePourquoi j'ai écrit ce livreComment ce livre est organiséConventions dans les échantillons de code TypeScriptConventions typographiques utilisées dans ce livreUtiliser des exemples de codeApprentissage en ligne O'ReillyComment nous contacterRemerciements
Point 1 : comprendre les relations entre TypeScript et JavaScriptPoint 2 : connais les options Typescript que tu utilises.Point 3 : Comprendre que la génération de code est indépendante des typesPoint 4 : se familiariser avec le typage structurelPoint 5 : Limite l'utilisation de n'importe quel type de produit
Point 6 : Utilise ton éditeur pour interroger et explorer le système de typographiePoint 7 : Considère les types comme des ensembles de valeursItem 8 : Savoir dire si un symbole se trouve dans l'espace de type ou l'espace de valeurPoint 9 : Préférer les déclarations de type aux assertions de typePoint 10 : Éviter les types de wrappers d'objets (chaîne, nombre, booléen, symbole, BigInt)Point 11 : Reconnaître les limites du contrôle des biens excédentairesPoint 12 : Appliquer les types à des expressions de fonctions entières lorsque c'est possiblePoint 13 : Connaître les différences entre type et interfacePoint 14 : Utiliser les opérations de type et les génériques pour éviter de se répéterPoint 15 : Utiliser les signatures d'index pour les données dynamiquesPoint 16 : Préférer les tableaux, les n-uplets et les tableaux similaires aux signatures d'index numériquesPoint 17 : Utilise readonly pour éviter les erreurs associées à la mutationPoint 18 : Utiliser les types mappés pour garder les valeurs synchronisées
Point 19 : Évite d'encombrer ton code avec des types inférablesPoint 20 : Utilise des variables différentes pour des types différentsPoint 21 : Élargissement du type de compréhensionPoint 22 : Comprendre le rétrécissement des typesPoint 23 : Créer des objets en une seule foisPoint 24 : Sois cohérent dans ton utilisation des pseudonymesPoint 25 : Utilise des fonctions asynchrones plutôt que des rappels pour le code asynchroneItem 26 : Comprendre comment le contexte est utilisé dans l'inférence de typePoint 27 : Utiliser des constructions fonctionnelles et des bibliothèques pour faciliter le flux des types
Item 28 : Préférer les types qui représentent toujours des états validesPoint 29 : Sois libéral dans ce que tu acceptes et strict dans ce que tu produisPoint 30 : Ne pas répéter les informations de type dans la documentationPoint 31 : Repousse les valeurs nulles à la périphérie de tes typesItem 32 : Préférer les Unions d'Interfaces aux Interfaces d'UnionsPoint 33 : Préférer des alternatives plus précises aux types de chaînes de caractèresItem 34 : Préférer les types incomplets aux types inexactsPoint 35 : Générer des types à partir des API et des spécifications, pas des donnéesItem 36 : Nommer les types en utilisant le langage de ton domaine de problèmesPoint 37 : Envisager des "marques" pour les caractères nominaux
Point 38 : Utiliser le champ d'application le plus étroit possible pour tous les types de produitsItem 39 : Préférer des variantes plus précises de n'importe quel à un simple n'importe quelPoint 40 : Cacher les assertions de type non sûres dans les fonctions bien typéesItem 41 : Comprendre les évolutionsPoint 42 : Utilise inconnu au lieu de quelconque pour les valeurs dont le type est inconnuPoint 43 : Préférer les approches de sécurité de type pour le rapiéçage des singes.Point 44 : Suivre la couverture des types pour éviter les régressions dans la sécurité des types
Point 45 : mettre TypeScript et @types dans les devDependencies.Item 46 : Comprendre les trois versions impliquées dans les déclarations de typePoint 47 : Exporter tous les types qui apparaissent dans les API publiquesPoint 48 : Utiliser TSDoc pour les commentaires sur l'APIPoint 49 : Fournir un type pour cela dans les rappelsPoint 50 : Préférer les types conditionnels aux déclarations surchargéesPoint 51 : Types de miroirs pour supprimer les dépendancesPoint 52 : Sois conscient des pièges des types de tests
Point 53 : Préférer les fonctionnalités d'ECMAScript à celles de TypeScript.Item 54 : Savoir itérer sur les objetsPoint 55 : Comprendre la hiérarchie DOMPoint 56 : Ne compte pas sur le privé pour cacher des informationsPoint 57 : utiliser les cartes de source pour déboguer TypeScript.
Point 58 : Écrire du JavaScript modernePoint 59 : Utilise @ts-check et JSDoc pour expérimenter avec TypeScriptPoint 60 : utilise allowJs pour mélanger TypeScript et JavaScript.Point 61 : Convertir module par module ton graphique de dépendancePoint 62 : Ne considère pas la migration comme terminée tant que tu n'as pas activé noImplicitAny

Content preview from TypeScript efficace

Chapitre 6. Déclarations de types et @types

Cet ouvrage a été traduit à l'aide de l'IA. Tes réactions et tes commentaires sont les bienvenus : translation-feedback@oreilly.com

La gestion des dépendances peut prêter à confusion dans n'importe quel langage, et TypeScript ne fait pas exception. Ce chapitre t'aidera à construire un modèle mental du fonctionnement des dépendances en TypeScript et te montrera comment résoudre certains des problèmes qui peuvent en découler. Il t'aidera également à créer tes propres fichiers de déclaration de type à publier et à partager avec les autres. En écrivant d'excellentes déclarations de type, tu peux aider non seulement ton propre projet, mais aussi l'ensemble de la communauté TypeScript.

Point 45 : mettre TypeScript et @types dans les devDependencies.

Le Node Package Manager, npm, est omniprésent dans le monde JavaScript. Il fournit à la fois un référentiel de bibliothèques JavaScript (le registre npm) et un moyen de spécifier les versions de ces bibliothèques dont tu dépends(package.json).

npm établit une distinction entre quelques types de dépendances, chacune d'entre elles allant dans une section distincte du fichier package.json:

dependencies: Ces sont des paquets qui sont nécessaires à l'exécution de ton JavaScript. Si tu importes lodash au moment de l'exécution, alors cela doit aller dans dependencies. Lorsque tu publies ton code sur npm et qu'un autre utilisateur l'installe, il installera également ces dépendances. (C'est ce qu'on ...