Il s’agit d’une notion qui existe à la fois dans VueJS et dans Angular (et dans React d’ailleurs). Dans VueJS, on parle de VueX, dans Angular de NgRx.

Notez le « x » contenu dans ces 2 termes fait référence à la « programmation réactive ».

La programmation réactive

Pour se représenter ce qu’est la programmation réactive, on peut penser au petit badge de notification qu’on voit sur tous les smartphones et beaucoup d’applications telles que Facebook et autre. Comment font ces badges pour indiquer le bon « chiffres »

Exemple : Quand on voit ²³ sur sa boîte mail, on sait qu’il y a 23 messages non lus et qu’en lisant chacun des messages, on verra se numéro décrémenter au fur et à mesure. On peut supposer qu’en cliquant pour lire son message, cela fait appel à une fonction qui décrémente le numéro. Si on passerait en « non lu » le message, une autre fonction incrémenterait à nouveau ce numéro.

Mais imaginez la complexité si ce chiffre dépendait d’une centaines voir de milliers d'autres utilisateurs ou alors d’autres fonctionnalités en correlation, cela deviendrait ingérable et beaucoup trop complexe à maintenir. Facebook s’est retrouvé dans cette même problématique pour laquelle le chiffre qu’ils affichaient était tout simplement faux et donc on investit des millions de dollars pour corriger le tir.

Ainsi, la solution à tout ceci, ce serait non pas de changer le numéro, mais que ce soit le numéro "lui-même" qui reste à l’écoute d’un énorme flux de données…

Tiens cela me fait penser aux observables tout ça…

Exact ! Il s’agit plus globalement de la programmation réactive.

Les stores, ça fait référence à magasin ?

Pour gérer cet énorme flux de données (dépend de la taille de son appli évidemment), on utilise donc un store. Il faut imaginer un store comme une sorte de base de données dans lequel on ne va pas stocker que des données mais également les « états » de ces données. C’est très pratique, car cela nous permet de conserver ainsi l’historique de l’évolution de ces données, un peu comme dans gitHub.

Donc si je comprends, un store sera un peu comme un mix de Git et base de données ? 

On peut voir cela comme un grand magasin avec une gestion du stock de toutes les informations utiles pour son application.

Fonctionnement dans VueJS

Dans VueX, le store est composé de states, mutations et actions.

• Les states vont déclarer un « état » et y associer un « jeu de donnée » qu’on souhaiter « stocker »
• Les mutations vont se charger de transformer cet état en modifiant les données
• Ces mutations sont appelées par les actions par la fonction commit 

=> Au final, notre composant « dispatch » une action et récupère le nouvel état par un « getter »

Cette vidéo explique très bien son fonctionnement

Fonctionnement dans Angular

Dans Angular, le principe est le même avec Ngrx composé d'actions, reducers et effects

(Attention ! Le terme « actions » ici se réfère aux states de vueJS et « effects » aux actions de VueX, faux amis)

Ce qui rend les choses plus complexe dans Angular, c'est la notion d'observable étroitement liées. Ainsi, on utilisera fréquemment la librairie Rxjs pour modifier nos données à l'intérieur même de l'observable avant qu'elles ne soient récupérées par le composant.

FAQ

1. Pourquoi toutes cette complication pour alors qu’au final c’est juste une variable qui change de valeur ?

On pourrait très bien s’en sortir si toutes les données étaient immutables (comme une chaîne de caractère, un entier, etc.), mais les objects, tableaux, etc ne le sont pas. Lorsqu’on change la valeur dans un objet quelque part, c’est l’ensemble des objets qui sont affectés, puisque l’ordinateur utilise des « pointeurs » dans la mémoire.

Ce mécanisme permet de rendre immutable n’importe quoi et également de disposer d’une liste centrale de ces « variables »

2. Qu’est-ce qui va me faciliter la vie de programmeur hormis la problématique du badge de notification de facebook évoqué tout à l’heure ?

• Déjà, on peut avoir l’historique de l’évolution de nos variables, cette « timeline » qui est proposée par certains outils comme « ngrx/store-devtools » est très utile pour le développement.
• Ensuite, tout ceci est réactif, ce qui fait qu’on peut appliquer ceci non seulement à un badge, mais à l’ensemble de l’application. Imaginez une application collaborative, comme un chat par exemple, les messages pourront apparaître instantanément au moment où la personne à l’autre bout de la terre l’écrit (bien entendu, cela implique que le serveur aussi fonctionne de manière « reactive », par socket par exemple, mais c’est un autre sujet)
• Enfin, lorsqu’on souhaite communiquer d’un composant à l’autre, c’est souvent la croix et la bannière. Dans Vue par exemple, j’utilise les props et le $emit pour communiquer avec ses composants parent-enfant. Avec Angular, j’utiliserai l’équivalent @Input @Output. Mais comment faire si on avait un composant plus éloigné, c’est ingérable. Là, pas de souci, à n’importe quel moment, je « souscris » à mon store et je récupère simultanément tous mes changements de données et je fais réagir mon appli en fonction, magique !

3. En bref, le store c’est la vie, mais cela demande de plus coder. Donc faut-il systématiquement en avoir un ? 

Je dirais tout dépend de la taille et des fonctionnalités de son application...