DEV Community: Luiz Felipe Warmling Amadeu

Os Hooks que vieram junto com o React 18

Luiz Felipe Warmling Amadeu — Fri, 14 Oct 2022 15:26:38 +0000

O que são react hooks?

Hooks são os novos padrões que foram introduzidos na versão React 16.8. Os hooks do React deram vida a esses recursos que pudemos fazer nos componentes de classe, mas desta vez nos componentes funcionais. Isso significa que essas APIs do React Hooks podem nos ajudar a interagir com os estados locais do React, os recursos do ciclo de vida e muito mais.

Os React Hooks existentes e como os usamos

useEffect: Este hook ajuda a realizar os efeitos colaterais nos componentes funcionais, como atualizar o Dom e buscar dados. Ele aceita uma função que será executada por padrão toda vez que o componente renderizar novamente. Podemos parar esta renderização passando algumas condições no array de dependências que é o segundo argumento de useEffect.

useState: Este hook ajuda a usar e atualizar variáveis de estado em um componente funcional.

useRef: Este hook retorna um objeto ref mutável que contém uma propriedade .current que é usada para múltiplos propósitos.

useCallback: Este hook retorna uma versão memorizada do retorno de chamada somente se as dependências foram alteradas. A memorização é uma maneira de armazenar em cache um resultado, economizando assim o uso da memória.

useMemo: Este hook recalcula o valor memoizado somente quando uma das dependências é alterada e retorna o valor memoizado. Essa também é uma das maneiras de armazenar em cache um resultado.

useContext: Este hook aceitará o valor fornecido por React.createContext e. Isso só irá renderizar novamente o componente sempre que seu valor for alterado. Isso, portanto, ajuda a criar, fornecer e consumir o contexto.

useReducer: Este hook nos permite lidar com algumas manipulações e atualizações de estado complexas. Estamos muito familiarizados com o redux, este gancho é um pouco semelhante a isso. ele aceita uma função redutora e um estado inicial.

useLayoutEffect: é executado de forma síncrona após uma renderização, mas antes que a tela seja atualizada.

useDebugValue: Este hook ajuda a registrar informações importantes nas ferramentas de desenvolvimento criadas pelo React. Isso é recomendado para uso apenas para ganchos personalizados. Então agora temos um resumo dos ganchos que vieram antes do react 18.

Vamos passar agora para os novos ganchos do React 18

useId
useSyncExternalStore
useDeferredValue
useInsertionEffect
useTransition Agora vamos mergulhar nesses novos hooks

useId:
Este hook é útil onde precisamos usar alguns ids exclusivos. Dessa forma, o React provou que nos ajudará a gerar IDs exclusivos. Esses IDs exclusivos podem ser usados para conteúdo renderizado pelo servidor e pelo cliente. Isso evita até mesmo incompatibilidade na renderização do lado do servidor, o que pode causar problemas.
Outra maneira em que podemos pensar é quando criamos um formulário, podemos adicionar um sufixo/prefixo a esse id, por exemplo, id + firstName. Dessa forma, podemos ter vários ids exclusivos.

Código de exemplo:

useSyncExternalStore:
A partir do nome, este gancho esclarece que ajudará na sincronização com as fontes de dados externas. Podemos ler e assinar a partir de fontes de dados externas. Este é um gancho de biblioteca desenvolvido principalmente para os autores da biblioteca integrarem.

Como usar isso? Este método aceita três argumentos:

subscribe: É para registrar um callback que é chamado sempre que a store muda.
getSnapshot: Ele retorna o valor atual da store.
getServerSnapshot: Este é um parâmetro opcional e retorna o instantâneo usado durante a renderização do servidor. Este método retorna o valor da store

getSnapshot é usado para verificar se o valor subscrito mudou desde a última vez que foi renderizado, então o resultado precisa ser referencialmente estável. Isso significa que ele precisa ser um valor imutável, como uma string ou número, ou precisa ser um objeto armazenado em cache/memoizado.

