React et TypeScript sont deux technologies impressionnantes utilisées par de nombreux développeurs de nos jours. Savoir comment faire peut devenir délicat, et parfois il est difficile de trouver la bonne réponse. Ne pas s'inquiéter. Nous avons rassemblé les meilleures pratiques ainsi que des exemples pour clarifier les doutes que vous pourriez avoir.

Plongeons-nous!

Comment React et TypeScript fonctionnent ensemble

Avant de commencer, revoyons comment React et TypeScript fonctionnent ensemble . React est une «bibliothèque JavaScript pour la création d'interfaces utilisateur», tandis que TypeScript est un «sur-ensemble typé de JavaScript qui se compile en JavaScript simple». En les utilisant ensemble, nous construisons essentiellement nos interfaces utilisateur à l'aide d'une version typée de JavaScript.

La raison vous pourriez les utiliser ensemble serait d'obtenir les avantages d'un langage de type statique (TypeScript) pour votre interface utilisateur. Cela signifie plus de sécurité et moins de bogues à expédier au front-end.

Est-ce que TypeScript compile mon code React?

Une question courante qu'il est toujours bon d'examiner est de savoir si TypeScript compile votre code React. Le fonctionnement de TypeScript est similaire à cette interaction:

TS : "Hé, est-ce tout votre code d'interface utilisateur?"
React : "Ouaip!"
TS : "Cool! Je vais le compiler et m'assurer que vous n'avez rien manqué. "
Réagissez :" Ça me semble bien! "

Donc la réponse est oui, c'est le cas! Mais plus tard, lorsque nous couvrirons les paramètres tsconfig.json la plupart du temps, vous voudrez utiliser "noEmit": true . Cela signifie que TypeScript n'émettra pas JavaScript après la compilation. En effet, nous utilisons généralement TS pour faire notre TypeScript.

La sortie est gérée, dans un paramètre CRA, par react-scripts . Nous exécutons yarn build et react-scripts regroupe la sortie pour la production.

Pour récapituler, TypeScript compile votre code React pour vérifier votre code. Il n'émet aucune sortie JavaScript (dans la plupart des scénarios). La sortie est toujours similaire à un projet non-TypeScript React.

TypeScript peut-il fonctionner avec React et webpack?

Oui, TypeScript peut fonctionner avec React et webpack. Heureusement pour vous, le manuel officiel de TypeScript contient un guide .

Avec un peu de chance, cela vous donne un petit rappel sur la façon dont les deux fonctionnent ensemble. Maintenant, passons aux meilleures pratiques!

Meilleures pratiques

Nous avons recherché les questions les plus courantes et rassemblé cette liste pratique des cas d'utilisation les plus courants pour React avec TypeScript. De cette façon, vous pouvez suivre les meilleures pratiques dans vos projets en utilisant cet article comme référence.

Configuration

L'une des parties les moins amusantes, mais les plus importantes du développement est la configuration. Comment pouvons-nous mettre en place les choses dans les plus brefs délais qui fourniront une efficacité et une productivité maximales? Nous discuterons de la configuration du projet, notamment:

• tsconfig.json
• ESLint
• Prettier
• Extensions et paramètres du code VS.

Configuration du projet

La façon la plus rapide de démarrer une application React / TypeScript est en utilisant create-react-app avec le modèle TypeScript. Vous pouvez le faire en exécutant:

 npx create-react-app my-app --template typescript

Cela vous donnera le strict minimum pour commencer à écrire React avec TypeScript. Quelques différences notables sont:

• l'extension de fichier .tsx
• la tsconfig.json
• la react-app-env.d.ts

La tsx est pour “TypeScript JSX”. Le tsconfig.json est le fichier de configuration TypeScript, qui a des valeurs par défaut définies. react-app-env.d.ts fait référence aux types de react-scripts et aide à des choses comme autoriser les importations SVG.

