Fermer

mai 6, 2022

Que faire lorsque vous avez besoin d’une variable globale dans Vue 3


Parfois, lors de l’écriture d’applications, vous avez besoin qu’une donnée, généralement une variable, soit disponible dans l’ensemble de votre base de code, peut-être même via plusieurs instances de Vue. Existe-t-il donc une « meilleure pratique » pour faire face à ces situations ? Nous allons jeter un coup d’oeil.

Le scénario idéal

Dans un monde idéal (généralement ce que nous couvrons lors de la rédaction d’articles de blog comme celui-ci), vous avez affaire à un seul SPA contenu qui est construit par Vue CLI via webpack ou peut-être Vite. Ces scénarios sont idéaux car les solutions permettent de gérer un état global (hint, hint).

Chaque fois que vous avez besoin que vos données soient accessibles à tous vos composants, vous voudrez peut-être d’abord penser à intégrer un gestionnaire d’état global. Dans Vue 3, la solution officielle recommandée est Pinia ou alors Vuex.

Vuex était la solution incontournable pour n’importe quel état global dans Vue 2, et a depuis été mis à jour pour fonctionner avec Vue 3 et la nouvelle API de composition. Cependant, un nouvel outil est venu lui faire concurrence pour la place de notre gestionnaire d’état mondial, Pinia. Je recommande actuellement que tous les nouveaux projets, et même les anciens (lorsque vous pouvez vous permettre le temps de les migrer) utilisent Pinia. Après l’avoir utilisé même un peu, vous sentirez à quel point il est intuitif et modulaire et, plus important encore, à quel point il est moins encombrant et redondant que son homologue précédent.

Un état global fourni par ces bibliothèques vous permet de l’injecter dans n’importe quel composant de votre application, ce qui en fait un endroit idéal pour stocker toutes les variables globales.

Le scénario avancé, sans dépendance

Il peut arriver que vous ne soyez pas autorisé ou que vous ayez choisi de ne pas inclure une dépendance dans votre projet, par exemple lors de l’écriture d’une bibliothèque sans dépendance. Dans ces cas, et également lorsqu’il s’agit d’arborescences de composants générées dynamiquement, telles que celles d’un formulaire généré dynamiquement ou d’une arborescence de composants basée sur un schéma, vous pouvez avoir besoin d’une solution différente.

Vue 3 nous offre deux outils très importants—fournir et injecter. Ils nous permettent de récupérer une donnée ou une variable de notre composant de niveau supérieur, quel qu’il soit, et de l’injecter dans ses enfants. Cet outil est très puissant car peu importe le nombre de niveaux d’enfants imbriqués que votre composant peut avoir, ou la profondeur du terrier du lapin du composant, vos données seront toujours prêtes à être récupérées (et même à maintenir la réactivité) en utilisant sa méthode sœur fournir.

Lorsque vous traitez avec des données secrètes

Lorsque vous traitez des données secrètes, telles que des jetons privés, il est très important de ne pas les exposer à votre référentiel. Dans ces cas, les « variables » globales ne sont pas une bonne solution. Au lieu de cela, vous devez utiliser la puissance de variables env via Vue CLI ou alors variables env dans Vite.

De cette façon, nous pouvons nous assurer que ces clés privées sont cachées aux regards indiscrets et ne sont utilisées directement que lors de la construction de l’application.

Quand tout le reste échoue

Comme je l’ai mentionné au début, tous les scénarios ne sont pas idéaux lorsque vous travaillez dans des projets réels. Parfois, vous obtiendrez des données directement de votre backend injectées dans le HTML via le serveur. Parfois, vous devrez partager ces « données globales » avec un widget jQuery ou un autre framework actuel comme React.

Restez calme et rappelez-vous qu’en fin de compte, Vue est un Javascript cadre, qui s’exécute dans un navigateur et donc vous pouvez Utilisez le fenêtre du navigateur Objet global. Ces données sont probablement mieux capturées d’une manière ou d’une autre par votre application dès que possible, peut-être dans main.js ou App.vue de niveau supérieur et gérées en interne à partir de maintenant. Cela peut devenir très désordonné très rapidement lorsque de nombreux composants lisent et écrivent dans l’objet window à partir de positions aléatoires dans votre application, et les bogues peuvent être très difficiles à détecter et à éliminer.

Avec cette solution, une bonne architecture, un code propre et une bonne composition de composants sont indispensables. La flexibilité fournie par l’objet window s’accompagne d’une grande responsabilité.




Source link