useDeferredValue:
O hook rastreia um valor. Se o valor mudar de um valor antigo para um novo, o gancho pode retornar qualquer um dos valores. O benefício de usar useDeferredValue é que o React irá trabalhar na atualização assim que outro trabalho terminar

const [searchInput, setSearchInput] = useState(“”);
const searchInputDeferred = useDeferredValue(searchInput);
Aqui é criada uma versão adiada da entrada de pesquisa.

Veja este exemplo:

Amad3eu / Example_UseDeferredValue

Um exemplo simples de como useDeferredValue pode melhorar a experiência do usuário com a desaceleração intencional da interface do usuário.

useDeferredValue example

A simple example of how the useDeferredValue hook can be used to improve the experience of the UI on slower devices.

View on GitHub

useInsertionEffect:
Este hook deve ser usado por autores de bibliotecas css-in-js. Porém esse hook é limitado em escopo e não tem acesso a refs. O gancho é acionado antes de todas as atualizações do DOM. Para desenvolvedores, useEffect ou useLayoutEffect devem ser preferidos. Todos nós sabemos sobre o useLayoutEffect que é acionado antes de um useEffect que useInsertionEffect seja executado antes mesmo de useLayoutEffect.

useTransition
Como o nome indica, este hook ajuda nas atualizações de transição.

As atualizações de estado do React são basicamente de dois tipos. Uma delas são as atualizações de transição que são responsáveis pela transformação da interface do usuário. A outra é a deflexão que vemos como clicar, arrastar etc. O hook **useTransition **nos permite especificar algumas atualizações de estado como não tão importantes. Com isso, podemos dizer ao React para priorizar algumas atualizações mais baixas para atualizações mais priorizadas, e o aplicativo parece muito mais fácil de usar.

const [isPending, startTransition] = useTransition();- isPending é um booleano. É o React nos dizendo se essa transição está em andamento no momento. - startTransition é uma função. Vamos usá-lo para dizer ao React switch atualização de estado que queremos adiar.

Exemplo de transição de uso

Então, finalmente, temos uma visão geral desses recém-introduzidos React Hooks, acredite, esses hooks vão nos ajudar muito a aumentar o desempenho, ajudar no cliente eficiente, bem como na renderização do lado do servidor e nos dar mais controle sobre o React como um todo

Vamos começar a usá-los e ver a mágica. 🧙‍♂️🧙‍♂️🧙‍♂️

A importância da Clean Architecture

Luiz Felipe Warmling Amadeu — Sun, 04 Sep 2022 20:45:19 +0000

Ultimamente estamos ouvindo falar bastante sobre termos como "Clean Architecture", "Hexagonal Architecture", "SOLID", "DRY", "DDD", etc. Todos eles são princípios, práticas ou abordagens no mundo de desenvolvimento de software que, em essência, convergem para o objetivo de tornar o software mais robusto, escalável e flexível, deixando-o tolerante a mudanças, facilitando a implementação de novos requisitos para a evolução e manutenção do sistema.
Quando se fala em Clean Architecture temos algumas características como:

Arquitetura FOCADA nas regras de negócio: suas regras não devem conhecer o "mundo lá fora" (Frameworks, Ferramentas, Tecnologias, etc).
Inversão de dependências: Por exemplo, seu banco de dados deve depender das suas regras, e não suas regras do seu banco. Sua UI? Mesma coisa!
A melhor decisão é a que você pode tomar depois? Isso não é preguiça, é arquitetura incremental.
Regras de negócio devem ser 100% TESTÁVEIS e INDEPENDENTES!

