Recentemente, vi um tweet de Jamie Kyle sobre o uso de desestruturação, parâmetros padrão e tipos embutidos:   https://twitter.com/buildsghost/status/1577030375158607872?s=20&t=0qa78fG7TzsSdxrsM1sCvg?embedable=true  Esse tweet e alguns componentes do React que vi recentemente em meu trabalho diário me inspiraram a escrever esta postagem no blog. Quero mostrar a você como usar tipos de desestruturação e embutidos pode tornar seu TypeScript menos legível!  Como é a definição da função TypeScript?  Em JavaScript e TypeScript, você pode definir uma função usando a palavra-chave   ou a função lambda/seta. Ambas as formas são válidas, mas têm suas diferenças. Vamos dar uma olhada na função simples   . A lógica de implementação não é relevante para nós. 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 };  Quando a definição da função é bastante simples, a função aceita alguns parâmetros de um tipo diferente. Se forem primitivos como strings ou números, tudo é legível.  Digamos que você queira passar algumas informações adicionais junto com o conteúdo de sua mensagem para a função   . sendMessage   function sendMessage(message: { content: string; senderId: string; replyTo?: string; }) { // you can assess content using `message.content` here }  Como você pode ver, o TypeScript permite que você escreva uma definição de tipo embutida para o objeto de   que deseja passar sem especificar o tipo usando a palavra-chave   ou   . message type interface  Vamos adicionar Destructuring. Quando você passa um grande objeto de   para sua função, o TypeScript permite separar os argumentos passados para reduzir o padrão de código da variável de   repetida muitas vezes. message message   function sendMessage({ content, senderId, replyTo, }: { content: string; senderId: string; replyTo?: string; }) { // you have access to `content` directly }  Por que acho que é uma má ideia e como você pode torná-la melhor?  Pode parecer uma boa ideia, afinal não é preciso escrever   vezes, certo? Acontece que não é tão bom. Vamos falar sobre 5 razões pelas quais eu acho que é um antipadrão. message  1. Você não tem certeza de onde vêm seus dados  Ao ler o corpo da função, você vê   e precisa verificar novamente para ter certeza de onde essa função vem. É passado como um argumento ou calculado em algum lugar da função? senderId  2. É difícil escrever documentação  Não há lugar natural para escrever comentários de documentação quando todos os tipos são limitados pela desestruturação na definição da função. Você pode escrever comentários entre cada campo de tipo, mas isso torna toda a definição da função ainda mais longa. Está ativamente desencorajando você a escrever um resumo rápido dos dados que está passando.  3. É difícil passar esses dados adiante  Quando seus dados são desestruturados, você precisa estruturá-los novamente em um novo objeto se quiser passá-los adiante. Isso desencoraja a criação de funções auxiliares menores e a dependência da composição para construir a lógica da função principal.  4. Você não pode reutilizar tipos de argumentos fora desta função  Se você precisar reutilizar seus argumentos de função em funções auxiliares ao compor sua lógica de função principal, deverá digitar o mesmo conjunto de tipos repetidamente. Isso torna mais fácil não escrever tipos.  5. É preciso muito espaço  Vamos encarar. São apenas muitas linhas de código que ocupam muito espaço na tela. Além disso, ele se concentra nos detalhes da implementação – o tipo interno dos argumentos que você está passando para uma função, que na maioria das vezes não é relevante quando você está olhando para essa função.  Basta criar um tipo para ele  Extrair o tipo e colocá-lo logo acima da função o torna muito mais legível. Há um local para comentários de documentação, você pode reutilizar esse tipo em alguma outra função auxiliar e alterar a definição de tipo em um local, se necessário.   /** * 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 }  Recursos  Encontre uma lista de recursos que usei ao pesquisar esta postagem no 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

Este áudio é produzido no idioma original da história!

Usar tipos de desestruturação e embutidos pode prejudicar sua base de código TypeScript

About Author

COMENTARIOS

Rótulos

ESTE ARTIGO FOI APRESENTADO EM

Related Stories

Digital Nomads Ouçam: O que você precisa saber sobre o novo visto DTV da Tailândia

Aumente sua produtividade com estas 18 ferramentas para desenvolvedores 🚀🔥

Como melhorar seu fluxo de trabalho em 10 vezes: 17 aplicativos essenciais

Modelo Bitcoin UTXO, alimentando um ecossistema único

Digital Nomads Ouçam: O que você precisa saber sobre o novo visto DTV da Tailândia

Aumente sua produtividade com estas 18 ferramentas para desenvolvedores 🚀🔥

Como melhorar seu fluxo de trabalho em 10 vezes: 17 aplicativos essenciais

Modelo Bitcoin UTXO, alimentando um ecossistema único

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps