É possível sem o Redux?

Hoje você pode encontrar muitas posições em que é necessário reagir / redux. Reagir é ótimo, sem perguntas. A questão para o Redux é se é possível sem ele. Se você pesquisar um pouco no Google, há um artigo sólido sobre Habré , onde o autor faz a mesma pergunta. Em um artigo com um exemplo simples (todoList), o método this.updateViews () é chamado com muita frequência (sete a oito vezes) e parece mais fácil.

A idéia principal aqui é modelos observáveis, reagir é responsável por observáveis, a única coisa que resta é criar um modelo.

Antes de criar o modelo, algumas palavras sobre o design (arquitetura) do cliente:

índice - dados brutos
história - matriz [modelo]
observador - modelo
visualização - erros, foco, sinalizadores

index.jsx - ponto de entrada do programa para a tela do usuário. O índice renderiza todos os componentes com dados padrão, faz consultas assíncronas, redesenha componentes com novos dados.

// index.jsx <History> <Observer> <HeaderView /> <MainView /> </Observer> </History> 

O Observer.jsx é responsável por sincronizar o modelo para várias visualizações. Por exemplo, Petya preenche um formulário de oferta e vê a visualização em tempo real no cabeçalho da página. O Observer armazena o objeto de modelo, fornecendo api: onModelChange (campo, valor) para os componentes filhos.

History.jsx é uma pilha de objetos de modelo, em que api: commit e rollback.

Model.js é o que o usuário pode inserir com canetas - ou seja, as mais valiosas. Outros dados no modelo não precisam ser armazenados. O modelo não é um componente de reação, mas uma classe js regular.

 class Model { constructor(other = {}) {} // copy constructor (and default too) isEqual(other) {} // operator == less(other) {} // operator< swap(other) {} hash() {} fieldNameConstrains() {} //see below please } 

O construtor de cópia é pelo menos necessário para o History. O método isEqual é para alterações não salvas em pop-up (o que é muito mais conveniente que o sinalizador no estado). O método fieldNameConstrains é para campos dependentes.

Grosso modo, se houver campos dependentes, eles precisam ser alterados todos seguidos.

 class Model { // constrains // distance <== velocity * time velocityConstrains(newVelocity) { this.velocity = newVelocity; this.distance = this.velocity * this.time; } timeConstrains(newTime) { … } distanceConstrains(newDistance) { this.distance = newDistance; this.time = this.distance / this.velocity; } } 

Por experiência pessoal, algo como model.field.onchange não funciona, pois às vezes você precisa chamar o construtor de cópia e os eventos onchange não são necessários.

View.jsx

 class View extends React.Component { state = { errors: {}, focus: {}, … } render() { … <input value={this.props.model.title} onChange={e => this.props.onModelChange('title', e.target.value)} /> … } } 

Validação A validação não precisa ser feita no modelo. Isso deve ser feito em vista (não esqueça que a vista é a tela do usuário e que nem todo o modelo pode ser mostrado na tela). Validadores são um conjunto de predicados. Existem apenas dois algoritmos para validação: 1) encontramos todos os erros no formulário ou 2) encontramos o primeiro erro. Por exemplo

 class View extends React.Component { onClickSaveButton() { const mapper = { title: () => model.title.length && !maxLenValidator(model.title, 25), price: () => !(model.price % 40 == 0), url: () => !urlValidator(model.url), … } const errors = map(mapper, (validator, key) => { return validator() ? key : undefined; }).filter(Boolean); } //       

Direitos de acesso. A principal coisa aqui é ficar e não usar herança. A ideia é que o modelo contenha todos os campos e que os aparemos para funções. Ou seja, é uma lista de permissões, os campos restantes no modelo permanecem por padrão. Uma etapa é adicionada para validação - fazemos uma projeção do objeto de validação (também é mapeador, veja acima), ou seja, validamos apenas os campos necessários.

Sobre produção. Essa abordagem está girando em produção há um ano - é uma interface para a criação de campanhas publicitárias, incluindo banners. Formas de complexidade variável - variando de um modelo para a tela, terminando com muitos modelos de tipos diferentes. Aqui você pode adicionar que o back-end gosta de enviar estruturas aninhadas, não deve ser tímido e armazenar apenas estruturas planas na exibição.

Sobre o método do modelo isEqual. Em algum lugar no utils.js, haverá os métodos isEqual e isEqualArray:

  function isEqual(left, right) { return left.isEqual(right); } isEqualArray(v1, v2) { if (v1.length !== v2.length) { return false } for (var k = 0; k != v1.length; k++) { if (!isEqual(v1[k], v2[k])) { return false; } } return true; } 

Você precisa tentar não criar modelos aninhados. Não esqueça que o modelo é de dados do usuário, não uma estrutura de dados.

Referências:

→ Horários
→ dois