E ai pessoal, tudo bem?

Continuando nossa série, agora que começamos a criar funcionalidade de verdade em nossa aplicação, vamos evoluir mais ela, adicionando um melhor controle do estado dela, inclusive persistindo as tarefas do usuário, por enquanto no storage do browser, pois se atualizamos a página, podemos ver que perdemos o que foi cadastrado ou alterado.

Apenas lembrando, o repositório do projeto está disponível em meu GitHub:

gustavobigardi/serie-react-todo-list
Repositorio contendo o aplicativo de exemplo Todo List, utilizado em minha série de artigos sobre React. - gustavobigardi/serie-react-todo-list

Componentizando

Podemos ver que nosso componente principal, além de grande, está com bastante lógica, inclusive de definição e alteração de estado. Ao componentizar nosso projeto, podemos ainda ter que gerar muito código extra para que dados cheguem a componentes em um nível mais fundo.

Vamos quebrar nosso App.js em vários componentes, facilitando a manutenção e testabilidade.

Primeiramente, precisamos identificar o que podemos quebrar em componentes. Validando a tela de nossa aplicação em execução, conseguimos identificar os seguintes componentes.

Identificando componentes para “quebrar” nossa aplicação em partes.

Podemos identificar na imagem acima, 4 componentes. Isso é algo até um pouco de interpretação, podendo quebrar em mais ou menos, mas para este exemplo, temos:

  • Componente lista de tarefas, em Azul: Este seria o componente contendo a lista de tarefas e a responsabilidade de iterar esta lista, renderizando o componente de tarefa.
  • Componente de tarefa, em Verde: Este é o componente que contém o texto da tarefa, sendo renderizado pela lista (componente em Azul) e com o componente de controles da tarefa.
  • Componente de controles da tarefa, em Vermelho: Este é o componente que contém os botões de Finalizar, Reativar e Remover tarefa. Este propaga um evento, quando um dos botões é acionado.
  • Componente principal, em Preto: Este componente contém a lista de tarefas, acesso a APIs e que passa estas informações renderizando o componente da lista de tarefas.

Vamos entender melhor como fica a responsabilidade de cada um ao quebrar nossa aplicação em componentes separados. Vamos começar pelos botões de controle. Para isto, vamos criar o diretório components dentro do diretório src, e dentro dele, criar o arquivo task-buttons.js.

Acho que vocês devem ter perguntado agora: “Espera! Cade a classe extendendo Component do React?” Podemos remover inclusive o import de Component no início do arquivo.

Calma… Ainda estamos criando o componente TaskButtons, mas como um componente Stateless, como apresentamos na Parte 2 desta série. Neste modelo, declaramos nosso componente como uma função, que recebe as propriedades do componente como argumentos da função. Dentro dela podemos definir constantes, funções e tudo mais, mas não temos o controle de estado como quando utilizamos um componente Statefull, declarado como uma classe que extende a classe Component.

Notem que cada botão faz uma chamada para seu respectivo evento, recebidos como propriedades do componente. Feito isso, podemos modificar no App.js para utilizar o novo componente, e já informando a task e eventos para ele, ficando como na imagem a seguir. Ah, não podemos esquecer no início do App.js de importar o componente.

Arquivo App.js modificado para utilizar o componente TaskButtons.

Notem que o restante do arquivo não mudou, apenas coloquei no lugar dos operadores ternários o nosso componente e passei como propriedades para ele a task atual e a referência dos métodos que criamos no App.js para cada um dos eventos que ele recebe como propriedades.

Agora, o exemplo acima não irá funcionar. Por que?

Precisamos corrigir como fazemos a chamada dos métodos. Devido a forma como o Javascript trata a referência para o objeto this, ao receber a chamada do evento completTask, por exemplo, o this não está no contexto da classe App. Para corrigir isso, alteramos os métodos que recebem os eventos, remvoeTask, completeTask e resetTask para arrow functions, que retornam uma segunda arrow function, cuja declaração tem o bind do this para a classe App.js. Com isso, ao tentar acessar o estado, ou mesmo chamar o método modifyTaskStatus (não modificado desta forma), o contexto do this estará correto.

Com isso, não precisamos utilizar o bind em todas as chamadas para os métodos ou ficar utilizando arrow functions dentro das propriedades onde escrevemos o uso do componente.

Ao executarmos novamente a aplicação, podemos ver que ela funciona exatamente como antes.

Aplicação funcionando com o novo componente TaskButtons.

Agora é sua vez

Vou deixar como “tarefa de casa” para que vocês façam a quebra dos demais componentes, o de tarefa e a lista de tarefas, lembrando que eles podem ser stateless components.

Enviem pull requests ou issues para o meu repositório no Github caso tenham dúvidas ou queiram conferir se está ok o que fizeram. Quem preferir também, fique a vontade de comentar aqui no artigo ou mesmo enviar uma mensagem privada em minhas redes sociais.

Na quarta parte do artigo, que vou publicar neste final de semana, vamos revisar o como estes componentes ficam e começar a trabalhar com o estado de nosso componente principal, o App.js, utilizando o Local Storage e aplicando o uso do Redux para gerenciar o estado.

Convite!!

Aproveitando, gostaria de deixar um convite a todos para o Visual Studio Summit 2019, em São Paulo nos dias 21/06/2019 e 22/06/2019, onde estarei apresentando o tema “Blazor, WebAssembly e o futuro do Browser“, com insights sobre o Blazor e como ele pode mudar a forma como construímos aplicações Web e o que temos de novidades com a transição de fase de experimental para preview.

Participe da maior conferência sobre desenvolvimento de software usando Visual Studio e obtenha insights valioso para os seus projetos de software.

Cupom de desconto: palestrante-gustavo (válido até 20/05).

Para mais informações em:
http://vssummit.com.br

Nos vemos lá!

E não percam a quarta parte da série, que será publicada neste próximo final de semana, onde vamos finalizar os componentes (revisar como ficam) e começar a colocar o Redux em nossa aplicação para ver como funciona o controle de estado.

Para receber notificações de novos artigos, inclusive desta série, acesse meu perfil aqui do Medium e me segue!

Um abraço a todos e até a próxima!