Récemment, j'ai vu un tweet de Jamie Kyle sur l'utilisation de la déstructuration, des paramètres par défaut et des types en ligne : https://twitter.com/buildsghost/status/1577030375158607872?s=20&t=0qa78fG7TzsSdxrsM1sCvg?embedable=true Ce tweet et quelques composants React que j'ai vus récemment dans mon travail quotidien m'ont inspiré pour écrire ce billet de blog. Je veux vous montrer comment l'utilisation de la déstructuration et des types inline peut rendre votre TypeScript moins lisible ! À quoi ressemble la définition de la fonction TypeScript ? En JavaScript et TypeScript, vous pouvez définir une fonction à l'aide du mot-clé de ou de la fonction lambda/flèche. Les deux manières sont valables mais ont leurs différences. Jetons un coup d'œil à la simple fonction . La logique de mise en œuvre ne nous concerne pas. function sendMessage // sendMessage function written using `function` keyword function sendMessage(message: string) { // function logic } // same sendMessage written as arrow function const sendMessage = (message: string) => { // function logic }; Lorsque la définition de la fonction est assez simple, la fonction accepte quelques paramètres d'un type différent. S'il s'agit de primitives comme des chaînes ou des nombres, tout est lisible. Supposons que vous souhaitiez transmettre des informations supplémentaires à côté du contenu de votre message à la fonction . sendMessage function sendMessage(message: { content: string; senderId: string; replyTo?: string; }) { // you can assess content using `message.content` here } Comme vous pouvez le constater, TypeScript vous permet d'écrire une définition de type en ligne pour l'objet de que vous souhaitez transmettre sans spécifier le type à l'aide du mot clé ou . message type interface Ajoutons Destructuring. Lorsque vous transmettez un objet de volumineux à votre fonction, TypeScript permet de séparer les arguments passés pour réduire le code passe-partout consistant à répéter plusieurs fois la variable de . message message function sendMessage({ content, senderId, replyTo, }: { content: string; senderId: string; replyTo?: string; }) { // you have access to `content` directly } Pourquoi est-ce que je pense que c'est une mauvaise idée et comment pouvez-vous l'améliorer ? Cela peut sembler une bonne idée, après tout, vous n'avez pas besoin d'écrire autant de fois, n'est-ce pas ? Il s'avère que ce n'est pas si génial. Parlons de 5 raisons pour lesquelles je pense que c'est un anti-modèle. message 1. Vous ne savez pas d'où proviennent vos données Lorsque vous lisez le corps de la fonction, vous voyez , vous devez revérifier pour être sûr d'où vient cette fonction. Est-il passé en argument ou calculé quelque part dans la fonction ? senderId 2. Il est difficile d'écrire de la documentation Il n'y a pas d'endroit naturel pour écrire des commentaires de documentation lorsque tous les types sont à l'étroit avec la déstructuration dans la définition de la fonction. Vous pouvez écrire des commentaires entre chaque champ de type, mais cela rend la définition de la fonction entière encore plus longue. Cela vous décourage activement d'écrire un résumé rapide des données que vous transmettez. 3. Il est difficile de transmettre ces données Lorsque vos données sont déstructurées, vous devez les structurer à nouveau dans un nouvel objet si vous souhaitez les transmettre. Cela décourage la création de fonctions d'assistance plus petites et l'utilisation de la composition pour créer la logique de votre fonction principale. 4. Vous ne pouvez pas réutiliser les types d'arguments en dehors de cette fonction Si vous avez besoin de réutiliser vos arguments de fonction dans des fonctions d'assistance lors de la composition de votre logique de fonction principale, vous devez taper le même ensemble de types à plusieurs reprises. Cela rend plus facile de ne pas écrire de types du tout. 5. Cela prend juste beaucoup de place Avouons-le. C'est juste beaucoup de lignes de code qui occupent beaucoup d'espace à l'écran. Et en plus, il se concentre sur les détails d'implémentation - le type interne des arguments que vous transmettez à une fonction, qui n'est la plupart du temps pas pertinent lorsque vous regardez cette fonction. Créez simplement un type pour cela Extraire le type et le placer juste au-dessus de la fonction le rend beaucoup plus lisible. Il y a un endroit pour les commentaires de documentation, vous pouvez réutiliser ce type dans une autre fonction d'assistance et modifier la définition de type à un endroit si nécessaire. /** * Message to send using XYZ API */ export type MessageToSend = { /** * Markdown string of the user's message */ content: string; /** * Id of the sender user */ senderId: string; /** * Other message ID if this is a reply */ replyTo?: string; }; function sendMessage(message: MessageToSend) { // function logic } function getUserIdsToNotify(message: MessaageToSend) { // function logic } Ressources Trouvez une liste des ressources que j'ai utilisées lors de la recherche de cet article de blog : https://www.typescriptlang.org/docs/handbook/variable-declarations.html#object-destructuring

The code in this story is for educational purposes. The readers are solely responsible for whatever they build with it.

Alongside

Twitter

Read My Stories

Cet audio est produit dans la langue originale de l'histoire !

Trop long; Pour lire

Making security fun one episode at a time

L'utilisation de la déstructuration et des types en ligne peut nuire à votre base de code TypeScript

Trop long; Pour lire

Companies Mentioned

Tomasz Cichociński

STORY’S CREDIBILITY

Code License

About Author

ÉTIQUETTES

Languages

CET ARTICLE A ÉTÉ PARU DANS...

L'utilisation de la déstructuration et des types en ligne peut nuire à votre base de code TypeScript

Trop long; Pour lire

Companies Mentioned

Tomasz Cichociński

STORY’S CREDIBILITY

Code License

About Author

ÉTIQUETTES

Languages

CET ARTICLE A ÉTÉ PARU DANS...

HISTOIRES CONNEXES