Design Patterns: como eles se aplicam no React

Aryanne Silva - Mar 22 - - Dev Community

Você já deve ter ouvido falar sobre Design Patterns (“padrões de projeto”, em português) . Mas você sabe o que eles são? E o que são React Patterns e como eles se aplicam?

Primeiramente, o que são Design Patterns?

Design Patterns são soluções generalistas para problemas recorrentes durante o desenvolvimento de um software. Não se trata de um framework ou um código pronto, mas de uma definição de alto nível de como um problema comum pode ser solucionado. Para melhor aproveitamento do conteúdo neste artigo, sugiro que aprofunde seus conhecimentos sobre o termo.

Como o conceito pode ser aplicado ao React?

Para quem ainda não está familiarizado, o React é uma biblioteca front-end que utiliza a linguagem de programação JavaScript e tem como um de seus objetivos facilitar a conexão entre diferentes partes de uma página, portanto seu funcionamento acontece através do que chamamos de componentes.

Esses componentes são escritos utilizando JSX que, a grosso modo, é uma linguagem desenvolvida como uma mistura de HTML e JS. Seu objetivo é ser transposta para JS da maneira mais simplificada possível.

Seguindo pela explicação do tópico acima, React Patterns nada mais são do que a aplicação de um padrão (como o próprio nome já diz) na escrita dos seus componentes React!

O poder do React se deve aos seus recursos e à arquitetura robusta que ele oferece. Padrões de projeto são de fato o que dá a esta biblioteca sua extraordinária praticidade e utilidade. Eles facilitam a otimização e a manutenção do código.

Eles permitem que os desenvolvedores criem aplicativos flexíveis por natureza, ofereçam melhor desempenho e produzam uma base de código mais fácil de manter.

A utilização de patterns também auxilia a interagir com o DOM de forma mais consistente e performática, sem side effects indesejados e com uma interface clara a nível de engenharia.

A seguir alguns patterns mais utilizado em React:

Higher-order component pattern

Um componente de ordem superior (HOC, do inglês Higher-Order Component), é uma função que recebe um componente e retorna um novo componente. Um componente de ordem superior é semelhante a uma função de ordem superior do JavaScript; são funções puras com zero efeitos colaterais.

código com Higher-order component pattern

Provider pattern

O Provider Pattern (padrão de provedor, em uma tradução livre) no React é um padrão usado para compartilhar dados globais em vários componentes na árvore de componentes do React.

O padrão de provedor envolve um componente Provider — componente que provê o(s) dado(s) — que contém dados globais e compartilha esses dados na árvore de componentes no aplicativo usando um componente Consumer — que consome os dados providos.

O padrão do provedor não é exclusivo do React; bibliotecas como React-Redux e MobX também implementam o padrão de provedor.

O código abaixo mostra um exemplo de uma configuração do padrão de provedor para React-Redux:

código com Provider pattern

No React, o Provider Pattern também pode ser implementado através da API Context do React.

O React por padrão suporta um fluxo descendente unilateral de dados (imagem abaixo) de um componente pai para seus filhos. Consequentemente, para passar dados para um componente filho localizado muito abaixo na árvore de componentes, teríamos que passar explicitamente props por cada nível da árvore de componentes — esse processo é chamado de perfuração de props.

Aqui temos os componentes mapeados à esquerda e na direita podemos ver a árvore de dados.

A API Context do React usa o padrão de provedor para resolver esse problema! Assim, ela nos permite compartilhar dados na árvore de componentes sem ter que passar por cada componente na árvore até chegar o no componente filho que irá receber essas props.

Do lado esquerdo, estrutura onde precisamos passar a(s) prop(s) por cada componente. Já do lado direito utilizando Context API, sem ter que passar manualmente em todos os níveis.

Para usar a Context API, primeiro precisamos criar um objeto qualquer que será nosso “context”. O objeto vem com um componente que aceita um valor: os dados globais. O objeto também possui um componente Consumer que será utilizado para alterações de contexto. O componente Consumer então provê as informações mais recentes e atualizadas para o componente filho.

Abaixo demonstra um caso de uso típico da API Context do React:

código de API Context do React

A Context API (e gerenciadores de estados globais a grosso modo), são bastante utilizados na implementação de recursos como autenticado de usuário, tema ou idioma preferencial, onde os dados globais são compartilhados em uma árvore de componentes.

Hooks patterns

As APIs do React Hooks foram introduzidas no React 16.8 e revolucionaram a forma como construímos componentes no React.

A API React Hooks oferece aos componentes funcionais do React uma maneira simples e direta de acessar recursos comuns do React, como props, state, context, refs e lifecycle.

O resultado disso é que agora os componentes funcionais não precisam mais ser componentes “burros”, onde definem apenas aparência da aplicação e a interface de usuário, pois podem usar o estado, conectar-se a um ciclo de vida do componente, executar efeitos colaterais e muito mais a partir de um componente funcional. Antes, esses recursos eram suportados apenas por componentes de classe.

Hooks resolvem alguns problemas como “componentes gigantes”, que concentram uma enorme lógica dividida em vários métodos de ciclo de vida. Com o Hooks, esses problemas foram amenizados, fornecendo uma API mais limpa e enxuta. Exemplo de uma implementação utilizando Hooks:

código com Hooks patterns

Além das vantagens já citadas, o Hooks pattern promove a reutilização do código, permitindo-nos criar hooks reutilizáveis ​​e personalizados.

Conclusão

Os Design Patterns focam na reutilização de soluções. Apesar de todos os problemas não serem iguais, caso você os quebre e ache similaridades com os que já foram resolvidos anteriormente, é possível aplicar os Patterns e obter as soluções.

Projetar softwares que sejam de qualidade e, principalmente, reutilizáveis, não é uma tarefa fácil — mas os padrões estão aí exatamente para facilitar nessa missão.

Referências

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .