Eu tenho seguido o conselho amplamente dado de aprender o desenvolvimento React primeiro componente de masterizaçãoprops, encapsulando o estado da interface do usuário no nível do componentethis.state e transmiti-lo seletivamente através da árvore de componentes. Tem sido uma experiência esclarecedora. Apreciei o poder do padrão de design de exibição sem estado e sinto que consegui obter resultados robustos e bem organizados usando essas técnicas.

Seguindo em frente, agora estou tentando incorporar um gerenciamento de estado mais sofisticado usandoredux. Mas enquanto eu percorro a complexidade e integroredux nos meus aplicativos, encontro-me confrontando as seguintes observações sobre como meu código evoluiu. Alguns desses desenvolvimentos parecem sensatos, mas outros me fazem questionar se estou fazendo as coisas 'certas'.

1) Criadores de ação como o nexo de negócios e lógica da interface do usuário

Acho que grande parte da lógica que foi implementada anteriormente nas funções do ciclo de vida do ReactcomponentDidUpdate etc., e emonTouch/onPress manipuladores, agora é implementado emcriadores de ação. Este parece ser um desenvolvimento positivo, pois mantém 'tudo no mesmo lugar' e permite testes de unidade.

Pergunta, questão: É uma prática recomendada concentrar a lógica de negócios em uma rede de criadores de ação bastante intricados?

2) Escavadoreducers

Como corolário do item 1 acima, acho que meureducers e sua correspondenteaction Os objetos evoluíram para uma lista de fato de setters que fazem pouco mais do que atualizar o armazenamento de estado com os valores passados, desta maneira:

case types.SAVE_ORDER: 
  return Object.assign({}, state, {
    order: action.order,
  });

Uma grande parte da razão para isso é quereducers deveria serfunções puras e, portanto, sou limitado no que posso fazer com eles (por exemplo, sem processamento assíncrono). Além disso, os redutores só podem operar em suas respectivas subseções do estado da loja. Dado que grande parte da complexidade do meu aplicativo já reside necessariamente nocriadores de ação, Acho difícil justificar a migração arbitrária da complexidade parareducers simplesmente para fazê-los parecer úteis.

Pergunta, questão: É normal e prática aceitável ter clichêreducers que funcionam meramente como setters glorificados para o estado de armazenamento redux?

3)redux-thunk em toda parte

Eu perguntei separadamente no SO por queredux-thunk é até necessário (em vez de chamar criadores de ação padrão dentro de funções de utilidade / retornos de chamada assíncronos). Eu fui apontado para issoresponda por Dan Abramov, que fornece uma explicação muito satisfatória (em relação à escalabilidade, renderização no servidor e muitas outras razões).

Tendo aceitado a necessidade deredux-thunk, Acho que a maioria dos meuscriadores de ação precisa executar ações assíncronas, precisa acessargetStateoudispatch várias alterações no estado. Como resultado, voltei 'thunksextensivamente.

Pergunta, questão: É normal que um aplicativo redux dependa extensivamente dethunkcriadores de ação e raramente acionam uma ação de objeto padrão diretamente?

4) Redux como globalthis.state

Na análise final, parece que meu aplicativo estáredux loja evoluiu para se assemelhar efetivamente a umthis.state. Você pode pensar nisso como manter todo o estado do aplicativo emthis.state no componente mais externo do contêiner, mas sem a bagunça inevitável resultante da passagem do referidostate através de camadas aninhadas depropse quaisquer alterações fazem backup da árvore de componentes por meio de um ninho de ratosmanipulador funções.

Pergunta, questão: ÉRestaurado a ferramenta c, orrect a ser usada em um armazenamento de estado global? Existem alternativas por aí que se comportam mais comoreagirembutidothis.state, permitindo que um estado global do aplicativo seja propagado através de componentes de reação sem estado e atualizado de todo o aplicativo por meio de um 'painel de controle' centralizado, sem a aparentemente interminável rede de clichês, constantes eswitch declarações que acompanham a adoçãoRestaurado?

5) Um único tipo de ação? Esta pergunta de acompanhamento é inspirada em um dos comentários postados.

Pergunta, questão: Poderíamos legitimamente (com toda a seriedade, não apenas demonstrando descaradamente um ponto) usar o redux com exatamente um tipo de ação?

Exemplo - Criador de ações:

export function someActionCreator(various_params){
  return (dispatch, getState => {
    // ... business logic here ....
    asyncIfThisIfThat().then(val => {
      dispatch({
        // type: 'UPDATE_STATE', // Don't even bother setting a type 
        order: val
      })
    })
  )
}

O único redutor universal:

export default function app(state = initialState, action = {}) {
  return Object.assign({}, state, action)
  // Just unconditionally merge into state!
}

Parece-me que isso forneceria um objeto de estado com escopo global que é mapeado automaticamente paraconnectcomponentes avançados e que se beneficia de todas as vantagens do estado imutável e interoperável com o Reactprops. Nesse esquema,dispatch efetivamente se torna um globalsetState.

Nota - Por favor, não tome esta pergunta errada - isso certamente não é uma crítica aRestaurado. Como aluno, obviamente não estou em posição de julgar uma tecnologia apoiada na experiência de milhares e no apoio de milhões. Não tenho dúvidas de seu valor no contexto certo.

Estou apenas sentindo o cheiro de um padrão questionável em meu próprio código e me perguntando o que, se algo está fazendo de errado, ou se estou usando a ferramenta certa para a tarefa.