Respostas:
Autor Redux aqui!
Eu gostaria de dizer que você fará os seguintes compromissos com ele:
Você precisará aprender a evitar mutações. O fluxo não tem opinião sobre a mutação de dados, mas o Redux não gosta de mutações e muitos pacotes complementares ao Redux assumem que você nunca muda o estado. Você pode aplicar isso com pacotes somente para desenvolvedores, como redux-imutable-state-invariant , use Immutable.js ou confie em si e em sua equipe para escrever código não mutativo, mas é algo que você precisa estar ciente, e isso precisa seja uma decisão consciente aceita por sua equipe.
Você terá que escolher cuidadosamente seus pacotes. Embora o Flux explicitamente não tente resolver problemas “próximos”, como desfazer / refazer , persistência ou formulários , o Redux possui pontos de extensão, como middleware e aprimoradores de loja, e gerou um ecossistema jovem, porém rico . Isso significa que a maioria dos pacotes são novas idéias e ainda não receberam a massa crítica de uso. Você pode depender de algo que será claramente uma má idéia alguns meses depois, mas ainda é difícil dizer.
Você ainda não terá uma boa integração com o Flow. Atualmente, o fluxo permite fazer verificações de tipo estático muito impressionantes, às quais o Redux ainda não suporta . Vamos chegar lá, mas vai demorar um pouco.
Eu acho que o primeiro é o maior obstáculo para os iniciantes, o segundo pode ser um problema para os adotantes entusiasmados demais, e o terceiro é a minha irritação pessoal. Fora isso, não acho que o uso do Redux traga desvantagens particulares que o Flux evite, e algumas pessoas dizem que ele tem algumas vantagens em comparação ao Flux.
Veja também minha resposta sobre aspectos positivos do uso do Redux .
shallowEqual
verificação react-redux, é usado para determinar se o estado mudou. Mas pode ser substituído por deepEqual ou JSON.stringify e compare. Eventualmente, é um desempenho um pouco menor - mas são cálculos puros sem lidar com o DOM - tão rápido o suficiente. E em qualquer caso, tornando-se é o mesmo
O Redux e o Flux exigem uma quantidade considerável de código padrão para cobrir muitos padrões comuns, especialmente aqueles que envolvem a busca assíncrona de dados. A documentação do Redux já possui alguns exemplos de redução de clichê: http://redux.js.org/docs/recipes/ReducingBoilerplate.html . Você pode obter tudo o que precisa em uma biblioteca do Flux, como Alt ou Fluxxor, mas o Redux prefere a liberdade sobre os recursos. Isso pode ser uma desvantagem para alguns desenvolvedores porque o Redux faz certas suposições sobre o seu estado que podem ser inadvertidamente desconsideradas.
A única maneira de você realmente responder à sua pergunta é tentar o Redux, se puder, talvez em um projeto pessoal. O Redux surgiu devido à necessidade de uma melhor experiência do desenvolvedor e é direcionado para a programação funcional. Se você não estiver familiarizado com conceitos funcionais, como redutores e composição de funções, poderá ser mais lento, mas apenas um pouco. A vantagem de adotar essas idéias no fluxo de dados é o teste e a previsibilidade mais fáceis.
Isenção de responsabilidade: migrei do Flummox (uma implementação popular do Flux) para o Redux e as vantagens superam qualquer desvantagem. Eu prefiro muito menos mágica no meu código. Menos mágica custa um pouco mais de clichê, mas é um preço muito pequeno a pagar.
O Redux não é uma implementação pura do Flux, mas definitivamente inspirado no Flux. A maior diferença é que ele usa um único repositório que agrupa um objeto de estado que contém todo o estado do seu aplicativo. Em vez de criar lojas como você fará no Flux, você escreverá funções redutoras que mudarão um único estado do objeto. Este objeto representa todo o estado do seu aplicativo. No Redux, você obterá a ação e o estado atuais e retornará um novo estado. Isso significa que as ações são seqüenciais e o estado é imutável. Isso me leva ao golpe mais óbvio do Redux (na minha opinião).
Existem poucas razões para isso:
1. Coerência - o estado da loja está sempre sendo alterado por um redutor, para facilitar o rastreamento de quem muda o quê.
2. Desempenho - por ser imutável, o Redux precisa apenas verificar se o estado anterior! == estado atual e se for o caso. Não é necessário repetir o estado todas as vezes para renderização determinada.
3. Depuração - novos conceitos impressionantes, como depuração de viagens no tempo e recarga a quente .
ATUALIZAÇÃO: se isso não foi suficiente para convencer, assista a excelente conversa de Lee Byron sobre interfaces de usuário imutáveis .
O Redux exige uma disciplina do desenvolvedor através da base de código / bibliotecas para manter essa ideia. Você precisará escolher as bibliotecas e escrever o código de maneira não mutável.
Se você quiser saber mais sobre as diferentes implementações dos conceitos do Flux (e o que funciona melhor para suas necessidades), confira esta comparação útil.
Depois disso, devo admitir que o Redux é para onde o desenvolvimento futuro da JS está indo (como escrever essas linhas).
Um dos maiores benefícios do uso do Redux em relação às outras alternativas do Flux é a capacidade de reorientar seu pensamento em direção a uma abordagem mais funcional. Depois de entender como todos os fios se conectam, você percebe sua impressionante elegância e simplicidade no design e nunca mais pode voltar atrás.
Eu prefiro usar o Redux, pois ele usa uma loja que facilita muito a comparação entre o gerenciamento de estado e o Flux , também Redux DevTools , são ferramentas realmente úteis que permitem ver o que você está fazendo com o seu estado com alguns dados úteis e está alinhado com as ferramentas de desenvolvimento do React.
O Redux também tem mais flexibilidade usando outras estruturas populares como Angular . De qualquer forma, vamos ver como o Redux se apresenta como uma estrutura.
O Redux possui três princípios que podem introduzir o Redux muito bem e são também a principal diferença entre o Redux e o Flux.
Fonte única da verdade
O estado de todo o aplicativo é armazenado em uma árvore de objetos em um único armazenamento.
Isso facilita a criação de aplicativos universais, pois o estado do seu servidor pode ser serializado e hidratado no cliente sem nenhum esforço extra de codificação. Uma única árvore de estado também facilita a depuração ou inspeção de um aplicativo; também permite que você persista o estado do seu aplicativo em desenvolvimento, para um ciclo de desenvolvimento mais rápido. Algumas funcionalidades tradicionalmente difíceis de implementar - Desfazer / Refazer, por exemplo - podem se tornar triviais de repente, se todo o seu estado estiver armazenado em uma única árvore.
console.log(store.getState())
/* Prints
{
visibilityFilter: 'SHOW_ALL',
todos: [
{
text: 'Consider using Redux',
completed: true,
},
{
text: 'Keep all state in a single tree',
completed: false
}
]
}
*/
Estado é somente leitura
A única maneira de mudar o estado é emitir uma ação, um objeto que descreve o que aconteceu.
Isso garante que nem as visualizações nem os retornos de chamada da rede sejam gravados diretamente no estado. Em vez disso, eles expressam a intenção de transformar o estado. Como todas as mudanças são centralizadas e ocorrem uma a uma em uma ordem estrita, não há condições sutis de corrida a serem observadas. Como as ações são apenas objetos simples, elas podem ser registradas, serializadas, armazenadas e posteriormente reproduzidas para fins de depuração ou teste.
store.dispatch({
type: 'COMPLETE_TODO',
index: 1
})
store.dispatch({
type: 'SET_VISIBILITY_FILTER',
filter: 'SHOW_COMPLETED'
})
As alterações são feitas com funções puras
Para especificar como a árvore de estados é transformada por ações, você escreve redutores puros.
Redutores são apenas funções puras que tomam o estado anterior e uma ação e retornam o próximo estado. Lembre-se de retornar novos objetos de estado, em vez de alterar o estado anterior. Você pode começar com um único redutor e, à medida que o aplicativo cresce, divida-o em redutores menores que gerenciam partes específicas da árvore de estados. Como redutores são apenas funções, você pode controlar a ordem em que são chamados, transmitir dados adicionais ou até tornar redutores reutilizáveis para tarefas comuns, como paginação.
function visibilityFilter(state = 'SHOW_ALL', action) {
switch (action.type) {
case 'SET_VISIBILITY_FILTER':
return action.filter
default:
return state
}
}
function todos(state = [], action) {
switch (action.type) {
case 'ADD_TODO':
return [
...state,
{
text: action.text,
completed: false
}
]
case 'COMPLETE_TODO':
return state.map((todo, index) => {
if (index === action.index) {
return Object.assign({}, todo, {
completed: true
})
}
return todo
})
default:
return state
}
}
import { combineReducers, createStore } from 'redux'
let reducer = combineReducers({ visibilityFilter, todos })
let store = createStore(reducer)
para mais informações visite aqui
Até onde eu sei, o redux é inspirado no fluxo. flux é uma arquitetura como MVC (Model View Controller). o facebook apresenta o fluxo devido a um problema de escalabilidade ao usar o MVC. então o fluxo não é uma implementação, é apenas um conceito. Na verdade, redux é a implementação do fluxo.