Autor Redux aqui!
Redux não é isso diferente de Flux. No geral, possui a mesma arquitetura, mas o Redux é capaz de reduzir alguns aspectos da complexidade usando a composição funcional, onde o Flux usa o registro de retorno de chamada.
Não há uma diferença fundamental no Redux, mas acho que isso torna algumas abstrações mais fáceis, ou pelo menos possíveis de implementar, que seriam difíceis ou impossíveis de implementar no Flux.
Composição do redutor
Tome, por exemplo, paginação. Meu exemplo do Flux + React Router lida com paginação, mas o código para isso é horrível. Uma das razões pelas quais é horrível é que o Flux torna natural reutilizar a funcionalidade nas lojas. Se duas lojas precisarem lidar com paginação em resposta a ações diferentes, elas precisam herdar de uma loja base comum (ruim! Você está se trancando em um design específico ao usar herança) ou chamar uma função definida externamente de dentro do diretório manipulador de eventos, que precisará operar de alguma forma no estado privado da loja Flux. A coisa toda é confusa (embora definitivamente no reino do possível).
Por outro lado, a paginação com Redux é natural graças à composição do redutor. São redutores até o fim, para que você possa escrever uma fábrica de redutores que gere redutores de paginação e depois usá-los em sua árvore de redutores . A chave para o fato de ser tão fácil é porque, no Flux, as lojas são simples, mas no Redux, os redutores podem ser aninhados por meio da composição funcional, assim como os componentes do React podem ser aninhados.
Esse padrão também permite recursos maravilhosos como desfazer / refazer código sem usuário . Você pode imaginar conectar Undo / Redo em um aplicativo Flux sendo duas linhas de código? Dificilmente. Com o Redux, é novamente, graças ao padrão de composição do redutor. Eu preciso destacar que não há nada de novo nisso - esse é o padrão pioneiro e descrito em detalhes na Elm Architecture, que foi influenciada pelo Flux.
Renderização do servidor
As pessoas estão processando bem no servidor com o Flux, mas, vendo que temos 20 bibliotecas do Flux tentando facilitar a renderização do servidor, talvez o Flux tenha algumas arestas no servidor. A verdade é que o Facebook não faz muita renderização de servidores, então eles não se preocuparam muito com isso e confiam no ecossistema para facilitar.
No Flux tradicional, as lojas são singletons. Isso significa que é difícil separar os dados para diferentes solicitações no servidor. Não é impossível, mas difícil. É por isso que a maioria das bibliotecas do Flux (assim como os novos Flux Utils ) agora sugerem o uso de classes em vez de singletons, para que você possa instanciar lojas por solicitação.
Ainda existem os seguintes problemas que você precisa resolver no Flux (você mesmo ou com a ajuda da sua biblioteca favorita do Flux, como Flummox ou Alt ):
- Se lojas são classes, como eu as crio e destruo com o despachante por solicitação? Quando registro lojas?
- Como hidrato os dados das lojas e depois os reidrato no cliente? Preciso implementar métodos especiais para isso?
É certo que as estruturas do Flux (não o Flux de baunilha) têm soluções para esses problemas, mas eu as acho complicadas demais. Por exemplo, o Flummox pede para você implementar serialize()
e deserialize()
em suas lojas . Alt resolve isso melhor, fornecendo takeSnapshot()
que serializa automaticamente seu estado em uma árvore JSON.
O Redux vai além: como existe apenas uma loja (gerenciada por muitos redutores), você não precisa de nenhuma API especial para gerenciar a (re) hidratação. Você não precisa "liberar" ou "hidratar" as lojas - há apenas uma loja e você pode ler o estado atual ou criar uma nova loja com um novo estado. Cada solicitação obtém uma instância de armazenamento separada. Leia mais sobre renderização de servidor com Redux.
Novamente, esse é um caso de algo possível, tanto no Flux quanto no Redux, mas as bibliotecas do Flux resolvem esse problema introduzindo uma tonelada de API e convenções, e o Redux nem precisa resolvê-lo porque não tem esse problema no primeiro lugar graças à simplicidade conceitual.
Experiência do desenvolvedor
Na verdade, eu não pretendia que o Redux se tornasse uma biblioteca popular do Flux - escrevi enquanto trabalhava na minha palestra ReactEurope sobre recarregar as baterias com viagens no tempo . Eu tinha um objetivo principal: tornar possível alterar o código do redutor em tempo real ou até "mudar o passado", cruzando ações e ver o estado sendo recalculado.
Não vi uma única biblioteca do Flux capaz de fazer isso. O React Hot Loader também não permite que você faça isso - na verdade, ele quebra se você editar as lojas Flux porque não sabe o que fazer com elas.
Quando o Redux precisa recarregar o código do redutor, ele chama replaceReducer()
e o aplicativo é executado com o novo código. No Flux, dados e funções são emaranhados nos repositórios do Flux, então você não pode “simplesmente substituir as funções”. Além disso, você teria que, de alguma forma, registrar novamente as novas versões com o Dispatcher - algo que o Redux nem tem.
Ecossistema
O Redux possui um ecossistema rico e de rápido crescimento . Isso ocorre porque ele fornece alguns pontos de extensão, como middleware . Ele foi projetado com casos de uso, como registro em log , suporte a promessas , observáveis , roteamento , verificações de desenvolvimento de imutabilidade , persistência etc., em mente. Nem todas serão úteis, mas é bom ter acesso a um conjunto de ferramentas que podem ser facilmente combinadas para trabalhar em conjunto.
Simplicidade
O Redux preserva todos os benefícios do Flux (gravação e reprodução de ações, fluxo de dados unidirecional, mutações dependentes) e adiciona novos benefícios (fácil desfazer refazer, recarregar a quente) sem introduzir o Dispatcher e o registro da loja.
Mantê-lo simples é importante, pois mantém você saudável enquanto implementa abstrações de nível superior.
Diferente da maioria das bibliotecas Flux, a superfície da API Redux é pequena. Se você remover os avisos, comentários e verificações de integridade do desenvolvedor, são 99 linhas . Não há código assíncrono complicado para depurar.
Você pode realmente ler e entender todo o Redux.
Veja também minha resposta sobre as desvantagens de usar o Redux comparado ao Flux .