Dans les cours précédents, on a vu que chaque composant possède son propre modèle de données (via la propriété data
).
Il est cependant possible d'utiliser des données "externes" :
import
,Or, il est fréquent de créer/détruire dynamiquement des composants, notamment avec vue-routeur (qui sera abordé en TD 7), ou bien d'autres mécanismes vuejs. Quand un composant est détruit, ses données propres sont perdues mais pas celles dont la source est externe, à moins bien entendu que cette source soit un composant qui soit lui-même détruit.
Pour faire persister des données malgré la destruction des composants, il faut donc que ces données soient stockées dans un emplacement qui ne sera jamais détruit. Pour que ce principe soit pratique, il suffit que créer un "dépôt" central pour le modèle de données, auquel tous les composants de l'application ont accès, dès leur création.
L'autre avantage d'un dépôt central est de faciliter le passage d'information entre composants. En effet, faire passer des données entre 2 composants A et B frères nécessite :
Si la communication doit se faire entre cousins, c'est encore plus compliqué puisqu'il faut faire remonter les événements et descendre des props sur plusieurs niveaux. Un dépôt central évite totalement ce type de mécanisme puisqu'il suffit d'avoir une variable dans le dépôt contenant les données à communiquer.
Vuex permet de créer un tel dépôt, appelé le "store"
Sur le Web, il est souvent noté que vuex n'est pas adapté à de petites applications car son utilisation est "verbeuse", c'est-à-dire qu'il faut écrire beaucoup de lignes pour définir le dépôt central et les données qu'il contient.
Ce n'est pas totalement vrai : il est verbeux car il permet de créer un dépôt en suivant de bonnes règles de programmation.
Il est donc possible d'écrire en quelques lignes un objet contenant les données centralisées et d'importer cet objet dans tous les composants via import
.
Cependant, cela complique grandement le déboguage, notamment car on ne garde jamais trace des modifications qui sont faîtes directement sur les données.
Sans parler du fait que dans un environnement asynchrone tel qu'un navigateur, que se passe-t-il quand une fonction lit des données alors qu'une autre les modifie ?
Enfin, même s'il n'y a que quelques données à centraliser, le supplément de codage lié à Vuex n'est pas si grand.
Le seul désavantage est parfois la performance.
ATTENTION ! Ce n'est pas parce que l'on utilise Vuex que l'on va mettre toutes les données dans le store. Les composants peuvent toujours définir des variables locales (dans data
ou computed
).
Quand on crée un projet grâce à vue-cli, dans lequel on intègre vuex (via le menu de personnalisation de projet), un répertoire store
est créé avec un fichier index.js
dedans.
Ce fichier permet de définir le dépôt grâce à la création d'un objet Vuex.Store
.
Ce fichier est ensuite importé dans main.js
, afin que l'application ait accès au dépôt, que l'on appellera un store dans la suite.
Pour une utilisation basique de Vuex, seules 2 propriétés du store doivent être définies : state et mutations.
Le principe essentiel de Vuex est de :