Les extensions DOM de Prototype entrent en collision avec une bibliothèque JS tierce - quel est mon meilleur pari?

Question

Je viens de passer près de 2 heures à déboguer une librairie JavaScript tierce pour trouver qu'un tableau que je passe à cette bibliothèque est converti en une chaîne quelque part dans le tuyau ... Je ne sais pas pourquoi ou comment ça se passe, mais dès que je retire Prototype de mon projet, tout fonctionne à nouveau correctement. Est-ce que cela pourrait être dû au fait que Prototype étend le DOM? Quelle est ma meilleure option? J'utilise les itérateurs d'éléments de Prototype, la manipulation DOM, la méthode bind() et les manipulateurs de chaînes dans mon projet, et je préfère ne pas les perdre.

Y at-il une bibliothèque qui a tout cela, mais qui fonctionne bien avec les bibliothèques JS tierces qui sont sensibles aux extensions DOM?

Answer 1

Après avoir travaillé avec Prototype auparavant, il n'y a aucun moyen de le faire «jouer sympa» (semblable au mode noConflict de jQuery).

L'approche même derrière Prototype empêche cela. Le pain de Prototype & butter provient de sa méthode Object.extend() qui est appelée sur les objets dès que vous les manipulez avec des méthodes Prototype. Sans oublier que Prototype a déjà modifié des objets JavaScript de base avant de jouer avec le vôtre. D'autre part, jQuery est entièrement autonome dans l'objet jQuery (qui est, à ma connaissance, tout ce qu'il ajoute à l'espace de noms JavaScript lorsqu'il est inclus).

Y a-t-il d'autres bibliothèques qui ont des fonctionnalités similaires? Bien sûr, en fait, et je suis sûr que vous en avez marre d'entendre cela maintenant, mais vous pourriez probablement en faire la plupart avec jQuery. Cependant, vous n'allez pas éviter l'inévitable: réécrire le code. Cela ne se fera pas de la même manière avec n'importe quel autre cadre, et encore moins vous donnera les mêmes résultats/beahvior.

Vos choix sont donc:

• drop Prototype et d'autres choses ré-écriture qui ne l'utiliser pour utiliser quelque chose d'autre
• Supprimez la bibliothèque tierce partie en faveur de remplacement ou de l'absence tout à fait
• Re- écrivez prototype.js ou thirdpartytool.js pour jouer correctement (ceci, bien sûr, est un hack terrible qui causera plus de maux de tête quand vous voulez "améliorer" un ou les deux outils dans le futur quand une nouvelle version sortira)

Answer 2

J'ai eu du succès avec jQuery. Si vous appelez jQuery.noConflict(), cela fonctionnera très bien avec d'autres bibliothèques JS.

Answer 3

Un peu de mon expérience amère. Je viens juste de finir d'écrire mon propre framework pour les applications XUL (j'ai juste besoin de quelque chose comme un modèle de composant sans $ ou prototype de douceur lib.). C'est très petit, pratique et simple. Mais ... Seulement maintenant, quand tout est prêt pour l'utilisation du framework, j'ai trouvé que c'est complètement mort dans le contexte XUL. Le principal obstacle est que le moteur JavaScript rejette tous vos changements dans les objets de base comme la fonction, l'objet, etc.. Donc, les extensions clés qui rendent les choses fonctionnent — f.x. Function.prototype.toClass, override et autres — sont invisibles en dehors du fichier où ils sont définis.