tsconfig.json [19659002] Heureusement pour nous, le dernier modèle React / TypeScript génère tsconfig.json pour nous. Cependant, ils ajoutent le strict minimum pour commencer. Nous vous suggérons de modifier le vôtre pour qu'il corresponde à celui ci-dessous. Nous avons également ajouté des commentaires pour expliquer le but de chaque option:

 {
  "options de compilation": {
    "target": "es5", // Spécifiez la version cible ECMAScript
    "lib": [
      "dom",
      "dom.iterable",
      "esnext"
    ]// Liste des fichiers de bibliothèque à inclure dans la compilation
    "allowJs": true, // Autorise la compilation de fichiers JavaScript
    "skipLibCheck": true, // Ignore la vérification de type de tous les fichiers de déclaration
    "esModuleInterop": true, // Désactive les importations d'espace de noms (importation * en tant que fs de "fs") et active les importations de style CJS / AMD / UMD (importation de fs en provenance de "fs")
    "allowSyntheticDefaultImports": true, // Autorise les importations par défaut à partir de modules sans exportation par défaut
    "strict": true, // Active toutes les options de vérification de type stricte
    "forceConsistentCasingInFileNames": true, // Interdire les références en cas de cohérence au même fichier.
    "module": "esnext", // Spécifiez la génération du code du module
    "moduleResolution": "node", // Résoudre les modules en utilisant le style Node.js
    "resolJsonModule": true, // Inclut les modules importés avec l'extension .json
    "isolatedModules": true, // Transpile chaque fichier en module séparé
    "noEmit": true, // Ne pas émettre de sortie (ce qui signifie ne pas compiler de code, effectuer uniquement une vérification de type)
    "jsx": "react" // Supporte JSX dans les fichiers .tsx
    "sourceMap": true, // *** Génère un fichier .map correspondant ***
    "declaration": true, // *** Génère le fichier .d.ts correspondant ***
    "noUnusedLocals": true, // *** Signaler des erreurs sur les sections locales inutilisées ***
    "noUnusedParameters": true, // *** Signaler des erreurs sur les paramètres inutilisés ***
    "experimentalDecorators": true // *** Active le support expérimental pour les décorateurs ES ***
    "incremental": true // *** Activer la compilation incrémentielle en lisant / écrivant les informations des compilations précédentes dans un fichier sur le disque ***
        "noFallthroughCasesInSwitch": true // *** Signaler les erreurs pour les cas de panne dans l'instruction switch ***
  },
  "comprennent": [
    "src/**/*" // *** The files TypeScript should type check ***
  ],
  "exclude": ["node_modules", "build"] // *** Les fichiers à ne pas taper check ***
}

