A ideia desse texto é mostrar como eu solucionei um problema no React utilizando o

conceito de wrapper.

Conceitualizando

O termo wrapper vem do inglês envolver, isso mesmo, talvez você já deve ter comido um
wrap (que é uma massa envolvendo um recheio). No modo geral é um padrão de código
também chamado de Decorator e seu objetivo é envolver objetos que possuem
comportamentos semelhantes. Saiba mais sobre wrapper aqui.

Contextualizando

Não achei um nome interessante pra descrever essa feature, mas o contexto é simples:

Imagine uma aplicação que tem uma página de cadastro que irá redirecionar o usuário para
outra página, nesta outra página você deve fazer um componente aparecer e desaparecer
com o tempo, nesse componente mostrará informações e dados que vieram do cadastro. A
tela que será carregada poderá ser uma tela de perfil ou algum redirecionamento, ou seja,
qualquer página do app.

Dados de Contexto
(dados capturados do
cadastro)

Redirecionamento
(states reinicializados)

Captura
(dados do contexto da
página anterior)

É fácil notar que não há apenas um problema aqui, e como sempre, há mais de uma
solução. E a solução mais fácil a curto prazo seria criar o componente com delay e colocá-lo
em todas as páginas que precisam mostrar o componente com delay, um useEffect para
escutar um state do history ou algum dado de contexto e verificar se precisa mostrar ou não
assim que a página for renderizada. Quanto aos dados que precisam aparecer no
componente com delay, existem muitas soluções para isso.

Mas então, quais os problemas dessa solução?

Primeiramente, não é de responsabilidade das páginas redirecionadas mostrarem o

componente, e sim da página/componente de cadastro, seríamos obrigados a mapear todos
os possíveis redirecionamentos, dependendo do tamanho da minha aplicação poderia ser
um trabalho chato.

Outro problema seria decorrente do anterior, teríamos que “handlear” dados que não são de
responsabilidade direta da página em questão.

Criando um Delayed Page Wrapper

Para resolver o problema de forma mais elegante, criei um componente wrapper, que fica
no meu layout ou nas camadas mais externas da DOM, esse componente tem apenas uma
responsabilidade, escutar um evento e mostrar um componente na tela de acordo com
algumas configurações. Onde o evento pode vir de qualquer lugar e o componente também.
Mas não é tão simples quanto parece.

Assim que eu criei o wrapper eu me deparei com outro problema, o fluxo a seguir pode
facilitar o entendimento:

EventSyste
PÁGINA É m
RECARREGADA

Wrapper Wrapper não recebe o evento

pois a página foi recarregada

Cadastro Qualquer
Event.dispatch(dado outra
s);
navigate(redirect); página

Não importa a ordem em que eu disparo o evento, ele não vai chegar ao Wrapper após o
refresh da página.

Para lidar com esse problema eu tive que criar um store para o evento, na aplicação que eu
estava desenvolvendo estávamos usando MobX, então eu criei um eventStore para
armazenar os dados do evento e o fluxo foi dividido em duas partes:
 EventSyst
PÁGINA É em
RECARREGADA

Wrapper
// recebe dados do evento, armazena os dados e faz o
redirect
// no segundo render, verifica os dados e mostra o Delayed
Component
navigate(event.data.url);
Cadastro Qualquer
Event.dispatch(dad outra
os);
navigate(redirect) página
;

Agora o Wrapper é responsável por receber o evento e também por fazer o

redirecionamento, os dados do evento (url, informações, configurações, etc) são
armazenados no primeiro render, assim que o evento chega e antes do navigate.

Essa solução é bastante flexível pois permite o uso do Wrapper para outros objetivos que
envolvam disparar informações em outras páginas após redirecionamento baseado no
contexto da página anterior. Vale ressaltar também que o uso do EventSystem facilita mas
não é obrigatório, o Wrapper permite utilizar history.state, por exemplo, para “handlear” o
evento e a navegação.

Mas então, onde o conceito de wrapper está sendo usado? No nosso exemplo o Wrapper
vai servir como um encapsulamento para que os componentes filhos possam sempre ter
possibilidade de mostrar o que queremos, por que no nosso casulo (o wrapper) os
componentes podem disparar e receber eventos de navegação e pedir para mostrar as
informações que eu preciso sempre que necessário e utilizando o mesmo padrão, sem que
eu precise criar states e effects que não são responsabilidade deles.

Se você chegou até aqui agradeço imensamente por ter lido! Se gostou curte e compartilhe!
:D/