Typescript parte 3: mais técnicas e boas práticas

Entendendo Decorators - Apresentação

Olá, pessoal, eu sou Flavio Almeida, bem vindos ao terceiro curso de TypeScript, esse curso ele tem todo o conteúdo do primeiro, do segundo curso é o mesmo projeto só que uma ligeira modificação que eu quero mostrar para vocês.

Primeira coisa que vocês vão fazer é ir lá no projeto, no link do capítulo, baixar o projeto e descompactar na área de trabalho de vocês. Descompactando na área de trabalho, eu vou pegar o meu Visual Studio Code, o editor de texto utilizado durante o treinamento, vou lá na área de trabalho, abrir aqui, TypeScript abriu o projeto do curso.

Com todo o código do curso anterior, a única modificação é que a pasta dist e a app, que antes tinha o código fonte, agora estão dentro de app. Então src tem o nosso código fonte TypeScript que nós escrevemos e a pasta dist é a pasta onde ficam os arquivos compilados do TypeScript para o Java Script.

Essa estrutura eu alterei para ficar mais perto com a estrutura de um servidor web ou uma aplicação escrita em Angular usando o Angular CLI, React e por aí vai. Relembrando o seguinte, para nós rodarmos esse projeto, você precisa ter o node.js 10.21 ou superior, versões LTS, vocês precisam usar o Studio Code e ter o Chrome instalado, então como é que eu executo o projeto?

Executando o projeto, lembrando de cursos anteriores que a gente tem um script, start que vai rodar o meu servidor local, mais o computador TypeScript em tempo real, significa que qualquer mudança nos nossos arquivos TS vai refletir no nosso projeto. Então eu vou escrever npm run start e isso aqui vai ser suficiente para ele abrir o navegador, no meu caso ele abriu aqui na minha segunda tela, deixa eu jogar para cá.

O projeto abriu, deixa eu forçar de novo, vou parar e vou voltar lá para o nosso código, abriu o terminal e lembrando, como faz para abrir o terminal? Você vem em “terminal > new terminal”, com a pasta do projeto aberta dentro do Visual Studio Code, vou dar npm run start. Fazendo isso o navegador vai ser automaticamente aberto. Uma outra diferença que a gente já nota aqui, é que dentro de localhost:3000 eu vou ter a subpasta dist e dentro dela o meu index.html.

Mas a aplicação continua funcionando perfeita em relação ao curso anterior, nenhum código foi trocado, só a estrutura de pastas, tá bom? Então é essa a estrutura que nós vamos utilizar ao longo do treinamento, então relembrando que o nosso código fonte agora está na pasta src, de source, e o resultado da compilação do nosso arquivo Start Script vão estar dentro da pasta dist.

Uma outra coisa aqui, só para finalizar, esse index.html que tem aqui dentro da pasta app só para o redirect quando eu abro o meu servidor lá para a pasta dist. E é a pasta dist que eu tenho meu index.htlm e meus scripts, tá bom? Só uma mudança porque eu quero motivar uma coisa lá para o final do treinamento e eu preciso dessa estrutura aí.

Fechado, galera? Então vamos começar, porque tem bastante coisa nova aqui para nós vermos e deixar nosso Code cada vez mais lindo.

Entendendo Decorators - Requisitos não funcionais

Pessoal, vamos voltar aqui para a nossa aplicação, porque nós precisamos continuar. Nossa aplicação está funcionando, nós conseguimos ir lá cadastrar aqui uma negociação que não seja em dia útil, mas, seguinte, essa aplicação é uma aplicação que você vai trabalhar, que você vai desenvolver geralmente ela tem requisitos que alguém está pedindo que essa aplicação funcione de uma determinada maneira.

Mas tem coisas que nós chamamos de requisitos não funcionais que é tudo aquilo que a sua aplicação tem que ter e que o cliente não pede, que está subentendido que vai ter e um dos requisitos não funcionais nessa aplicação é a velocidade. Nós esperamos que essa renderização da nossa tabela seja numa velocidade aceitável.

É claro que pelo escopo da nossa aplicação, ela é até aceitável, mas, por exemplo, eu poderia gerar uma métrica aqui na minha aplicação para saber se eu preciso substituir a nossa própria solução, o nosso próprio micro framework view, substituir por uma solução mais profissional do mercado como a angular, react e por aí vai.

Então como é que eu faço essa análise para saber o tempo de renderização, o tempo que demora meus métodos para serem executados? A primeira coisa que passa na nossa cabeça é nós chegarmos lá na nossa classe view, nossa abstract class view generic e o que eu vou fazer? Eu vou chegar no método update e vou usar aqui um recurso que tem no próprio navegador, eu vou fazer um teste de performance e tempo de execução.

Vou criar aqui uma constante que vou chamar de t1, esse cara vai ser igual ao objeto disponível globalmente no navegador chamado performance e vou chamar o método now. Então vou guardar o tempo 1 e quando eu acabo de renderizar, eu vou dizer que const t2 = performance.now e agora eu preciso saber a diferença entre um e outro.

Então o que eu vou fazer no meu console? console.log e aí eu vou botar assim, usando uma template string, tempo de execução do método update: t2-t1, esse cara vai me dar em milissegundos e eu vou dividir por mil para saber quanto é em segundos e eu vou colocar aqui segundos, quero saber quanto tempo esse cara demora.

Vou salvar. Nenhum erro de compilação aqui que nós estamos vendo, vou voltar lá para o navegador, vou olhar aqui o console log. Ele já carregou e como nós já fazemos o update no table, ele está dizendo que o update do view demorou essa fração aqui de segundos. Beleza, agora vamos adicionar 17/01/2020, 1111, incluir. Mais outro teste.

Então eu tenho uma métrica aqui de segundos, mas a questão toda agora é que eu também tenho que saber quanto o método adiciona vai levar. Então vamos voltar lá para o código, vou voltar lá para o meu controle dentro de src. Você pode fazer assim também, “Ctrl + P”, aí você coloca controller e ele vai te mostrar controller.ts, cuidado, tá?

Dentro do controller.ts eu vou fazer a mesma coisa, const t1 = performance.now, guardei esse tempo. Quando eu acabo de incluir eu vou fazer cons t2 = performance.now e agora eu vou ter que fazer o console.log. Vou copiar aqui, na natureza nada se cria, tudo se copia. Vou colocar aqui, tempo de execução do método que não é mais update, é adiciona.

Está aqui o meu código. Vou chegar um pouco para o lado para vocês verem aqui. Completar o código, salvei e vou voltar lá para o meu navegador, fez o refresh. Vou digitar 17/01/2020, vou incluir alguma coisa aqui, pronto incluiu e eu tenho lá o tempo de execução gasto com o método adiciona. Você vê que ele já não foi tão rápido quanto os outros, mas mesmo assim é muito rápido.

Só que isso não está legal, galera. É o seguinte, todo o lugar que eu quiser realizar essa métrica, eu vou ter que praticamente copiar e colar o mesmo código, que é cria t1, cria t2, faz o console.log e a única coisa que muda nesse console log é o nome do método que eu estou executando. Então esse código é intrusivo, ele está entrando na lógica.

Esse requisito não funcional está entrando na lógica do método da minha classe, ele não pertence, ele não faz parte da regra de negócio, ele está aí porque eu preciso executá-lo. Outra coisa, se eu quiser fazer isso em outros lugares do sistema, eu vou ter que repetir esse código em vários lugares, então a pergunta que nós fazemos é será que tem algum jeito para isolar esse requisito não funcional, que é um teste de performance, em um único lugar?

E desse único lugar reutilizar em qualquer lugar, qualquer método que eu queira? Tem e é isso que nós vamos ver. O TypeScript fornece uma solução muito interessante para resolver esse tipo de problema.

Entendendo Decorators - TypeScript e Decorators

Bom, galera, o TypeScript possui um recurso de linguagem chamado decorator. Esse decorator me permite pegar esse código, por exemplo, o nosso código que checa performance, isolar esse código e colocar esse código em um único lugar e esse código pode ser aplicado em diversos lugares na aplicação.

Flavio, você está dizendo que esse código que eu preciso colocar um código, iniciar uma variável antes do miolo do método ser executado e outro no final do método a ser executado, isso pode ser violado em um código? Beleza, até entendi, mas como esse código vai ser aplicado no meu método?

É isso que nós vamos ver agora bem devagar. Então vamos entender como funciona esse decorator. A primeira coisa, para você não ficar assustado, é que o decorator é, nada mais, nada menos, que uma função. Então vamos começar lá dentro da pasta src.