Les recommandations supplémentaires proviennent de la communauté [react-typescript-cheatsheet] (https://github.com/typescript-cheatsheets/react-typescript-cheatsheet) et les explications proviennent de la Documentation des options du compilateur dans le manuel TypeScript officiel. C'est une ressource merveilleuse si vous voulez en savoir plus sur les autres options et ce qu'elles font.

ESLint / Prettier

Afin de vous assurer que votre code suit les règles du projet ou de votre équipe, et le style est cohérent, il est recommandé de configurer ESLint et Prettier. Pour les faire jouer correctement, procédez comme suit pour le configurer.

1. Installez les dépendances de développement requises:

    yarn add eslint @ typescript-eslint / parser @ typescript-eslint / eslint-plugin eslint-plugin-react - -dev
    

2. Créez un fichier .eslintrc.js à la racine et ajoutez ce qui suit:

    module.exports = {
     parser: '@ typescript-eslint / parser', // Spécifie l'analyseur ESLint
     étend: [
       'plugin:react/recommended',  // Uses the recommended rules from @eslint-plugin-react
       'plugin:@typescript-eslint/recommended',  // Uses the recommended rules from @typescript-eslint/eslint-plugin
     ],
     parserOptions: {
     ecmaVersion: 2018, // Permet l'analyse des fonctionnalités ECMAScript modernes
     sourceType: 'module', // Permet l'utilisation des importations
     ecmaFeatures: {
       jsx: true, // permet l'analyse de JSX
     },
     },
     règles:  {
       // Place pour spécifier les règles ESLint. Peut être utilisé pour remplacer les règles spécifiées à partir des configurations étendues
       // par exemple. "@ typescript-eslint / explicit-function-return-type": "off",
     },
     réglages:  {
       réagir: {
         version: 'detect', // Indique à eslint-plugin-react de détecter automatiquement la version de React à utiliser
       },
     },
   };
    

3. Ajouter des dépendances plus jolies:

    fil ajouter plus joliment eslint-config-prettier eslint-plugin-prettier --dev
    

4. Créez un fichier .prettierrc.js à la racine et ajoutez ce qui suit:

    module.exports = {
     semi: vrai,
     trailingComma: 'all',
     singleQuote: true,
     printWidth: 120,
     tabWidth: 4,
   };
    

5. Mettez à jour le fichier .eslintrc.js :

    module.exports = {
     parser: '@ typescript-eslint / parser', // Spécifie l'analyseur ESLint
     étend: [
       'plugin:react/recommended',  // Uses the recommended rules from @eslint-plugin-react
       'plugin:@typescript-eslint/recommended',  // Uses the recommended rules from the @typescript-eslint/eslint-plugin
   +   'prettier/@typescript-eslint',  // Uses eslint-config-prettier to disable ESLint rules from @typescript-eslint/eslint-plugin that would conflict with prettier
   +   'plugin:prettier/recommended',  // Enables eslint-plugin-prettier and displays prettier errors as ESLint errors. Make sure this is always the last configuration in the extends array.
     ],
     parserOptions: {
     ecmaVersion: 2018, // Permet l'analyse des fonctionnalités ECMAScript modernes
     sourceType: 'module', // Permet l'utilisation des importations
     ecmaFeatures: {
       jsx: true, // permet l'analyse de JSX
     },
     },
     règles:  {
       // Place pour spécifier les règles ESLint. Peut être utilisé pour remplacer les règles spécifiées à partir des configurations étendues
       // par exemple. "@ typescript-eslint / explicit-function-return-type": "off",
     },
     réglages:  {
       réagir: {
         version: 'detect', // Indique à eslint-plugin-react de détecter automatiquement la version de React à utiliser
       },
     },
   };
   

Ces recommandations proviennent d'une ressource communautaire écrite appelée «Utilisation d'ESLint et de Prettier dans un projet TypeScript» par Robert Cooper . Si vous visitez son blog, vous pouvez en savoir plus sur le «pourquoi» derrière ces règles et configurations.

Extensions et paramètres VSCode

Nous avons ajouté ESLint et Prettier et la prochaine étape pour améliorer notre DX est pour corriger / améliorer automatiquement notre code lors de la sauvegarde.

Tout d'abord, installez l'extension ESLint pour VSCode . Cela permettra à ESLint de s'intégrer parfaitement à votre éditeur.

Ensuite, mettez à jour vos paramètres Workspace en ajoutant ce qui suit à votre .vscode / settings.json :

 {
  "eslint.autoFixOnSave": vrai,
  "eslint.validate": [
    "javascript",
    "javascriptreact",
    { "language": "typescript", "autoFix": true },
    { "language": "typescriptreact", "autoFix": true }
  ],
  "editor.formatOnSave": vrai,
  "[javascript]": {
    "editor.formatOnSave": faux
  },
  "[javascriptreact]": {
    "editor.formatOnSave": faux
  },
  "[typescript]": {
    "editor.formatOnSave": faux
  },
  "[typescriptreact]": {
    "editor.formatOnSave": faux
  }
} 

Cela permettra à VS Code de travailler sa magie et de corriger votre code lorsque vous enregistrez. C'est beau!

Ces suggestions proviennent également de l'article précédemment lié "Utilisation d'ESLint et de Prettier dans un projet TypeScript" par Robert Cooper .

Composants

L'un des concepts fondamentaux de React est Composants. Ici, nous ferons référence aux composants standard à partir de React v16.8, c'est-à-dire ceux qui utilisent des hooks par opposition aux classes.

En général, il y a beaucoup à se soucier des composants de base. Prenons un exemple:

 importez React depuis 'react'

// Écrit en tant que déclaration de fonction
fonction Heading (): React.ReactNode {
  retour 
 Mon titre de site Web 
}

// Écrit en tant qu'expression de fonction
const OtherHeading: React.FC = () => 
 Mon titre de site Web 

Remarquez la principale différence ici. Dans le premier exemple, nous écrivons notre fonction en tant que déclaration de fonction . Nous annotons le type de retour avec React.Node parce que c'est ce qu'il renvoie. En revanche, le deuxième exemple utilise une expression de fonction . Étant donné que la deuxième instance renvoie une fonction, au lieu d'une valeur ou d'une expression, nous annotons le type de fonction avec React.FC pour React "Function Component".

Cela peut être déroutant pour se souvenir des deux. C'est surtout une question de choix de conception. Quelle que soit l'option que vous choisissez d'utiliser dans votre projet, utilisez-la de manière cohérente.

Accessoires

Le prochain concept de base que nous aborderons est celui des accessoires. Vous pouvez définir vos accessoires à l'aide d'une interface ou d'un type. Prenons un autre exemple:

 importez React depuis 'react'

accessoires d'interface {
  nom: chaîne;
  couleur: chaîne;
}