O diagrama que utilizei na parte superior deste post, segundo Uncle Bob, é uma tentativa de integrar todos esses conceitos e boas práticas arquiteturas em uma única ideia.
Um sistema bem estruturado possui baixo acoplamento e alta coesão, portanto, uma das soluções encontradas é a divisão do sistema em camadas.
Surge então a Regra de Dependência que, acordo com a figura, nos mostra que a seta apenas segue para dentro, ou seja, a camada mais externa visualiza e utiliza a mais interna. O inverso não pode acontecer. Isso não faz com que o software fique dependente ou restritivo, muito pelo contrário, a aplicação dessa regra diminui as limitações do código o tornando organizado e acessível. Não ultrapassar essas barreiras é essencial para otimizar o funcionamento do sistema.

Entities

Na camada de entidades, deve ser alocada a lógica de negócio e as regras de alto nível. Essa camada pode ser usada por todas as outras, tendo em vista que possui regras mais gerais do software, ou seja, as entidades são usadas pelas classes mais externas.

Use Cases

Neste nível do software, cabe a aplicação das regras de negócio para cada caso. Estas são mais específicas e dizem respeito a validações por exemplo.

Interface Adapters

Esta camada tem uma função bem específica como todas as outras. Função esta que é converter as informações vindas das camadas internas (entidades+casos de uso) para o reconhecimento dos elementos pertencentes no próximo nível.

Frameworks and Drivers

Composta pelos elementos mais externos: Frameworks, Banco de dados, bibliotecas e derivações.

Aplicação prática

Para ilustrar como podemos aplicar o conceito de Clean Architecture na prática, trago aqui uma situação onde temos um projeto de API de cadastro utilizando a liguangem NodeJs e algumas bibliotecas como o Express, MongoDB, BCrypt para criptografia de senha e Validator para validar o e-mail recebido.
Sei que esse exemplo é de baixa complexidade, mas acredito que é suficiente para entender a abordagem proposta nesse post.
A imagem abaixo talvez represente a forma como geralmente estruturamos esse tipo de projeto quando não se conhece a abordagem arquitetural que estamos discutindo aqui.

Nesse cenário temos componentes como o SignUpController e SignUpRouter acloplados a biblioteca de terceiros, além de termos componentes que possuem muitas "responsabilidades". Se precisarmos em algum momento trocar o Express por outro framework, será necessário alterar todos os controllers.

Então para dar início a uma transformação na arquitetura do nosso sistema podemos iniciar focando em desacoplar nossos controllers do Express. Esse tipo de decisão em um cenário ideal deveria ser uma tarefa muito fácil. Mas aqui temos que essa biblioteca praticamente "toma conta" do sistema.

O SignUpController aponta para o Express por isso o primeiro passo seria usar o padrão de inversão de dependência (dependency inversion) para fazer com que o Express olhe para nossos controllers.

Para isso, podemos criar um adapter entre os dois que terá a tarefa de converter as interfaces do controller para a realidade do Express. Uma das particularidades do Express é que ele espera receber o (req, res) como parâmetros nas rotas definidas.

Também não podemos permitir que o adapter dependa diretamente do SignUpController. Devemos fazer com que ele possa adaptar qualquer controlador, assim, criamos uma camada Presentation e dentro dela uma interface Controller, que irá servir como um limite desta camada para fazer a inversão de dependência. O adapter precisa de qualquer classe que utilize a interface.

Com isso a dependência inverteu. Se eu precisar trocar, só altero o adapter.

Seguindo em frente, precisamos agora desacoplar a biblioteca para validar e-mail para que nosso presentation layer não dependa de um componente externo. Criamos um EmailValidatorAdapter semelhante ao adapter criado anteriormente.

Assim, em vez de o SignUpController depender diretamente desse adapter, definimos, ainda na camada de apresentação, uma nova interface EmailValidator que diz o que esse componente deve fazer e "alguém" de fora implementa a interface definida. Dessa forma desacoplamos e se outros controladores precisarem usar esse validador poderemos facilmente reutilizar o componente. Ainda temos o benefício de, se um dia optarmos por substituir essa biblioteca por uma regex por exemplo, alteraremos apenas um componente.