Eu vou criar aqui a pasta "decorators" e dentro dela eu vou criar um decorator, o nome que eu vou usar vai ser logar tempo de execução. Vou renomear aqui, “new file > logar-tempo-de-execucao.ts”. Então está aqui o meu arquivo criado, é um arquivo ts, o que eu vou fazer? Sabemos que esse arquivo para o sistema de modus que estamos usando do ECMAScript é um módulo, então ele tem que exportar alguma coisa.

O que eu vou exportar? Eu vou dar export function e o nome da função que eu vou exportar, logarTempoDeExecucao, só isso, uma função que eu estou exportando. Flavio, você está dizendo que decorator é só isso? Não, tem mais, mas o princípio para nós entendermos é que esse decorator é declarado dessa forma.

Ainda está longe terminarmos esse decorator, mas o mais importante para entendermos é onde que eu quero usar esse cara? Eu quero usar tanto em view quanto no meu controller, então como é que essa função decorator, depois de pronta, como que pegamos ela e associa com o método que queremos analisar e executar um código? Esse código de performance ou qualquer outro que a gente vai ver ao longo do treinamento.

Eu vou voltar lá para o meu controller, negociação controller, onde tem o adicione, vou remover isso aqui, porque queremos que isso seja feito pelo decorator. O que eu vou fazer? Você vai chegar e eu vou importar aqui em cima do adiciona, vou colocar @logarTempoDeExecução. Fiz isso, abro e fecho parênteses, quando faço isso dá um erro, mas já vou explicar.

Primeira coisa que você vai verificar é se o seu import lá em cima, se ele importou logarTempoDeExecucao, descendo uma pasta ele foi para a pasta decorators. Verifica se o js está lá. Esse js precisa estar lá. Antes de terminarmos o decorator, você já sabe que o decorator eu uso essa sintaxe especial usando arroba ou at, no inglês, mais o nome da minha função decorator.

Como é uma função, estou abrindo e fechando parênteses, mas se eu passo o mouse aqui em cima, você vai ver que esse decorator ainda não está pronto. Nós precisamos continuar a implementar, porque ele não segue uma assinatura de um decorator real, mas o mais importante aqui, antes da implementação, é o seguinte, suponha que nós já implementamos esse decorator. Não vai funcionar.

Nós precisamos ativar uma configuração especial no compilador para garantir que os decorators sejam processados pelo TypeScript no momento da compilação do seu código. Então, recapitulando, estou tendo esse erro porque o meu decorator não está pronto, se eu estivesse com o decorator, pronto nem iria funcionar porque eu preciso deixar claro para o compilador TypeScript, quero que o TypeScript processe decorators no meu código e como faço isso?

Vou salvar, vou lá no centro nervoso do compilador TypeScript, que é o tsconfig.json e vou colocar uma propriedade aqui que é experimentalDecorators: true. Quando eu coloco eu estou dizendo para o TypeScript que eu vou usar decorators experimentais.

A primeira coisa que você pode estar pensando na sua cabeça é se você vai usar uma coisa experimenta. Não, isso é usado por angulares, isso é usado se você tem TypeScript react você pode usar também. É só porque a definição do API de decorator ainda não foi consolidada no mundo do Java Script.

Então o que estou dizendo para o TypeScript é usar a questão experimental, mas de experimental não tem nada, porque isso é usado em produção e por aí vai. Salvei, agora o meu compilador está com isso ativado e agora nós podemos voltar lá para logar tempo de execução. Só para garantir eu vou parar aqui o meu servidor e vou executar npm run start.

Só para ter certeza de que a configuração que eu passei para o decorator vai estar sendo executada aqui no meu código. É uma coisa importante para nós vermos, é que eu preciso fazer esse código compilar, vamos lá agora para o próximo vídeo que vamos terminar o nosso decorator.

Sobre o curso Typescript parte 3: mais técnicas e boas práticas

O curso Typescript parte 3: mais técnicas e boas práticas possui 197 minutos de vídeos, em um total de 57 atividades. Gostou? Conheça nossos outros cursos de JavaScript em Front-end, ou leia nossos artigos de Front-end.

Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:

• Entendendo Decorators
• Decorators de métodos
• Decorator de propriedade
• API externa e interface
• Mais sobre interfaces