Version imprimable
Bonjour,
Ci-dessous retrouvez la traduction de l'article How to Easily Create a JavaScript Framework, Part 1 de Teylor Feliz.
Comment créer facilement un framework JavaScript - Partie 1
Cet article est le premier d'une série qui vous expliquera comment créer un framework JavaScript.
Bonne lecture et n'hésitez pas à partager vos points de vue sur cet article
salut kalyparker!
très bonne article!!
Il existe beaucoup de framework js, hors il y'a aussi beaucoup de petite source qui n'en utilise pas, et qui mélange dans leur code des procédures spécifique à leur application et celle beaucoup plus générique, patchant le js ou le dom.
Pense que c'est une bonne chose de donner les bases au débutant, de bien différencier les différentes procédures, et de les classer comme telles.
Sinon une chose que je voudrais ajouter , c'est de toujours donner des noms explicite aux fonctions, un mauvais exemple dans ce domaine est jquery, (même si pour certain c'est un point fort), réduire la syntaxe et mélanger les type de retour possible d'une fonction est une mauvaise chose, tant pour la l'aspect méthodologique qu'impose la programmation que au niveau du débogage.Imaginer une classe renvoyant des types différents en fonction des arguments passé ...
Sinon concernant le framework en lui même, la fonction getById, est erroné. Elle renvoie this au lieu de l'élément correspondant à l'identifiant passé, de plus elle créer un tableau qui devrait être nécessaire que quand il y a plus d'un argument.
Les boucles sont mal former, faut créer une variable pour tester la longueur d'un tableau.
La fonction addClass, devrait tester si la chaine n'est pas déjà vide avant d'ajouter un espace.
La fonction on est mal construite, a chaque appel de celle-ci , l'interpréteur testera l'existence de telle ou telle fonction native. Cette distinction devrait ce faire à l'initialisation de la fonction.
je suis impatient de voire la suite, surtout au niveau de l'extension des classes natives, à la quelle j'ai jamais trouvé une réponse satisfaisante.
Salut kimjoa.
Tes remarques sont plutôt intéressantes mais nécessitent quelques explications.
Pour ce qui est du nommage, c'est effectivement souvent un problème pour les principaux frameworks. J'ai eu récemment à alléger Prototype et script.aculo.us pour en sortir toutes les fonctions qui me semblaient inutiles et je dois avouer que ça n'a pas été une sinécure, en particulier à cause de ça (pour retrouver les dépendances aussi, mais c'est un autre problème) et pourtant, Prototype est plus cohérent (à mon goût) que jQuery pour le nommage...
Concernant les types renvoyés, ta remarque est juste sur le fond, renvoyer des types différents en fonction des paramètres passés est une aberration, mais ce n'est pas ce que fait jQuery, au contraire. jQuery fonctionne sur le principe de l'objet unique (jQuery ou $) et c'est bien cet objet modifié qui est renvoyé par quasiment toutes les méthodes jQuery, ce qui permet en particulier des possibilités de chaînages assez impressionnantes.
Dans la traduction de kalyparker, c'est bien cet aspect qui est repris, on travaille sur un tableau d'éléments qui est lui-même renvoyé par les méthodes de la librairie. Cela me semble assez cohérent comme fonctionnement et justifie pleinement que getById renvoie un tableau et non un élément HTML, ce qui casserait la logique de la lib.
Pour ce qui est du on, tu as raison, cela fait des tests inutiles à chaque utilisation de la méthode.
Enfin, pour ce qui est de l'ajout de classe, j'aurais tendance à faire comme tu le dis, mais se soucier de cet espace initial relève plus je pense d'une certaine maniaquerie (que j'assume :)) que réellement d'un point important. Avoir un espace initial dans la propriété className d'un élément n'est pas une erreur et ne pas essayer de le détecter évite là aussi des tests inutiles ;)
EDIT :
Pour les boucles, tu as là aussi raison, c'est d'ailleurs un débat que nous avons eu à plusieurs reprises sur comment écrire une boucle optimisée :)
Ceci dit, dans la mesure où il s'agit d'une traduction, je pense qu'il est préférable de laisser le code tel quel.
salut bovino!
C'est vrai. , hormis la fonction $ qui fait tout même le café :), les autres sont plus cohérente.Citation:
Concernant les types renvoyés, ta remarque est juste sur le fond, renvoyer des types différents en fonction des paramètres passés est une aberration, mais ce n'est pas ce que fait jQuery, au contraire
Je trouve que se concept de renvoyer toujours une collection d'élément n'est pas très logique. Toutes les fonctions du dom ne renvoie pas un nœud. Une fonction comme isDescendante appliqué à une collection devrait renvoyer un tableau ou un boolean comme sont non l'indique? Hors si cette fonction ne renvoie pas une collection , alors pourquoi getById le devrait?Citation:
Dans la traduction de kalyparker, c'est bien cet aspect qui est repris, on travaille sur un tableau d'éléments qui est lui-même renvoyé par les méthodes de la librairie. Cela me semble assez cohérent comme fonctionnement et justifie pleinement que getById renvoie un tableau et non un élément HTML, ce qui casserait la logique de la lib.
Tout les framework dom , même d'un autre langage , hors jqeury font la distinction entre élément et collection. Plus généralement c'est comme si tout les objets javascript serait en faite encapsuler dans des collections :calim2:
Ouais c'est vrai que sa relève de la maniaquerie :aie:Citation:
Enfin, pour ce qui est de l'ajout de classe, j'aurais tendance à faire comme tu le dis, mais se soucier de cet espace initial relève plus je pense d'une certaine maniaquerie (que j'assume ) que réellement d'un point important. Avoir un espace initial dans la propriété className d'un élément n'est pas une erreur et ne pas essayer de le détecter évite là aussi des tests inutiles
a++
jour
instructif ,comprehensible et facile a ingurgiter et ca mon petit cerveau il aime :ccool:
article propre et interessant, il aurait été bon de voir pourquoi les functions anonyme ;-)
sinon , je rejoins kimjoa , sur m'optimisation et sur la suite ( concernant l'extend de classes :) )
Merci de vos commentaires.
A mon avis Teylor Feliz a surtout voulu présenter une série d'article permettant à n'importe qui de comprendre comment fonctionne un framework JavaScript de manière assez simple.
Des améliorations sont possibles, mais dans la mesure où ce code n'est pas de moi, je ne vais pas le modifier, mais vos remarques permettront à ceux qui veulent allez plus loin d'avoir quelques pistes ;)
Bonjour,
Je viens de lire les différentes parties de cet article et je le trouve très intéressant, et utile.
Mais dans cette partie 1, il me semblait qu'il y avait une erreur dans la fonction toggleHide(). La condition est "bizarre", mais surtout, tout élément qui sera montré via cette fonction après avoir été caché, se transformera automatiquement en "block" CSS, ce qui n'est pas souhaitable, par exemple pour un élément "img" (qui est "inline" plutôt que "block").
J'en ai parlé à l'auteur sur son article original, et il m'a répondu qu'effectivement, il y avait bien une erreur dans cette fonction, et a indiqué la ligne à corriger.
Merci Ced-le-pingouin,
La modification à été faite dans la série (en français).