Discussion :

[Zefling]

Bonjour,

J'ai commencé à écrire un petit projet (sous licence MIT) pour ajouter quelques fonction qui me semblaient absentes et utiles pour le JS.
J'essaie de voir si quelque chose m'échappe ou pourrait être mieux fait.

Le projet est ici : https://github.com/Zefling/BakuJS

Cordialement.

Note : je n'ai pas pris le temps de traduire en anglais les commentaires...

[SylvainPV]

Hello,

Ça me fait penser à un autre projet similaire, SugarJS, qui venait ajouter des méthodes aux protos des objets natifs. Pour beaucoup de devs JS, étendre le proto d'objets qui ne nous appartiennent pas est une mauvaise pratique et présente trop de risques (pas future-friendly). C'est une erreur historique faite par Prototype.js, une des libs JS les plus populaires avant l'ère jQuery. La position de SugarJS est aujourd'hui de modifier uniquement certains objets, et d'en préserver d'autres (comme Object.prototype ou HTMLElement.prototype). Ils ont fait une page explicative très exhaustive là-dessus: http://sugarjs.com/native

Je ne sais pas si tu avais déjà connaissance de tous les problèmes liés à l'extension d'objets built-in, et si tu as une opinion sur le sujet. Pour ma part, même si je trouve l'extension de proto très séduisante et pratique, je pense qu'il est plus sûr de passer par des wrappers comme le font jQuery et underscore.

PS: attention avec navigator.language en nom de propriété, actuellement il y a des exceptions JS si la langue n'est pas gérée

[Zefling]

Je ne connaissais pas Sugar. À l'origine, j'avais fait ce projet pour pour les formateurs (nombre, date, string). J'ai juste poussé la partie DOM hier soir. Je vais prendre cela en compte.

[SylvainPV]

Le débat venait du fait que ces objets sont définis dans une spec du WHATWG, et non dans la spec ECMAScript officielle. Mais comme le WHATWG rassemble quasiment tous les éditeurs, je ne pense pas que cela cause trop de problèmes. Peut-être que certains navigateurs peu connus ne suivent pas ces specs, car rien ne les y oblige si on s'en tient au W3C.. mais bon, c'est sûrement des cas minoritaires

Par contre, le risque de collisions futures ou d'assomptions est toujours présent. Cela implique de maintenir une vigilance constante sur le projet au cas où de nouvelles méthode viendraient à être standardisées et rentrer en conflit avec les tiennes. Cela signifie aussi que si les utilisateurs s'amusent à stocker des propriétés persos au sein de host objects comme les éléments HTML (ce qui est là aussi une mauvaise pratique, mais bcp de libs et d'utilisateurs le font, et ça m'arrive aussi ), ils risquent d'avoir des conflits.

C'est le compromis confort/risque qui est délicat à trouver. Si l'opérateur bind de ES7 vient à être standardisé, on pourra obtenir ce même confort d'écriture sans devoir étendre les prototypes : https://github.com/zenparsing/es-function-bind

[Zefling]

D'après ce que j'ai lu, c'est que sous IE 6 & 7, ça causait des problèmes de mémoire et que sur IE 8 c'était mal foutu. D'où les problèmes pour Prototype.js. Sauf que ça c’était il y a 5 ans et que les supports de IE 8 est mort (même le 9 et quasiment le 10 sauf pour Vista).
Depuis, ça s'est standardisé, il ne reste que les problèmes de collisions... on ne peut pas dire que ça soit le pire. D'ailleurs, j'ai vu des articles où ils dissent que ça n'est plus vraiment un problème.

Bon, je vais continuer à explorer cette approche et regarde du côté des collisions, je n'ai pas pour but de faire un truc pour pour les navigateurs du moyen-âge. (sinon j'aurais commencé par String.trim() pas supporté par IE8).

D'ailleurs, j'ai trouvé ça : http://lea.verou.me/2015/04/idea-ext...ut-collisions/

[Zefling]

J'ai fait pas mal de modifications et d'ajouts, dont l'inclusion récursive (c'est pour me rapprocher de ce qui est permis en jstl avec fmt:message).

[ascito]

pour la gestion des dates, une usine qui est utilisé un peu beaucoup j'ai l'impression, ou va l’être...

http://momentjs.com

même si c'est plus forcément dans l'idée d’étendre le proto Date, cela permet de voir comment font les autres

[Zefling]

Ce n'est pas du tout la même approche. Mais c'est sûr qu'on peut faire beaucoup mieux sur mon truc.

[progdebutant]

Je trouve que ce que dit SylvainPV est très pertinent, faudra pas oublier ses remarques pour ce projet.
+1 Sylvain.

[SylvainPV]

Je n'ai fait que relever un problème potentiel qui peut survenir pour une minorité d'utilisateurs. Si Zefling souhaite utiliser cette lib pour son usage personnel, il est probable qu'il ne rencontre jamais de problème de conflit. C'est plus préoccupant s'il souhaite la diffuser et la promouvoir pour un grand nombre de personnes. Car si un d'entre eux a un conflit, il n'y a rien que l'on puisse faire côté lib pour corriger ça, il sera trop tard et il faudra changer toute l'API. C'est ce qui est arrivé à Prototype.js, et ce breaking change a coûté très cher.

[Zefling]

J'ai changé le nom des méthodes du DOM pour éviter les collisions, il n'y a pas de méthodes qui commencent par un _ en JS il me semble. Après, si une autre lib fait la même chose, utilisé en semble ça ne fonctionnera pas, je m'en doute un peu.

Après, pour ce que je connais des environnements où cela peut pourraient poser problème aujourd'hui, ça serait vraiment du cas particulier. Presque tout le monde utilise les mêmes moteurs, même ceux qui étaient plus exotique pour console utilisent aujourd'hui des moteurs dérivés de Webkit.

[ascito]

de mon point de vue,

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Date._getMonthName()

le "_" pourrait éventuellement servir à signifier un test unitaire.

D'un autre coté, j'utiliserais donc ta lib si, je peu comparer les protos natifs, et autres extensions, en me servant du tiens, ce qui franchement est un chemin sympa.

Fin pourvu que ca reste le moins intrusif possible

[Zefling]

Merci pour le soutient.

J'ai ajouté des tests et un début de doc : http://zefling.github.io/BakuJS/

Je me rends compte que j'ai presque tout réécrit depuis ma première publication.

[Zefling]

Je suis en train de tester mon formateur en condition réelle depuis quelques jours dans un gros projet où l'on cherche à avoir la même chose pour le formatage que les fmt:message en JSTL mais côté client. Pense être arrivé à quelque chose d'assez stable (au moins pour ça). Pour la partie DOM, je ne l'utiliserais pas, j'ai un autre projet plus perso pour ça.
D'ailleurs j'ai mis un petit script de minification avec plusieurs options.