Podemos dizer que é nossa camada Utils que é mais genérica irá conter coisas que podem ser utilizadas em qualquer lugar.

Surge, então, a necessidade de uma camada de negócio que diga o que precisamos fazer. Pois para realizar um cadastro, precisamos salvar os dados no banco de dados, mas antes disso, queremos criptografar a senha do usuário.

Criamos então uma interface AddAccount que nada mais é do que a representação de uma camada de negócio da aplicação, a camada Domain. Essa camada não terá implementação, mas apenas protocolos que dizem o que nossa regra de negócio deve fazer.

Com isso, o SignUpController irá precisar de alguém que implemente essa interface para criar uma conta de usuário. Não importa se a implementação será com banco de dados, cache, ou dados "mockados", o que importa é que a implementação respeite a interface definida.

Assumindo que queremos a implementação da regra de negócio voltada para armazenamento em banco de dados, criaremos a Data layer que terá o componente DBA Account.
Esse sim irá utilizar o BCrypt para fazer a criptografia da senha do usuário. Mas não queremos acoplá-los diretamente. Assim como antes, criaremos o BCrypt Adapter para isolar os nossos componentes do BCrypt que uma biblioteca externa.
Ele ficará dentro da Infra layer, camada que terá implementações de interface voltadas para frameworks. E agora para realizar a inversão de dependência, criamos a interface Encrypter ainda na Data layer já que o DBA Account precisa de alguém que saiba fazer criptografia e não ele mesmo saber como faz.
Com isso a dependência inverteu novamente. O Infra layer que aponta para o Data layer e não o Data layer apontando para o Infra.

Para finalizar temos o a dependência com o MongoDb. Criaremos o componente AddAccountMongo Repository que sabe usar o mongo e criaremos também a interface AddUser Repo pois outros componentes podem precisar de "alguém" que saiba inserir no banco de dados, não importa qual.
Inversão de dependência feita mais uma vez.
Com isso as bibliotecas de terceiros estão cada vez mais isoladas, cada vez mais na camada mais "fora" da nossa arquitetura. Se futuramente quisermos trocar MongoDB, vamos alterar apenas um componente.

Realizamos até aqui transformações, com a ajuda do padrão de projeto Adapter, que removem o acoplamento entre as camadas. Mas para conseguir ter uma solução completa e desacoplar nossas camadas precisamos acoplar uma delas, e esta será a Main layer.
Ela será responsável por criar instâncias de todos os objetos. Exemplo: Para criar a rota de signup precisamos do SignUpController, que por sua vez precisa de alguém que implemente a interface AddAccount. Mas que sua implementação não será instanciada no controller.
"Alguém" irá criar essa instância e injetará no controller. O Main layer fará a composição desses objetos através de outro design pattern, o Composite, e toda composição será feita em um lugar só.

Abaixo está o desenho final desse exemplo, destacando com cores para melhor visualização das camadas. Acredito que tenhamos chegado bem próximo de um desenho arquitetural bem estruturado com baixo acoplamento e alta coesão. Observa-se que as dependências externas estão sempre nas "pontas" e facilmente podemos troca-las sem afetar o resto do sistema.

Considerações Finais

As ideias propostas por Uncle Bob, padronizam o desenvolvimento de software moderno.

Nota-se que os métodos sugeridos, se aplicados de maneira correta, organizam o código, facilita o trabalho em equipe, e entre outros benefícios. Isso não quer dizer que o Clean Architecture é uma "bala de prata" para desenvolver softwares. Ressalto aqui que sua aplicação deve ser avaliada de acordo com o tipo de projeto e suas particularidades.

Referências

Otavio Lemos
Rodrigo Manguinho em Clean React
MARTIN, Robert C. Clean Architecture: A Craftsman’s Guide to Software Structure and Design. 1st. ed. USA: Prentice Hall Press, 2017. ISBN 0134494164.