Eu só queria adicionar algumas diferenças pragmáticas de quando fiz o código RxJS inspirado no Redux.
Mapeei cada tipo de ação para uma instância de Assunto. Cada componente com estado terá um Assunto que é mapeado em uma função redutora. Todos os fluxos do redutor são combinados com o estado merge
e, em seguida, scan
geram a saída. O valor padrão é definido startWith
logo antes de scan
. Usei publishReplay(1)
para estados, mas posso removê-lo mais tarde.
A função de renderização pura de reação será apenas para o local onde você produz dados de evento enviando todos os produtores / assuntos.
Se você tem componentes filhos, precisa descrever como esses estados são combinados com os seus. combineLatest
pode ser um bom ponto de partida para isso.
Diferenças notáveis na implementação:
Sem middleware, apenas operadores rxjs. Acho que esse é o maior poder e fraqueza. Você ainda pode pegar conceitos emprestados, mas acho difícil obter ajuda de comunidades irmãs como redux e cycle.js, uma vez que é outra solução customizada. É por isso que preciso escrever "eu" em vez de "nós" neste texto.
Sem opção / caso ou strings para tipos de ação. Você tem uma maneira mais dinâmica de separar ações.
rxjs pode ser usado como uma ferramenta em qualquer lugar e não está restrito ao gerenciamento de estado.
Menos número de produtores do que tipos de ação (?). Não tenho certeza sobre isso, mas você pode ter muitas reações nos componentes pai que ouvem os componentes filho. Isso significa menos código imperativo e menos complexidade.
Você possui a solução. Nenhuma estrutura necessária. Bom e mau. Você vai acabar escrevendo seu próprio framework de qualquer maneira.
É muito mais fractal, e você pode facilmente assinar as alterações de uma subárvore ou de várias partes da árvore de estado do aplicativo.
- Adivinha o quão fácil é fazer épicos como o redux-obseravble fazem? Muito fácil.
Também estou trabalhando em benefícios muito maiores, onde os componentes filhos são descritos como fluxos. Isso significa que não precisamos completar os estados pai e filho nos redutores, já que podemos apenas ("apenas") combinar recursivamente os estados com base na estrutura do componente.
Eu também penso em pular o react e ir com snabbdom ou outra coisa até que o React trate melhor os estados reativos. Por que devemos construir nosso estado para cima apenas para quebrá-lo por meio de suportes novamente? Vou tentar fazer uma versão 2 desse padrão com Snabbdom.
Aqui está um trecho mais avançado, mas pequeno, onde o arquivo state.ts constrói o fluxo de estado. Este é o estado do componente do formulário ajax que obtém um objeto de campos (entradas) com regras de validação e estilos CSS. Neste arquivo, usamos apenas os nomes dos campos (chaves do objeto) para combinar todos os estados dos filhos no estado do formulário.
export default function create({
Observable,
ajaxInputs
}) {
const fieldStreams = Object.keys(ajaxInputs)
.map(function onMap(fieldName) {
return ajaxInputs[fieldName].state.stream
.map(function onMap(stateData) {
return {stateData, fieldName}
})
})
const stateStream = Observable.combineLatest(...fieldStreams)
.map(function onMap(fieldStreamDataArray) {
return fieldStreamDataArray.reduce(function onReduce(acc, fieldStreamData) {
acc[fieldStreamData.fieldName] = fieldStreamData.stateData
return acc
}, {})
})
return {
stream: stateStream
}
}
Embora o código possa não dizer muito isoladamente, ele mostra como você pode construir o estado para cima e como pode produzir eventos dinâmicos com facilidade. O preço a pagar é que você precisa entender um estilo diferente de código. E adoro pagar esse preço.