type OtherProps = {
  nom: chaîne;
  couleur: chaîne;
}

// Notez ici que nous utilisons la déclaration de fonction avec l'interface Props
en-tête de fonction ({nom, couleur}: accessoires): React.ReactNode {
  retour 
 Mon titre de site Web 
}

// Notez ici que nous utilisons l'expression de fonction avec le type OtherProps
const OtherHeading: React.FC  = ({nom, couleur}) =>
  
 Mon titre de site Web 

En ce qui concerne les types ou les interfaces, nous vous suggérons de suivre les directives présentées par la communauté react-typescript-cheatsheet :

• "utilisez toujours l'interface pour la définition de l'API publique lors de la création d'une bibliothèque ou d'un tiers- définitions de type ambiant de partie. "
• " envisagez d'utiliser le type pour vos accessoires et états de composant React, car il est plus contraint. "

Vous pouvez en savoir plus sur la discussion et voir un tableau pratique comparant les types et les interfaces ici .

Regardons un autre exemple pour que nous puissions voir quelque chose d'un peu plus pratique:

 importez React à partir de 'react'

type Props = {
  / ** couleur à utiliser pour le fond * /
  couleur?: chaîne;
  / ** accessoire enfant standard: accepte tout nœud React valide * /
  enfants: React.ReactNode;
  / ** fonction de rappel passée au gestionnaire onClick * /
  onClick: () => void;
}

Bouton const: React.FC  = ({children, color = 'tomato', onClick}) => {
   retour  {enfants} 
}

Dans ce composant nous utilisons un type pour nos accessoires. Chaque accessoire a une courte description ci-dessus pour fournir plus de contexte aux autres développeurs. Le ? d'après l'hélice nommée couleur indique qu'il est facultatif. Le prop enfants prend un React.ReactNode car il accepte tout ce qui est une valeur de retour valide d'un composant ( en savoir plus ici ). Pour tenir compte de notre accessoire optionnel de couleur nous utilisons une valeur par défaut lors de sa déstructuration. Cet exemple doit couvrir les bases et montrer que vous devez écrire des types pour vos accessoires et utiliser des valeurs facultatives et par défaut.

En général, gardez ces choses à l'esprit lorsque vous écrivez vos accessoires dans un projet React et TypeScript:

• Always ajoutez des commentaires descriptifs à vos accessoires à l'aide de la notation TSDoc / ** comment * / .
• Que vous utilisiez des types ou des interfaces pour vos accessoires de composant, utilisez-les de manière cohérente.
• Lorsque les accessoires sont facultatifs, gérez

Hooks

Heureusement, l'inférence de type TypeScript fonctionne bien lors de l'utilisation de hooks. Cela signifie que vous n’avez pas grand-chose à craindre. Par exemple, prenez cet exemple:

 // `value` est déduit sous forme de chaîne
// `setValue` est déduit comme (newValue: string) => void
const [value, setValue] = useState ('')

C'est un domaine dans React et TypeScript qui brille. Cela signifie que vous n’avez pas à faire grand-chose. Les choses fonctionnent juste et c'est magnifique.

Dans les rares occasions où vous devez initialiser un hook avec une valeur nulle, vous pouvez utiliser un générique et passer une union pour taper correctement votre hook . Voir cette instance:

 type User = {
  email: chaîne;
  id: string;
}

// le générique est le < >
// l'union est l'utilisateur | nul
// ensemble, TypeScript sait, "Ah, l'utilisateur peut être Utilisateur ou nul".
const [user, setUser] = useState  (null);

