Redux continua sendo uma das bibliotecas mais comentadas no ecossistema de front-end, e por um bom motivo. Sua previsibilidade nos permite escrever aplicativos que se comportam de forma consistente em todas as plataformas (cliente, nativo e servidor), é facilmente depurável e funciona com qualquer camada de IU.
Mas a conversa em torno do Redux nem sempre é positiva; de fato, a equipe do Redux lançou o Redux Toolkit no ano passado em resposta a muitas das críticas persistentes contra isto. Apesar disso-ou talvez por causa disso-uma série de novas alternativas para gestão de estado surgiram, levando à conclusão de que o Redux pode finalmente estar de saída.
Você já conhece a posição que este post assume com base no título-não, Redux não está morto. Em defesa dessa posição, abordaremos o seguinte:
Por que usar Redux?
No desenvolvimento de software, onde há um problema, podemos ter certeza que alguém criará uma solução em breve. O problema que o Redux foi criado para resolver é o gerenciamento de estado.
No React, podemos ter um estado global em um componente de nível superior. Este componente de nível superior passa o estado para baixo como adereços para os componentes, ou seja, os componentes filhos, que requerem os dados.
class App extends Component { construtor () { super() this.state={ amigos: [ {nome:'Victor', idade: 22}, {nome:'Matt', idade: 30}, {nome:'Kate', idade: 40} ], } } render () { const allFriends=this.state.friends.map (amigo=> amigo.nome) Retorna ( Amigos
); }
}
No exemplo de código acima, o componente filho FriendList recebe os dados allFriends como props. Também pode ser transmitido mais uma vez. (Eu sei que não deveria fazer isso em um componente de aula em 2021, mas você entendeu.)
O estado no componente de nível superior sempre pode ser atualizado. Um componente filho atualizaria o estado global recebendo uma função do componente superior para atualizar.
class App extends Component { construtor () { super() this.state={ amigos: [ {nome:'Victor', idade: 22}, {nome:'Matt', idade: 30}, {nome:'Kate', idade: 40} ], searchField:'' } } onSearchChange=(evento)=> { this.setState ({searchField: event.target.value}) } render () { const filterFriends=this.state.friends.filter (amigo=> { return friend.name.toLowerCase (). includes (this.state.searchField) }) Retorna ( Amigos
); }
}
No código de exemplo acima, nosso estado searchField é sempre atualizado usando a função onSearchChange e passado para o componente SearchBox .
Esta é a aparência de nossa SearchBox recebendo a função para uma atualização:
const SearchBox=({searchChange})=> { Retorna ( );
}
Todo esse detalhamento e lidar com o componente C obtendo dados do componente A se torna um incômodo quando seu aplicativo fica maior.
Houve argumentos recentes de que não precisamos estritamente do Redux, mas a verdade não é tão clara. Você não percebe que precisa do Redux até criar um aplicativo para o qual o gerenciamento de estado não é tão simples.
Dan no Twitter: “Eu gostaria de corrigir isso: não use Redux até que tenha problemas com o vanilla React Veja https://t.co/RhzRGzEIe0 @ CamJackson89/Twitter ”
Eu gostaria de corrigir isso: não use o Redux até que tenha problemas com o Vanilla React. Veja https://t.co/RhzRGzEIe0 @ CamJackson89
Na mesma linha, Pete Hunt, um ex-membro da equipe React, também disse , “ Você saberá quando precisar do Flux. Se você não tem certeza se precisa, você não precisa. ” Se você não tem certeza se precisa do X, não precisa dele.
Então, para recapitular, devemos usar Redux se:
- Nosso estado será atualizado com freqüência; aqui, Redux fornece “uma única fonte de verdade”
- Nosso aplicativo tem muito estado necessário em muitos componentes
- Nossa função/lógica para atualizar o estado será complicada
Assim como qualquer outra ferramenta, o Redux também tem suas desvantagens e desvantagens.
Alternativas para Redux
Antes de mergulharmos nas alternativas do Redux, deve ficar claro que existem diferentes arquiteturas para gerenciamento de estado. Todos esses padrões foram usados com React e outras bibliotecas de IU para gerenciar o estado e seu fluxo de dados.
Os três padrões, perfeitamente resumidos neste tweet de Ilham Wahabi, são atômico, proxy e fluxo.
Atômico
Esta arquitetura é semelhante à que o React usa para a API de contexto e useState . Este padrão permite que você crie seu estado como um átomo e os divida em átomos menores, ao contrário do armazenamento do Redux, que é um grande contêiner de todos os estados.
Jotai é um exemplo que usa essa arquitetura. Vamos dar uma olhada em um exemplo de código.
importar {atom} de'jotai' const countAtom=atom (0)
const friendAtom=atom ('Matt')
const friendsAtom=atom (['Victor','Matt','Kate'])
O estado acima é dividido em pedaços menores e tratado como um átomo. Usar um átomo específico em seu componente ficará assim:
import {useAtom} de'jotai' Const Friend=()=> { const [amigo]=useAtom (friendAtom) Retorna ( {amigo}
Recuo é outra alternativa Redux que usa a arquitetura atômica.
Proxy
Este padrão usa o objeto JavaScript Proxy para acessar o estado. Proxy envolve um objeto e modifica os comportamentos tradicionais do objeto. Seu objetivo principal é criar um comportamento personalizado ou redefinir os operadores fundamentais.
MobX e Valtio são duas bibliotecas de gerenciamento de estado populares que usam essa arquitetura. De acordo com Valtio , ele transforma o objeto que você passa para ele em um proxy autoconsciente.
import {proxy, useSnapshot} de'valtio' const bio=proxy ({idade: 23, nome:'Victor'})
Faça alterações no estado de qualquer lugar em seu aplicativo:
bio.friends={nome:'Matt'}
bio.friends.amount={número: 1}
Ou faça uma cópia dos dados do proxy a serem usados para renderização:
função
Bio () { const snap=useSnapshot (bio) Retorna ( {snap.name} )
}
Valtio força você a ler o instantâneo e alterar sua fonte. O componente com certeza irá renderizar novamente a parte do estado que sofreu mutação.
Fluxo
A arquitetura Flux é usada por Redux e Zustand. Este padrão tem vários componentes que são vinculados para lidar com o estado: as ações, despachante, armazenamentos e visualizações do controlador.
Usaremos Zustand como exemplo; não é tão grande quanto o Redux e tem muito menos clichê.
importar criar de'zustand' const useStore=create (set=> ({ meuNome:'Victor', idade: 23, amigos: 0, aumentar Amigos: ()=> definir (estado=> ({amigos: estado.amigos + 1})), perderAllFriends: ()=> definir ({amigos: 0})
}))
Zustand considera nossa loja um gancho. A palavra-chave set combina o estado em useStore .
Usar o estado em nosso componente é muito fácil.
função
BearCounter () { const bears=useStore (state=> state.bears) retorne {bears} por aqui...
} function Bio () { const name=useStore (state=> state.myName) const boostFriends=useStore (state=> state.increaseFriends) Retorna ( Eu sou {name}
)
}
Com base em sua arquitetura, as alternativas mencionadas acima-Jotai, Recoil, Zustand e Valtio-têm diferentes métodos de gerenciamento de estado e, de muitas maneiras, surgiram como uma resposta ao padrão usado pelo Redux. Dependendo dos seus requisitos, seu aplicativo pode se beneficiar do uso da abordagem atômica (Jotai ou Recoil) ou até mesmo da abordagem de fluxo com Zustand em vez de Redux, graças à sua API mínima.
Equívocos comuns do Redux
Redux tem muitos clichês desnecessários
Redux tem recebido muitas críticas da comunidade JavaScript, não apenas por causa de seu código “clichê”, mas por causa de sua curva de aprendizado. Muitos desenvolvedores não percebem que o Redux usa um padrão de design que requer muito código clichê: a arquitetura de fluxo, que usa seus componentes individuais para gerenciamento de estado.
O Flux usa o componente de ação (método) para passar dados para o despachante. O despachante obtém as ações e ajuda a redistribuir a propriedade que mantém o estado em seu retorno de chamada. Essa propriedade é o que conhecemos como carga útil .
Então, a loja atua como nosso contêiner de estado e lógica, que está vinculado aos callbacks. Todas essas operações exigem muitos clichês. Mesmo aqueles que criticam Redux pela quantidade de clichês têm que admirar essa arquitetura.
Redux é um exagero
O próprio Dan Abramov não escondeu o fato de que você provavelmente não precisa do Redux para o seu projeto. Eu diria que você só precisa do Redux quando seu aplicativo aumenta e se torna complexo; um aplicativo menor ou um projeto pessoal provavelmente poderia se dar bem com a API de contexto.
Falando em API de contexto, ela funciona bem quando você precisa compartilhar dados de estado global-não há necessidade de passar dados como acessórios o tempo todo para cada componente. Na verdade, às vezes isso é suficiente, e uma solução sofisticada de gerenciamento de estado externo como o Redux é um exagero. Devemos deixar claro, entretanto, que Context não é uma solução de gerenciamento de estado, mas uma maneira mais fácil de levar dados para um componente aninhado.
Da mesma forma, algumas pessoas alegaram que Redux está morto porque a API Hooks do React já é perfeitamente capaz de lidar com o estado, especialmente quando usado junto com a API de contexto . Isso não é totalmente falso, mas muito dessa reação é resultado do estresse da perfuração da hélice. Se você não quer ter que perfurar componentes, Redux não deve ser sua escolha.
Meu ponto é que muitas das críticas contra Redux são o resultado de equívocos como esses. Muitos desenvolvedores usam o Redux mal ou quando não é necessário. É melhor entender seu projeto antes de escolher Redux.
O futuro do Redux
De muitas maneiras, o futuro é agora graças ao Redux Toolkit (RTK). Este kit de ferramentas ajuda com a abundância de código clichê que o Redux oferece por padrão, fornecendo uma configuração de loja simplificada, redutores e ações. Ele também inclui todos os pacotes comumente usados junto com o Redux para que não tenhamos que instalá-los todos individualmente-pacotes como Reselect, Redux Thunk, Immer e muito mais.
Instalar este kit de ferramentas é fácil:
# Em seu aplicativo React já existente, execute um desses comandos # npm
npm install @ reduxjs/toolkit # Yarn
yarn add @ reduxjs/toolkit
As APIs que o RTK fornece são createStore () , createReducer () , createAction () e createSlice () , que ajudam a simplificar o código clichê do Redux. Esta é uma melhoria no desenvolvimento do Redux.
createSlice () cria seus redutores e ações para você e também os conecta. React-Redux também tem as APIs useDispatch e useSelector agora, o que significa que você pode se conectar às ações de despacho e armazenar sem ter que usar um HOC.
Na minha opinião, Redux nunca vai a lugar nenhum nos próximos anos porque se encaixa muito bem no React. Não há confiança ou dependência de nenhuma dessas bibliotecas; React será usado no lado da visualização de seu aplicativo, enquanto Redux lida com o estado.
Hooks and the Context ainda não fornecem tanto poder quanto Redux em termos de gerenciamento de estado. Na verdade, foi claramente explicado que eles não são uma verdadeira solução de gerenciamento de estado. Eles são apenas provedores de estado-você ainda precisa fornecer a lógica nos componentes.
Redux emprega uma arquitetura pub/sub: seu componente é registrado para mudanças de estado, e o componente também pode publicar mudanças de estado usando o envio. Você pode tentar empregar a API de contexto neste cenário, mas provavelmente acabará tendo que usar o Redux. Existem histórias em primeira mão sobre como usar o Context para gerenciamento de estado pode matar o desempenho do aplicativo .
A questão é que Redux oferece mais do que gerenciamento de estado. Desde o padrão de design até a fácil manutenção e escalabilidade conforme o aplicativo cresce, você pode desacoplar sua lógica de gerenciamento de estado de sua camada de IU. O Redux ainda é útil, ainda tem um futuro e definitivamente não está morto.
A postagem Redux não está morto apareceu primeiro em LogRocket Blog .
