Pour Vue.js vs React vs Angular, les trois ont l'air de se valoir, mais Vue.js semblait « plus propre », être plus agréable à utiliser, et avoir moins de casseroles d'après les moult tests que j'ai lus. Mais c'est très subjectifs (et j'aime pas le concept de JSX de React).
L'utilité et l'intérêt d'un state management pattern et d'une bibliothèque comme VueX est à peu près incompréhensible tant qu'on a pas joué avec de la programmation réactive (et de fait, je ne l'ai pas compris avant d'avoir testé et compris Vue.js).
En gros : ton framework de programmation réactive (j'ai utilisé Vue.js, mais de ce que j'en sais React et consorts fonctionnent pareil) va te permettre de découper ton application en composants. Chaque composant va par défaut gérer les données d'état et l'affichage d'un bout de l'application. C'est très pratique en terme de découpage, mais d'un point de vue « intégrité des données » ça va avoir deux inconvénients :
Les données d'état vont être naturellement éparpillées dans toute l'application, ce qui rends l'état de l'application très rapidement incompréhensible et imprédictible.
Tu as très vite fait de mettre à jour ton état depuis X points d'entrée (c'est d'autant plus facile que JS est souple et permet de faire plein de trucs, donc tu peux très rapidement mettre à jour un objet partagé en pensant qu'il n'était qu'à toi). Et avec X > 1, tu auras forcément un moment ou quant tu veux mettre à jour ton état, tu dois aussi faire le traitement A, mais ce traitement ne sera fait qu'à partir du point d'entrée X1 mais pas X2. Et bim ! État incohérent !
Donc, un outil comme VueX (ou Flux, Redux et leurs amis) te permet de corriger tout ça :
Tu centralises l'état de ton application,
Tu garantis la cohérence de cet état en t'interdisant de le mettre à jour par d'autres moyens que des méthodes clairement identifiées1.
Entre autres effets de bord sympathiques, ça permet de tracer en dev toutes les modifications sur l'état de ton application, et donc de voyager dans le temps.
Voilà, j'espère que c'est plus clair comme ça ?
En réalité dans VueX, pour des raisons de langage tu ne peux pas forcer l'interdiction de modification, et les avertissements « attention cet objet a été modifié en douce hors des procédures » n'est actif qu'avec une configuration spécifique. Qui doit donc impérativement être activée en dev (sinon c'est idiot) et désactivée en prod (sinon c'est lent). ↩
[^] # Re: Et vue.js alors?
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal 8 mois avec Javascript (ES6) et vue.js : mon retour d'expérience du développement front en 2018. Évalué à 9. Dernière modification le 09 novembre 2018 à 16:54.
Pour Vue.js vs React vs Angular, les trois ont l'air de se valoir, mais Vue.js semblait « plus propre », être plus agréable à utiliser, et avoir moins de casseroles d'après les moult tests que j'ai lus. Mais c'est très subjectifs (et j'aime pas le concept de JSX de React).
L'utilité et l'intérêt d'un state management pattern et d'une bibliothèque comme VueX est à peu près incompréhensible tant qu'on a pas joué avec de la programmation réactive (et de fait, je ne l'ai pas compris avant d'avoir testé et compris Vue.js).
En gros : ton framework de programmation réactive (j'ai utilisé Vue.js, mais de ce que j'en sais React et consorts fonctionnent pareil) va te permettre de découper ton application en composants. Chaque composant va par défaut gérer les données d'état et l'affichage d'un bout de l'application. C'est très pratique en terme de découpage, mais d'un point de vue « intégrité des données » ça va avoir deux inconvénients :
Donc, un outil comme VueX (ou Flux, Redux et leurs amis) te permet de corriger tout ça :
Entre autres effets de bord sympathiques, ça permet de tracer en dev toutes les modifications sur l'état de ton application, et donc de voyager dans le temps.
Voilà, j'espère que c'est plus clair comme ça ?
En réalité dans VueX, pour des raisons de langage tu ne peux pas forcer l'interdiction de modification, et les avertissements « attention cet objet a été modifié en douce hors des procédures » n'est actif qu'avec une configuration spécifique. Qui doit donc impérativement être activée en dev (sinon c'est idiot) et désactivée en prod (sinon c'est lent). ↩
La connaissance libre : https://zestedesavoir.com