Stratégie recommandée pour synchroniser l'état de vuex avec le serveur
Imaginez ce cas simple. Vous avez une Vue application JS dans laquelle les utilisateurs peuvent créer des listes de tâches et les trier. Ces listes doivent être stockées dans une base de données par le serveur. Supposons que nous avons un ListComponent qui fait l'essentiel de l'UX.
Ma question est, quel modèle dois-je utiliser pour gérer la synchronisation des données frontale et principale?
A) Passer par vuex: Stocker les listes actives (celles affichées, éditées ou créées) dans le vuex store. Le ListComponent changera le store et puis , les modifications apportées à une liste seront envoyées au backend via une API.
B) Aller directement au serveur: Lire et écrire directement à partir du ListComponent sur le serveur chaque fois qu'une liste est affichée, modifiée ou créée.
Si vous suivez A, quelle architecture le magasin devrait-il avoir? comment et quand dois-je lancer une synchronisation? Comment puis-je suivre ce qui a changé et ce qui n'a pas changé?
Les deux peuvent être corrects selon votre cas d'utilisation. L'application que je construis actuellement utilise les deux.
Quand utiliser B: allez directement au serveur Utilisez B si les données sont très importantes à sauvegarder. Dans ce cas, vous souhaiterez peut-être accéder directement au serveur et diffuser la réponse pour vérifier qu'elle a été validée dans la base de données. Nous utilisons ce processus pour les modifications de type administrateur. Notez que vous pouvez également mettre à jour Vuex après la réponse du serveur et toujours utiliser Vuex pour servir vos données.
Quand utiliser A: passez par Vuex Utilisez A si vous avez besoin d'une expérience plus rapide, car il n'y a pas d'attente pour le serveur. Vous devez être d'accord avec l'affichage optimiste des modifications avant d'enregistrer réellement. L'autre avantage est que vous pouvez synchroniser Vuex vers localStorage . Nous l'utilisons pour les préférences de l'utilisateur qui sont utilisées pour personnaliser les vues. C'est une mauvaise expérience de ralentir la page juste pour attendre de les récupérer.
Comment utiliser A: passez par Vuex Il y a plusieurs façons de le faire. Voici un modèle:
- Dispatch Vuex Action 1 du composant
- Validation de la mutation Vuex à partir de l'action qui met à jour l'état - il s'agit d'une mise à jour optimiste car vous supposez qu'elle passera
- Envoyer une autre action Vuex 2 à partir de l'action 1 - Cela suppose que vous réutiliserez cette action dans plusieurs actions, sinon tout peut aller dans l'action 1
- L'action 2 envoie des données au serveur
- Au retour de la promesse, Action 2 commet une mutation pour mettre à jour l'état de Vuex
- La mutation doit gérer toute divergence (ou erreur)
Comptez le coût de Vuex
Comme le montre votre commentaire, il est bon de compter le coût si vous avez besoin d'utiliser Vuex, car cela ajoute beaucoup de frais généraux et de complexité. L'idéal est d'écrire vos composants de manière à contenir toutes les interactions avec un seul type de données (comme les "listes") afin de ne pas avoir à partager l'état via Vuex.