Une pratique très courante dans le développement Web consiste à cibler un élément de votre DOM et à le manipuler d'une manière ou d'une autre. Voyons la puissance de la référence dans Vue avec un exemple facile à suivre.
Une pratique très courante en développement Web consiste à cibler un élément de votre DOM (modèle d'objet de document) (autrement dit, tous vos éléments HTML et leur structure logique). de le manipuler d’une manière ou d’une autre.
Dans cet article, nous allons vérifier le pouvoir de réf et de certains de ses cas extrêmes. Préparez votre pain et pelons-le.
Knights of the Old Vuepublic
Pour ceux d'entre nous qui venons de l'ancien régime, alias jQuery nous étions très habitués à viser un DOM. élément de notre page pour le modifier ou l’utiliser de quelque manière que ce soit. En fait, cela était presque inévitable dans les cas où vous souhaitiez utiliser n'importe quel type de plugin utilisant un élément de votre page.
Dans jQuery vous sélectionneriez un élément en le ciblant avec le $ () ce qui ouvrirait une grande variété de méthodes pour manipuler cet objet. Prenons l'exemple d'une div dans laquelle vous souhaitez définir ou basculer la visibilité en basculant autour de la propriété CSS de l'affichage .
Considérons le balisage suivant pour notre exemple. 19659008] I is hidden
I est montré
I is ?
Dans jQuery ceci ressemblerait à ce qui suit:
$ ('# datOneDiv'). Css (' bloc de visualisation');
Quelques éléments intéressants à mentionner ici. Tout d'abord, remarquez que nous visons un div très spécifique dans notre document, celui portant le id de de datOneDiv vu par le sélecteur ] #datOneDiv (le # fonctionne ici de la même manière qu'un sélecteur CSS, il désigne un identifiant).
La deuxième chose à noter est que, aussi incroyablement simple que cela puisse être, il a empêché de nombreuses personnes de réellement apprendre à utiliser JavaScript, qui au fil du temps est devenu un problème.
Avez-vous même JS, Breh? ??
En JavaScript vanille, le même résultat peut être obtenu en utilisant querySelector et certaines manipulations de propriétés.
Ce qu'il faut noter à propos de cet exemple, c'est qu'une fois encore, nous utilisons un id pour cibler une partie div très spécifique de notre document. Certes, nous aurions aussi pu cibler le div avec sa classe en faisant .myCoolClass mais comme vous le découvrirez, le même problème se posera.
The Vue Awakens
Nous allons tuer des Sith aujourd'hui. Ne vous inquiétez pas, aucun type à l'air froid et corné n'a été blessé dans la rédaction de cet article.
Envisagez le composant Vue suivant Sith.vue .
I is Sith
Je sais, je sais. Amaga, je devrais utiliser des cours dynamiques, ton exemple est si mauvais, l'avocat est fou et tu n'es plus ma meilleure. C’est correct, je ne vous ai pas aimé de toute façon. Cependant, à titre d'exemple, supposons que nous ne sachions pas tout ce bien-être de Vue et que nous essayions en fait de cibler le DOM de cette façon pour y apporter des modifications. (Blagues à part, s'il existe un moyen d'appliquer des classes ou des styles de manière dynamique, vous devriez TOUJOURS opter pour le faire avec des propriétés dynamiques! Nous ne faisons que ceci, à titre d'exemple simple à suivre.)
Si nous instancions cela composant dans notre App.vue ou notre point d’entrée principal de l’application, et nous cliquons sur le bouton, vous remarquerez que cela fonctionne réellement. Alors, pourquoi exactement nous a-t-on dit à maintes reprises qu'il était tellement mauvais de cibler le DOM directement dans Vue comme nous le faisons ici?
Essayez de modifier votre modèle principal (ou l'endroit où vous testez ces composants) pour en contenir deux. ou plusieurs seigneurs Sith, comme tel.
Maintenant, vas-y et clique sur le second pour le tuer. HUH. La force est faible avec celui-ci. Savez-vous ce qui s'est passé?
Lorsque la méthode du composant keelItWithFire se déclenche sur le second composant, la méthode querySelector passe par le DOM et tente de trouver le premier exemple d'un élément de la classe sithLord et bien sûr, il le trouve!
Le grand problème du ciblage direct du DOM dans Vue est tout d'abord que les composants sont censés être réutilisables et dynamiques Donc, nous ne pouvons pas garantir que la classe ici sera unique .
Bien, nous pouvons utiliser un id vous voyez! Et vous êtes partiellement correct, attribuer un attribut id à un modèle dans Vue en quelque sorte garantit son unicité, prouvant que vous n'instanciez pas plus d'un seul de ces composants dans l'ensemble de votre application (sinon vous rencontrerez essentiellement le même problème que précédemment).
La deuxième mise en garde est que vous devrez également garantir qu'aucune autre fonctionnalité de votre application, aucun autre développeur et aucune autre La bibliothèque va créer un élément pouvant contenir le même objet id .
La voie du vuedi
Vue ou pas, rien n’est tenté.
Dans Vue, nous en avons beaucoup d'outils pour modifier le modèle de manière dynamique à travers les propriétés calculées, l'état local, les liaisons dynamiques, etc. Mais il viendra un moment où vous serez confronté à la nécessité de cibler réellement le DOM. Quelques raisons courantes sont de mettre en œuvre un plugin externe non spécifique à Vue, ou de cibler un champ dans un formulaire et de le centrer, par exemple.
Lorsqu'un tel cas se présente, nous avons un attribut plutôt intéressant peut gifler des éléments appelés ref . Vous pouvez consulter la documentation officielle ici .
Nous allons créer un nouveau composant, cette fois un Jedi.vue et nous allons le faire Les choses que nous sommes censés voir dans Vue.
I is Jedi
Quoi, vous pensiez que parce qu’ils étaient Jedi, nous n’allions pas? Il n'y a rien qui cloche avec un petit hippo, ce n'est pas AUCUN.
Maintenant, l'important est de comprendre ce qui se passe lorsque l'on ajoute un attribut ref à l'un des éléments sur notre . En termes simples, chaque instance de composant contiendra désormais une référence privée désignant sa propre balise
que nous pouvons cibler comme indiqué sur la fonction keelItWithFire via la fonction $ refs propriété de l'instance.
Outre les problèmes liés au ciblage par classe et par id, il est de la plus haute importance de savoir que le plus gros problème de tous est que la modification directe de DOM peut entraîner le remplacement de ces modifications par Vue lorsqu'il y a un cycle de restitution du DOM, sur ce composant ou sur son parent.
Depuis que nous ciblons directement le DOM, Vue ne le sait pas, il ne met pas à jour la "copie" virtuelle il a stocké – et lorsqu'il doit reconstruire, tous ces changements seront complètement perdus.
Si vous ne voulez pas qu'un certain morceau de votre DOM soit constamment restitué par Vue, vous pouvez appliquer le . attribut v-once – de cette façon, il ne tentera pas de restituer ce par t.
Pour l’instant, cet exemple ne semble pas très excitant, mais avant de passer à un scénario réel, j’aimerais évoquer quelques mises en garde.
Caveat 1
Si vous utilisez ref au-dessus d'un composant Vue, tel que puis ce que vous obtenez de this. $ Refs.jedi sera l'instance de composant, et non l'élément comme nous sommes ici avec la balise
. Cela signifie que vous avez accès à toutes les propriétés et méthodes de Vue, mais vous devrez également accéder à l'élément racine de ce composant via $ el si vous devez apporter des modifications directes à DOM. [19659053] Caveat 2
Les $ refs sont enregistrés après l'exécution de la fonction de rendu d'un composant. Cela signifie que vous ne pourrez PAS utiliser $ refs sur les hameçons qui se produisent avant le rendu est appelé, par exemple sur created () [1945[19009007]; vous l'aurez cependant disponible sur monté () .
Il y a moyen de attendre que soit créé () pour que les éléments soient disponibles, et le est en tirant parti de la fonction de cette fonction $ nextTick .
Ce que fera de cette. $ nextTick c’est l’arrêt de la fonction que vous lui transmettez jusqu’à la prochaine mise à jour du DOM par Vue .
Considérons l’exemple suivant:
No
Nous avons une balise
avec une référence de myRef rien d’exceptionnel. Sur le crochet created () il se passe quelque chose de nouveau.
Premièrement, nous vérifions si est présent. $ Refs.myRef est disponible, et comme prévu, cela ne sera pas dû au fait que le DOM n'a pas encore été restitué à ce stade - le fichier console.log sera donc exécuté.
Après cela, nous définissons une fonction anonyme appelée $ nextTick [qui sera exécuté après le prochain cycle de mise à jour du DOM. Chaque fois que cela se produit, nous allons nous connecter à la console: «Maintenant, c'est fait!»
Sur le crochet monté () nous utilisons en fait ce ref pour modifier le texte intérieur de la balise
à quelque chose de plus digne de notre sauveur, l'avocat magique, puis nous console un peu plus.
N'oubliez pas que vous obtiendrez les journaux de la console dans cet ordre:
Maintenant il est monté
Maintenant il le fait
monté () va effectivement tirer avant nextTick parce que nextTick se passe à la fin de la cycle de rendu.
Le côté obscur
Bien, maintenant que vous avez toute la théorie impressionnante, que pouvons-nous réellement faire avec cette connaissance? Jetons un coup d’œil à un exemple courant, intégrant une bibliothèque tierce, flatpickr dans l’un de nos composants. Vous pouvez en savoir plus sur flatpickr ici .
Considérons le composant suivant.
Tout d'abord, nous importons la bibliothèque et certains styles requis, mais le package nécessite ensuite de cibler un élément spécifique de notre DOM auquel s'attacher. Nous utilisons réf ici pour diriger la bibliothèque vers l'élément correct avec ceci. $ Refs.datepicker .
Cette technique fonctionnera même pour . ] plugins jQuery .
Mais méfiez-vous du côté obscur. Angerlar, jPear, Reactgression; le côté obscur de la Force sont-ils. (Avertissement, ceci est une blague. En fait, je ne déteste pas les autres frameworks. Sauf peut-être jQuery. JQuery is evil.)
Envelopper
J'espère que vous avez eu du plaisir à apprendre sur ref aujourd'hui . C'est un outil incompris et sous-utilisé qui vous évitera des ennuis s'il est utilisé au bon moment!
