This is in portuguese, wanna know why? Click here!
Deixa eu explicar primeiro para dar um contexto no que vamos tratar... Pegou? Contexto? Essa foi a única, prometo.
Mas então...
O que é contexto? E porque eu tenho que me importar com ele? E para onde ele vai?
Beleza, vamos imaginar que você tem a seguinte estrutura:
/* App.js */
const App = () => {
// Faz algo muito loco aqui e cria uma array para os menus
return (
<div>
<Menu lista={arrayDeMenus} />
{/*resto da sua aplicação*/}
</div>
);
};
/* Menu.js */
const Menu = (props) => (
<ul>
{props.arrayDeMenus.map(menu => (
<MenuItem icon={menu.icon}>{menu.nome}</MenuItem>
))}
</ul>
)
/* MenuItem.js */
const MenuItem = (props) => (
<li>
<i>{props.icon} </i>
<p>{props.children}</p>
</li>
)
Beleza, sacou o código né? Sabe o nome disso? Props Hell, ou traduzindo daquele jeito, Inferno de Propriedades, e aí? Como resolve isso? Vamos ficar parado e deixar para o próximo resolver isso?
Claro que não, já temos uma solução para isso, e ela se chama contexto, dessa forma a aplicação inteira pode se beneficiar dessa estrutura e somente quem precisa de algo acessa somente o que precisa.
Mas toma cuidado lindo, porque tu sabe né? Só coloca no contexto o que precisa, porque o contexto com 10mb de informação não ajuda o dispositivo do guri ali que tem um celular low end, então só usa o que precisa, deixa o mais liso possível.
Então vamos resolver o problema, mas agora usando o contexto?
Beleza então!
/* index.js */
export const ContextAPI = createContext();
const menu = [
{nome: "Perfil", icon: "😀"},
{nome: "Configurações", icon: "💻"},
{nome: "Sair", icon: "🔴"},
]
reactDom.render(
<ContextAPI.Provider value={menu}>
<App />
</ContextAPI.Provider>,
document.getElementById("root")
);
/* App.js */
const App = () => {
// Tua aplicação faz o que precisa e esquece do menu, porque ele já existe no index.js!
return (
<div>
<Menu />
{/*resto da sua aplicação*/}
</div>
);
};
/* Menu.js */
const Menu = (props) => {
const contexto = useContext(ContextAPI)
return (
<ul>
{contexto.map(menu => (
<MenuItem icon={menu.icon}>{menu.nome}</MenuItem>
))}
</ul>
)
}
/* MenuItem.js */
const MenuItem = (props) => (
<li>
<i>{props.icon} </i>
<p>{props.children}</p>
</li>
)
Como funciona, primeiro de tudo se cria um contexto, ali tá no index.js, tem um contexto criado, e veja só, esse contexto está lindão... Mas ele não tem NADA, isso mesmo NADA.
Mas o contexto então vai dar coisas para o resto da aplicação, ao renderizar o <App/> passamos o provedor e esse lindo aí do provider que irá ter um value, e nesse value é que colocamos o que o contexto vai deixar disponível.
No menu usamos um hook ali bonitão, e esse useContext vai receber um contexto, que está no index e vai colocar como a referência de qual contexto receber a informação. Como o contexto tem uma array, já pode sair usando ela.
Então, viu? O App passa completamente despercebido pelo contexto, então, basicamente a informação pulou do index para o Menu, isso é lindo? Eu sei, eu sei. Mas calma, isso é só o começo.
Beleza, quer algo mais legal? Bora fazer um hook de contexto custom? Bora fazer esse contexto ficar ainda mais dinâmico e brincar com um wanna be redux no meio caminho?
Saca esse aqui então:
/* index.js */
reactDom.render(
<CustomContext>
<App />
</CustomContext>,
document.getElementById("root")
);
/* context.js */
const InitialState = {
menu: [
{ nome: "Perfil", icon: "😀" },
{ nome: "Configurações", icon: "💻" },
{ nome: "Sair", icon: "🔴" },
],
};
const AppContext = createContext(InitialState);
const CustomContext = ({ children }) => {
const [state, dispatch] = useReducer(reducer, InitialState);
return (
<AppContext.Provider value={{ state, dispatch }}>
{children}
</AppContext.Provider>
);
};
/* reducer.js */
const reducer = (state, { type, payload }) => {
switch (type) {
case "MENU":
return {
...state,
menu: [...state.menu, payload],
};
default:
return state;
}
};
/* useActions.js */
const useActions = () => {
const { state, dispatch } = useContext(AppContext);
const anotherMenu = async (menu) => {
dispatch({ type: "MENU", payload: {menu, icon: "🤯"}});
return;
};
return {
state,
anotherMenu,
};
};
/* App.js */
const App = () => {
const { anotherMenu } = useActions();
// Se tua cabeça não explodir eu não sei o que vai fazer!
return (
<div>
<Menu />
<button
onClick={() => anotherMenu("Cooontexto")}
>
Novo Menu
</button>
{/*resto da sua aplicação*/}
</div>
);
};
/* Menu.js */
const Menu = (props) => {
const { state } = useActions();
return (
<ul>
{state.menu.map((menu) => (
<MenuItem icon={menu.icon}>{menu.nome}</MenuItem>
))}
</ul>
);
};
/* MenuItem.js */
const MenuItem = (props) => (
<li>
<i>{props.icon} </i>
<p>{props.children}</p>
</li>
);
Tá beleza, duplica essa aba aqui e coloca o código lado a lado que a pancada na mente é forte! Bora então e vamos com cuidado e por partes, beleza?
Primeira coisa, temos o contexto, ele vai ser apenas um preparação de campo, ele vai dar o início nesse trem aqui. Ele é responsável por dar o estado inicial da aplicação, então coloca ali tudo o que não precisa carregar de forma externa.
Ele também vai envelopar o index da aplicação para poder passar o contexto.
Agora vem a segunda parte, o reducer, esse aqui é perigoso, mas tu precisa entender o que ele faz direito, senão dá ruim. Certo então, vamos lá entender o que isso aqui faz.
Mimimimi, tem um switch case aqui!
Tem sim e vai ficar, eu também reclamei, tu vai reclamar, e vai engolir essa calado. Estamos entendidos? Beleza, mais pra frente tu vai entender porque precisa do switch aqui. Mas ele é para saber qual alteração de estado deve ser feita.
No momento tem apenas o "MENU", mas pode (e provável que vá) ter várias, algumas dezenas de alterações de estado.
Mas o que ele altera? Ele vai mudar a informação de maneira síncrona com o estado da aplicação. Então NADA DE FAZER FETCH AQUI! Pensou no async await, também não rola isso é só açúcar sintático para operações assíncronas. Ficou claro? Certo, se precisar usar o reducer para limar informação, alterar ela, converter de string para number, faz tudo aqui. Ele é responsável por atualizar o estado da aplicação.
Repara que ele sempre TEM que retornar o estado, beleza, se retornar null toda a aplicação quebra. Então olha o que faz no reducer!
Ok, vamos a parte legal, o nosso hook. Reparou no nome? Tem o use na frente não tem? Baaaah tchê garoto, primeiro hook custom que coloca para frente, chega a dar um orgulho que só!
Então, o que o useActions faz? Ele vai conceder ações para a aplicação. Ou seja, se quer alterar o contexto da aplicação usa uma ação para alterar esse estado. Essa função do useActions vai retornar várias funções para o usuário brincar, ele também retorna o estado, vai que precisa receber o estado não é mesmo?
Então é aqui que o mundo assíncrono acontece, aqui pode usar FETCH, pode usar await, pode fazer promise, faz o câmbal aqui, pode dar o louco forte e sair girando. Mas entenda uma coisa: usa o dispatch para atualizar o estado da aplicação.
Então já entendeu né. Fez o fetch, recebeu informação do backend, larga um dispatch para atualizar o estado. Mas repara, o dispatch precisa receber sempre um object com duas coisas (pode ter mais, só que aí tu se complica fazendo isso). Quais coisas?
type e payload, então já sabe, usa o type para passar para o que vai bater no switch, e quando o reducer pegar o switch certo ele vai colocar a informação do payload dentro do estado. Belezura, mas como vamos usar?
Olha que lindo, no App e Menu já usamos isso. Manja essa, no App rodamos o useActions() para receber a função que altera o estado, e no Menu rodamos novamente para receber o contexto da aplicação.
Fala sério, tu nunca pensou que iria fazer um redux em tão pouco né? E manja mais essa, tudo em hooks porque somos tudo fino e elegante nesse Javascript.
Por hoje é isso, tem aí material até não aguentar mais o buxo. Ficou com vontade de copiar tudo isso? Beleza, pega esse snippet aqui e guarda a mansa.
Curtiu né, achou que tava brincando né!
(()=>{})()
Top comments (0)