Je suis en train d'apprendre la gestion des états dans Vue.js et je ne comprends pas très bien pourquoi cela doit être si compliqué et déroutant avec toutes ces différentes méthodes (mutations, getters, setters). N'est-il pas plus simple de modifier directement les données? Cela n'a-t-il pas l'air plus clair?
Qu'est-ce qui ne va pas avec l'utilisation d'un code simple comme celui-ci? Qu'est-ce que j'oublie ici? Sauf que je dois définir store: window.store dans chaque composant. Est-ce que je peux le faire en toute sécurité ou est-ce absolument nécessaire pour moi d'utiliser Vuex?
// global app data
window.store = {
appName: 'Hello World!'
}
export default {
template: `
<div @click="changeAppName">Hellow {{ store.AppName }}</div>
`,
data()
{
return {
store: window.store
}
}
methods: {
changeAppName() {
store.appName = 'Reactive app name!'
}
}
};
3 Réponses :
Une fois que vous aurez une application plus grande qui communiquera les uns avec les autres composants, les états du magasin, etc., vous serez si heureux que vous ayez fait un effort pour créer ces getters et setters < / fort>.
Si vous créez un projet qui est petit, simple PWA ou que vous ne faites que déconner, alors oui, cela peut sembler déroutant et inutile. Mais une fois que ce petit projet est devenu plus dépendant des composants, qui dépendent des états de Vuex (pensez à utiliser Vuex, vous n'en avez pas besoin, mais vous saurez quand vous en aurez besoin).
Une fois que vous avez créé des getters et des setters et que vous aurez ce modèle dans toute l'application, le code sera propre, facile à lire pour chaque programmeur qui voudra vous aider à maintenir le projet.
Amusez-vous avec Vue.
Tout d'abord, une citation du documentation Vuex :
Quand dois-je l'utiliser?
Bien que Vuex nous aide à gérer la gestion de l'état partagé, cela entraîne également le coût de plus de concepts et de passe-partout. C'est un compromis entre la productivité à court et à long terme.
Si vous n'avez jamais construit de SPA à grande échelle et que vous vous lancez directement dans Vuex, cela peut sembler verbeux et intimidant. C'est parfaitement normal - si votre application est simple, tout ira très bien sans Vuex. Un modèle de magasin simple peut être tout ce dont vous avez besoin. Mais si vous construisez un SPA de moyenne à grande échelle, il y a de fortes chances que vous ayez rencontré des situations qui vous poussent à réfléchir à la manière de mieux gérer l'état en dehors de vos composants Vue, et Vuex sera la prochaine étape naturelle pour vous. Il y a une bonne citation de Dan Abramov, l'auteur de Redux:
"Les bibliothèques de flux sont comme des lunettes: vous saurez quand vous en aurez besoin."
Quand et si vos composants deviennent très gros parce qu'ils ont de nombreux états différents et font beaucoup de mutations d'état différentes, il devient de plus en plus difficile de raisonner sur leur code et de les maintenir ou de les étendre. C'est à ce moment que le découplage du stockage d'état et de la modification du composant lui-même devient intéressant.
Prenons également le cas où plusieurs composants peuvent déclencher les mêmes actions ou mutations. Dans ce cas, il devient évident que ce dernier doit être extrait dans un objet / classe / fichier commun pour éviter de dupliquer la logique. Une fois que vous êtes arrivé à ce point, vous vous approchez déjà très près d'une structure de type Vuex.
De plus, une application qui communique avec une API backend impliquera des appels asynchrones ajax, une gestion des erreurs, etc. Si tout cela est placé dans le même fichier que le composant, il sera très long et encore difficile à lire et à comprendre.
L'extraction de toutes les mutations dans un module Vuex séparé les rend faciles à tester de manière isolée sans avoir à instancier les composants Vue réels qui les utilisent. Les composants Vue peuvent alors être (principalement) purement liés à la logique d'affichage et à la réaction aux événements.
Comme vous pouvez le voir, il s'agit de donner à votre application une meilleure structure. Toutes ces raisons s'additionnent dans une application plus grande pour la rendre beaucoup plus facile à maintenir.
Enfin, Vuex ajoute des fonctionnalités intéressantes comme le suivi de l'état et la restauration avec le plugin Devtools Vue.js. Cela permet d'inspecter l'état à tout moment de l'exécution de l'application et aide à comprendre toutes les modifications qui y sont apportées. Voir ci-dessous pour une capture d'écran.
En bref cependant, pour répondre à votre question: non, Vuex n'est pas absolument nécessaire et il doit être utilisé lorsque cela a du sens car il peut apporter plus de verbosité injustifiée dans certains cas.
Depuis que j'ai écrit ceci, j'ai en fait réduit la quantité d'état que je stocke dans VueX. Je l'utilise toujours, mais pas pour l'état all . Je garde l'état qui n'est pas censé vivre plus longtemps qu'une "page" (ou route) donnée directement dans le composant parent "page" et je le transmets à travers les propriétés. Étant donné que cet état est automatiquement supprimé avec le composant qui le possède, cela me libère de la gestion des entrées obsolètes dans le magasin et réduit l'utilisation totale de la mémoire pour les longues sessions dans l'application.
Quelques lectures intéressantes:
C'est ce que je cherchais. Merci pour l'explication claire.
Si vous avez de l'expérience en programmation orientée objet, ce modèle devrait vous être familier. Pour que vous puissiez vous fier à vos données de manière centralisée.
Et bien sûr, vous pouvez le faire comme vous l'avez mentionné, mais ce n'est pas un style propre et peut ne pas être mis à l'échelle.
Et voici un plugin appelé vuex pathify pour faire de tout cela un beaucoup plus facile mais c'est difficile à comprendre si vous ne savez pas comment fonctionne vuex.
Vuex est complètement facultatif car il n'est vraiment utile que lorsque vous avez un état plus grand / partagé dans votre application. Vuex est "comme des lunettes: vous saurez quand vous en aurez besoin" .
avec
toutes ces différentes méthodesvoulez-vous dire js.methods ou parlez-vous des concepts (état, mutations, actions, getters + modules)? Parce que je trouve que 3 concepts (modulesest juste un espace de noms pour les 4 anciens,stateque vous devez faire de toute façon) pour être un petit "prix" à payer étant donné la puissance qu'il fournit .Veuillez envisager d'accepter les réponses à vos questions . Beaucoup de vos questions n'ont pas de réponse acceptée.