L'autre endroit où TypeScript brille avec les crochets est avec userReducer où vous pouvez profiter des unions discriminées . Voici un exemple utile:

 type AppState = {};
type Action =
  | {tapez: "SET_ONE"; charge utile: chaîne}
  | {type: "SET_TWO"; charge utile: nombre};

réducteur de la fonction d'exportation (état: AppState, action: Action): AppState {
  commutateur (action.type) {
    cas "SET_ONE":
      revenir {
        ...Etat,
        un: action.payload // `payload` est une chaîne
      };
    cas "SET_TWO":
      revenir {
        ...Etat,
        deux: action.payload // `payload` est un nombre
      };
    défaut:
      état de retour;
  }
}

Source: react-typescript-cheatsheet Section des crochets

La beauté ici réside dans l'utilité des unions discriminées. Remarquez comment Action a une union de deux objets d'aspect similaire. La propriété type est une chaîne de caractères littérale . La différence entre ceci et une chaîne de type est que la valeur doit correspondre à la chaîne littérale définie dans le type. Cela signifie que votre programme est très sûr car un développeur ne peut appeler qu'une action dont la clé de type est définie sur "SET_ONE" ou "SET_TWO" . [19659005] Comme vous pouvez le voir, les hooks n'ajoutent pas beaucoup de complexité à la nature d'un projet React et TypeScript. Si quoi que ce soit, ils se prêtent bien au duo.

Cas d'utilisation courants

Cette section est destinée à couvrir les cas d'utilisation les plus courants où les utilisateurs trébuchent lorsqu'ils utilisent TypeScript avec React. Nous espérons qu'en partageant cela, vous éviterez les pièges et partagerez même ces connaissances avec d'autres.

Gestion des événements de formulaire

L'un des cas les plus courants consiste à taper correctement le onChange utilisé sur un champ de saisie dans un formulaire. Voici un exemple:

 importez React à partir de 'react'

const MyInput = () => {
  const [value, setValue] = React.useState ('')

  // Le type d'événement est un "ChangeEvent"
  // On passe "HTMLInputElement" à l'entrée
  fonction onChange (e: React.ChangeEvent ) {
    setValue (e.target.value)
  }

  retour 
}

Extension des accessoires de composant

Parfois, vous voulez prendre les accessoires de composant déclarés pour un composant et les étendre pour les utiliser sur un autre composant. Mais vous voudrez peut-être en modifier un ou deux. Eh bien, rappelez-vous comment nous avons examiné les deux façons de taper les accessoires, les types ou les interfaces des composants? En fonction de celui que vous avez utilisé, vous déterminez comment étendre les accessoires de composant. Voyons d'abord comment utiliser le type :

 importez React à partir de 'react';

tapez ButtonProps = {
    / ** la couleur de fond du bouton * /
    couleur: chaîne;
    / ** le texte à afficher à l'intérieur du bouton * /
    texte: chaîne;
}

type ContainerProps = ButtonProps & {
    / ** la hauteur du conteneur (valeur utilisée avec 'px') * /
    hauteur: nombre;
}

Const Container: React.FC  = ({couleur, hauteur, largeur, texte}) => {
  retour 
 {text} 
}

Si vous avez déclaré vos accessoires à l'aide d'une interface alors nous pouvons utiliser le mot-clé étend pour "étendre" essentiellement cette interface mais apportez une ou deux modifications:

 import React de «réagir»;

interface ButtonProps {
    / ** la couleur de fond du bouton * /
    couleur: chaîne;
    / ** le texte à afficher à l'intérieur du bouton * /
    texte: chaîne;
}

l'interface ContainerProps étend ButtonProps {
    / ** la hauteur du conteneur (valeur utilisée avec 'px') * /
    hauteur: nombre;
}

Const Container: React.FC  = ({couleur, hauteur, largeur, texte}) => {
  retour 
 {text} 
}

Les deux méthodes résolvent le problème. C'est à vous de décider lequel utiliser. Personnellement, l'extension d'une interface semble plus lisible, mais en fin de compte, cela dépend de vous et de votre équipe.

Vous pouvez en savoir plus sur les deux concepts dans le manuel TypeScript:

