Estrutura divertida de gerenciamento de estado Huex

1. Introdução

Eu sempre fiquei impressionado com quantas ações você precisa fazer para o gerenciamento de estado dos frameworks - descreva imediatamente o esquema, escreva mutações, comprometa-as ... Por que não tornar tudo o mais simples possível?)

Por que escrever código quando você não pode escrevê-lo?

(atualizado)
Apresento a vocês minha arte de meia hora - Huex !

Até o momento, a solução está disponível apenas na plataforma NodeJS, mas acho que será suficiente para a apresentação.

Isenção de responsabilidade: O Huex foi escrito por mim apenas para fins educacionais e de entretenimento e não afirma ser uma estrutura de pleno direito. E talvez afirme. Agora vamos.

Para que serve?

Tenha um único armazém de dados conveniente. Ser capaz de monitorar suas alterações. Ele se livrará de palavras incompreensíveis como "getters", "mutators", "actions", "commit", etc.

Como instalá-lo?

Até agora, apenas copiando este repositório.
Depois que o repositório é copiado, você precisa conectá-lo via package.json do seu projeto em algum lugar neste formulário:

"dependencies": { "huex": "file:../huex/" } 

Depois disso, ele estará disponível como um módulo huex.

Ou torne ainda mais fácil, como o dpr observou corretamente:
npm i -S https://github.com/vssenko/huex.git

Como usá-lo?

Tão natural e simples quanto possível. Vamos começar imediatamente com o código:

 //  huex. const Huex = require('huex'); //  . const storage = Huex(); //     - . storage.on('change:a', (e) => console.log(`Property "a" was changed: ${e.value}`)); //      . storage.a = 5; 

E isso é tudo. Em qualquer alteração \ configuração do campo de nosso armazenamento, dois eventos serão criados: alteração com dados {chave, valor} e alteração: chave com dados {valor}.
(atualizado)
E para objetos e matrizes aninhados, os eventos serão criados para o objeto aninhado e o pai.
O suficiente para criar projetos de qualquer complexidade.

Talvez algo mais?

Obviamente: você pode criar campos profundamente aninhados em movimento e nenhuma exceção será criada.

 const Huex = require('huex'); const storage = Huex(); storage.abcde = 5; 

E, é claro, os manipuladores de eventos também podem ser pendurados em todos os objetos aninhados.

(atualizado)

Talvez algo mais?

Sim Agora, o Huex trabalha não apenas com dados simples, mas também com objetos e matrizes, remodelando-os em repositórios Huex em movimento!

  sut.subSut = { a: 5 }; sut.on('change:subSut', (e) => { console.log(e.key); // subSut console.log(e.value.a) // 10 console.log(e.nested); // { key: 'a', value: 10 } }); sut.subSut.a = 10; 

Ainda mais exemplos estão disponíveis nos testes do projeto.

Qual é o problema?

Toda essa mágica é implementada através do Proxy . Esta não é a solução mais rápida e, em geral, eles não recomendam o uso da classe Proxy na produção.

(atualização)

Conclusão

Por dois ciclos de desenvolvimento (à noite), a comunidade JS possui outra estrutura interessante.
O que a Huex pode fazer:

• Inicializado a partir de objeto \ matriz
• Salvar valores por atribuição simples
• Acionar eventos ao mudar-se como um objeto ou como uma matriz
• Em movimento, refaça os objetos / matrizes gravados nos repositórios Huex
• Acionar eventos ao alterar um campo de objeto ou campo de matriz
• Em movimento, gere armazenamentos vazios ao acessar um campo inexistente (um recurso controverso, mas muito interessante)

O que a Huex não sabe como:

• Seja rápido :-). Embora, como Drag13 notou, ainda haja progresso em direção à velocidade do Proxy, de repente essa abordagem se tornará popular.