Cadre Huex Fun State Management

Présentation

J'ai toujours été étonné du nombre d'actions que vous devez faire pour la gestion de l'état des frameworks - décrivez immédiatement le schéma, écrivez les mutations, engagez-les ... Pourquoi ne pas tout rendre aussi simple que possible?)

Pourquoi écrire du code quand on ne peut pas l'écrire?

(mis à jour)
Je vous présente mon métier d'une demi-heure - Huex !

Jusqu'à présent, la solution n'est disponible que sur la plateforme NodeJS, mais je pense qu'elle sera suffisante pour la présentation.

Avertissement: Huex a été écrit par moi à des fins de divertissement et d'éducation uniquement et ne prétend pas être un cadre à part entière. Et peut-être qu'il prétend. Maintenant, allons-y.

À quoi ça sert?

Avoir un seul entrepôt de données pratique. Être capable de suivre leurs changements. Il se débarrassera des mots incompréhensibles comme "getters", "mutators", "actions", "commit", etc.

Comment l'installer?

Jusqu'à présent, juste en copiant ce référentiel.
Une fois le référentiel copié, vous devez le connecter via package.json de votre projet quelque part sous cette forme:

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

Après cela, il sera disponible en tant que module huex.

Ou rendez-le encore plus facile, comme l' a correctement noté dpr :
npm i -S https://github.com/vssenko/huex.git

Comment l'utiliser?

Aussi naturel et simple que possible. Commençons tout de suite avec le code:

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

Et c'est tout. A tout changement \ paramétrage du champ de notre stockage deux événements seront créés: changer avec les données {clé, valeur} et changer: clé avec les données {valeur}.
(mis à jour)
Et pour les objets et tableaux imbriqués, des événements seront créés pour l'objet imbriqué et le parent.
De quoi créer des projets de toute complexité.

Peut-être autre chose?

Bien sûr: vous pouvez créer des champs profondément imbriqués dès le départ, et aucune exception ne sera créée.

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

Et bien sûr, les gestionnaires d'événements peuvent également être suspendus sur tous les objets imbriqués.

(mis à jour)

Peut-être autre chose?

Oui! Désormais, Huex fonctionne non seulement avec des données simples, mais aussi avec des objets et des tableaux, en les transformant en référentiels Huex où que vous soyez!

  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; 

Encore plus d'exemples sont disponibles dans les tests de projet.

Quel est le problème?

Toute cette magie est implémentée via Proxy . Ce n'est pas la solution la plus rapide, et en général, ils ne recommandent pas d'utiliser la classe Proxy en production.

(mise à jour)

Conclusion

Pour deux cycles de développement (soirées), la communauté JS dispose d'un autre cadre intéressant.
Ce que Huex peut faire:

• Initialisé à partir de l'objet \ tableau
• Enregistrer les valeurs par affectation simple
• Déclencher des événements lors de sa modification en tant qu'objet ou tableau
• En déplacement, refaites les objets / tableaux qui y sont écrits dans les référentiels Huex
• Déclencher des événements lors de la modification d'un champ d'objet ou d'un champ de tableau
• En déplacement, générez des stockages vides lorsque vous accédez à un champ inexistant (une fonctionnalité controversée, mais très cool)

Ce que Huex ne sait pas comment:

• Soyez rapide :-). Bien que, comme l' a noté Drag13 , il y ait encore des progrès vers la vitesse du proxy, cette approche deviendra soudainement populaire.