De nombreuses bibliothèques de framework JS choisissent d'utiliser le symbole $ comme noms de fonctions ou de variables, et jQuery est le plus typique. Dans jQuery, le symbole $ n'est qu'une référence à l'objet window.jQuery, donc même si $ est supprimé, window.jQuery reste un support solide pour garantir l'intégrité de l'ensemble de la bibliothèque de classes. La conception de l'API de jQuery prend pleinement en compte les conflits de références entre plusieurs frameworks. Nous pouvons utiliser la méthode jQuery.noConflict pour transférer facilement le contrôle.
La méthode jQuery.noConflict contient un paramètre booléen facultatif [1], qui détermine s'il faut remettre l'objet jQuery lui-même lors de la remise de la référence $ :
Par défaut, l'exécution de noConflict transférera le contrôle de la variable $ à la première bibliothèque qui génère $ ; lorsque RemoveAll est défini sur true, l'exécution de noConflict transférera tout le contrôle de $ et l'objet jQuery lui-même à la première bibliothèque à les générer. .
Par exemple, lorsque KISSY et jQuery sont mélangés et que $ = KISSY est utilisé pour simplifier les opérations de l'API, cette méthode peut être utilisée pour résoudre le problème de conflit de noms.
Alors comment ce mécanisme est-il mis en œuvre ? Lisez le début du code source de jQuery [2], la première chose à faire est ceci :
Il est facile de comprendre que jQuery mappe les deux objets jQuery et $ dans l'environnement de fenêtre via deux variables privées pour éviter que les variables ne soient écrasées de force. Une fois la méthode noConflict appelée, la différence entre _jQuery, _$, jQuery, $ est utilisée pour déterminer la méthode de transfert de contrôle. Le code spécifique est le suivant :
noConflict: function( deep ) {
Si (deep && window. jQuery === jQuery ) {
window.jQuery = jQuery === 🎜> Examinons le problème de configuration des paramètres mentionné ci-dessus. deep ne paramètre pas, _$ remplace window.$, à ce moment l'alias jQuery $ n'est pas valide, mais jQuery lui-même est intact. Si une autre bibliothèque ou un autre code redéfinit la variable $, le contrôle de celle-ci est complètement transféré. D'un autre côté, si deep est défini sur true, _jQuery écrase window.jQuery et $ et jQuery seront invalides.
L'avantage de cette opération est que peu importe qu'il s'agisse d'un environnement d'exécution très conflictuel tel qu'un mixage de framework ou une coexistence multi-version de jQuery, en raison du mécanisme de transfert fourni par la méthode noConflict et du fait qu'elle renvoie un objet jQuery non couvert , il peut être complètement cartographié via des variables pour résoudre les conflits.
Mais le fait inévitable est que cela peut provoquer une défaillance du plug-in et d'autres problèmes. Bien sûr, il peut être restauré en modifiant simplement les paramètres de contexte :
.
Le code est le suivant :
L'exemple suivant résout également ce problème
Depuis sa naissance, il y a eu de plus en plus de versions de jQuery, et de nouvelles versions du site officiel de jQuery sont toujours constamment mises à jour et publiées. Cependant, nous avons déjà utilisé des versions plus anciennes de jQuery dans des projets précédents, tels que : 1.3.X, 1.4.X, 1.5.X, 1.6.2, etc.
En raison des besoins du projet, il est nécessaire de continuer à utiliser des versions plus récentes de jQuery. Cependant, pour les anciennes versions de jQuery qui existent déjà et qui ont été adoptées, comment permettre à plusieurs versions différentes de jQuery de coexister sur le projet. même page sans qu'en est-il des conflits ?
En fait, en utilisant la fonctionnalité jQuery.noConflict(), nous pouvons non seulement laisser jQuery coexister avec d'autres bibliothèques JS, telles que Prototype. Peut également coexister avec d'autres versions différentes de jQuery lui-même sans conflit.