Bibliothèques tierces

Que ce soit pour un GraphQL client comme Apollo ou pour tester avec quelque chose comme React Testing Library nous nous retrouvons souvent à utiliser des bibliothèques tierces dans les projets React et TypeScript. Lorsque cela se produit, la première chose que vous voulez faire est de voir s'il existe un package @types avec les définitions de type TypeScript. Vous pouvez le faire en exécutant:

 #yarn
fil ajouter des types @ / 

#npm
npm install @ types / 

Par exemple, si vous utilisez Jest vous pouvez le faire en exécutant:

 #yarn
fil ajouter @ types / jest

#npm
npm install @ types / jest

Cela vous donnerait alors une sécurité de type supplémentaire chaque fois que vous utilisez Jest dans votre projet.

L'espace de noms @types est réservé pour les définitions de type de package. Ils vivent dans un référentiel appelé DefinitelyTyped qui est partiellement géré par l'équipe TypeScript et partiellement par la communauté.

Devraient-ils être enregistrés en tant que dépendances ou devDependencies dans mon package.json ?

La réponse courte est «ça dépend». La plupart du temps, ils peuvent passer sous devDependencies si vous créez une application Web. Cependant, si vous écrivez une bibliothèque React en TypeScript, vous souhaiterez peut-être les inclure en tant que dépendances .

Il y a quelques réponses à cela sur Débordement de pile que vous

Que se passe-t-il s'ils n'ont pas de package @types?

Si vous ne trouvez pas de package @types sur npm, alors vous ont essentiellement deux options:

1. Ajouter un fichier de déclaration de base
2. Ajouter un fichier de déclaration complet

La ​​première option signifie que vous créez un fichier basé sur le nom du package et le placez à la racine. Si, par exemple, nous avions besoin de types pour notre package banana-js alors nous pourrions créer un fichier de déclaration de base appelé banana-js.d.ts à la racine:

 déclarer le module 'banana-js';

Cela ne vous offrira pas de sécurité de type mais cela vous débloquera.

Un fichier de déclaration plus complet serait celui où vous ajoutez les types pour la bibliothèque / le package:

 declare namespace bananaJs {
    fonction getBanana (): chaîne;
    fonction addBanana (n: nombre) void;
    fonction removeBanana (n: nombre) void;
}

Si vous n'avez jamais écrit de fichier de déclaration, nous vous suggérons de consulter le guide du manuel TypeScript officiel .

Résumé

Utiliser React et TypeScript ensemble dans le meilleur des cas prend un peu d'apprentissage en raison de la quantité d'informations, mais les avantages rapportent énormément à long terme. Dans cet article, nous avons couvert la configuration, les composants, les accessoires, les crochets, les cas d'utilisation courants et les bibliothèques tierces. Bien que nous puissions approfondir de nombreux domaines, cela devrait couvrir les 80% nécessaires pour vous aider à suivre les meilleures pratiques.

Si vous souhaitez entrer en contact, partager d'autres bonnes pratiques ou discuter de l'utilisation des deux technologies ensemble, vous pouvez me joindre sur Twitter @jsjoeio .

Pour en savoir plus

Si vous souhaitez approfondir, voici quelques ressources que nous vous suggérons:

react-typescript-cheatsheet [19659007] Beaucoup de ces recommandations provenaient directement de la fiche de réaction react-typescript-cheats
. Si vous cherchez des exemples ou des détails spécifiques sur quoi que ce soit React-TypeScript, c'est l'endroit où aller. Nous apprécions également les contributions!

Manuel TypeScript officiel

Une autre ressource fantastique est le Manuel TypeScript . Ceci est tenu à jour par l'équipe TypeScript et fournit des exemples et une explication détaillée derrière le fonctionnement interne du langage.

TypeScript Playground

Saviez-vous que vous pouvez tester React avec le code TypeScript directement dans le navigateur ? Il vous suffit d'importer React. Voici un lien pour commencer .

Joe Previte, également connu sous le nom de JavaScript Joe, est un défenseur des développeurs Open Source sur Facebook. Dans ses temps libres, il aime créer des vidéos pour Egghead, écrire des articles sur le codage et diriger un groupe d'étude de méditation en ligne.