Bonjour,

Je me suis fait une petite fonction require() style node.js pour mes développement frontend, ça me permet de charger dynamiquement des "modules" lors de l'exécution du script, sans avoir à inclure toute ma librairie au lancement de la page, et de les utiliser de façon indépendante.

Le but est en somme de pouvoir faire ceci:

var foo = require('lib/foo');
foo.magic();

Et dans lib/foo.js:

exports.magic = function () {
   // do magic
};

Le souci c'est que ça me fait utiliser deux pratiques dépréciées de JavaScript, à savoir les requêtes HTTP synchrones, et la vilaine fonction eval().

Voilà le code de ma fonction require(): http://wall.deblan.fr/x163f/javascript/1/

Je suis vraiment satisfait de cette fonction, mais je ne dors pas totalement sur mes oreilles pour les raisons que j'évoque ci-dessus...

J'avais fait une version totalement asynchrone et sans eval explicite (on créé un script avec src qu'on append au body, en utilisant les évènements load et error pour appeler un callback), mais ça ne fonctionnait pas à tous les coups (des fois strictement aucun script n'était chargé, et sans renvoyer d'erreur).

Vous pensez que c'est un crime d'utiliser des requêtes bloquantes avec un eval() ? Devrais-je plutôt utiliser jQuery.getScript() ?

Je pense que le raisonnement est mauvais. Typiquement, dans symfony tu peux paramétrer des JS de base et qui sera systématiquement chargés (ou pas, en tout cas dans sf2]) et il est possible, suivant les besoins dans les vues, d'ajouter "à la volée" ce dont tu as besoin. Pour illustrer un peu, voila ce que tu peux trouver dans un layout (template de base où le contenu généré par mes bundles sera intégré) : http://wall.deblan.fr/x1640/html/1/ (note la définition de "block"). Voilà maintenant ce que j'ai dans une vue qui aurait besoin de plus de choses : http://wall.deblan.fr/x1641/html/1/

Dans symfony 1, il y a avait une petite similitude : tu pouvais alimenter un tableau de js, css et d'autres trucs depuis les vues et les contrôleurs.

Je suis pas encore habitué à la notion de layout et de block, mais en somme il y a une page "mère" qui contient la structure html et qui définit différents blocs, puis la vue qui est réellement appelée se contente de remplir les blocs prédéfinis ?

L'idée me plaît bien, j'avais pas envie de m'embêter avec des tableaux de js et css dans mes contrôleurs, mais dans la mesure où c'est directement dans la vue, pourquoi pas.

Quoi qu'il en soit mon délire de base c'était plutôt de recréer une sorte d'autoload, avec un seul fichier main.js, qui inclue une classe particulière pour faire joujou avec, qui elle-même va inclure d'autres classes nécessaires à son fonctionnement, et ainsi de suite. Dans ce sens là ma fonction require() fait le job, mais d'après toi c'est une mauvaise idée de chercher à recréer un autoload côté client ? Tu trouves que le raisonnement est mauvais, mais est-ce qu'en pratique ça pose vraiment problème ?

"Je suis pas encore habitué à la notion de layout et de block, mais en somme il y a une page "mère" qui contient la structure html et qui définit différents blocs, puis la vue qui est réellement appelée se contente de remplir les blocs prédéfinis ?" : Oui, les "sous" vues surchargent (si elles le souhaitent) les blocks parents. La pattern utilisé est Decorator https://en.wikipedia.org/wiki/Decorator_pattern

Si tu écris du JS qui dépend de bibliothèques, ne te fais pas chier à récupérer ces dépendances uniquement à l'exécution car tu risques de souffrir de ralentissements (après le chargement initial). Exemple con : tu n'as pas besoin de jQuery pour exécuter le code de base de ton site. Cependant, à un moment donné tu veux (et tu es contraint) de l'utiliser (pour faire des animations par exemple) : au lieu d'avoir une exécution rapide car jQuery a été chargé avant, tu va te manger une requête HTTP qui va prendre quelques millisecondes, pas certaine d'être résolue (exemple : coupure réseau) et ton code ne sera pas exécuté.

Dans le contexte d'un site web, je n'ai jamais rencontré ce type de fonctionnalité. Bien souvent, on va jouer sur le cache navigateur du client et la compression des fichiers.

Decorator m'a l'air intéressant, mais ça doit poser problème dès lors qu'on a besoin de propriétés ou méthodes protégées, non ?

Pour ce qui concerne le JS, il me faudrait une raison un peu plus conséquente que de l'animation pour charger une bibliothèque comme jQuery, mais je vois ce que tu veux dire, et dans ce cas là je chargerais la bibliothèque avec la page.

Je viens de découvrir RequireJS et c'est exactement la même logique (à la différence qu'il charge les scripts de façon asynchrone). Tu penses que le raisonnement de RequireJS est mauvais ?

Par contre RequireJS propose un "optimizer" qui regroupe tous les fichiers et les minifie, à utiliser une fois le développement terminé. Je pense que je vais faire la même chose, en gros mon require(), ce sera que pour le développement, je pense que c'est mieux comme ça.

Je ne sais pas s'il est mauvais ou pas, mon sentiment est que dans le cadre de site internet, tu n'as pas besoin de faire ça. Par contre, implanter ce type de fonctionnalité dans une grosse application (genre un site à la deezer), pourquoi pas