zestedesavoir / zds-site

Cœur du projet technique de Zeste de Savoir
https://zestedesavoir.com
Other
268 stars 162 forks source link

Réorganiser le JS en modules / dans un namespace #796

Closed sandhose closed 5 years ago

sandhose commented 10 years ago

Actuellement, il n'y a aucun lien, aucune structure entre les différents modules JS. De plus, il y a beaucoup (trop) de variables globales déclarées un peu partout... (Juste en regardant celle qui commencent par $, on a $elem, $list, $navigableElems, $solvedTopicsElem, $overlay et $that)

Il faudrait tout englober dans un namespace (disons "App", pour faire original :smile: ), voir faire un système de module.

Solution 1: Se contenter d'un namespace

Juste avoir un namespace App, où l'on fout toutes les variables et autre... Genre App.editor, App.dropdown, App.mobileMenu, ...

Solution 2: Instaurer un système de modules

C'est ma solution préférée, mais elle plaira peut-être pas à tout le monde.

En gros, avoir une variable globale App, qui serait un objet avec quelques méthodes:

Cette solution permettrait une meilleure organisation, qui sera je pense très utile par la suite. L'App pourrait également implémenter un EventEmitter (sûrement via une lib), qui permettrait de gérer des événements (genre un événement "load", quand le DOM + les modules sont chargés, un événement "message", qui pourrais afficher un message à l'utilisateur de manière unifiée, un événement "editor submit", "zen mode activate", "notification", ....). Cela permettrait vraiment de créer un lien entre les différents modules, et d'unifier un certain nombres de choses...

Comme vous l'avez sûrement remarqué, je suis plutôt pour la seconde solution (sans blague ?). btw, si vous êtes d'accord de mettre en place cette structure dans le code, je peux m'occuper de tout adapter (rassurez-vous, je vais pas tout réécrire from scratch, il y a du code comme celui de l'éditeur qui sont déjà très bien adapté à cette structure! :smiley_cat: )

Voila, j'attends votre avis!

Alex-D commented 10 years ago

En fait, à terme, ma vision de tout ce JS est de simplement le virer et de convertir tout ça avec AngularJS pour aller beaucoup plus loin sur certaines pages qui nécessitent des outils bien plus avancés.

Du coup, tout ça n'est là que pour une v1, dans un futur que j'espère assez proche, tout ça sera revu, jQuery sera retiré et c'est AngularJS seul qui fera son boulot.

Du coup, je pense que ça n'est pas super utile de "perdre" son temps à repasser sur ces scripts là, alors qu'ils seront revus.

Alex-D commented 10 years ago

D'ailleurs, faire un système de module, c'est réinventer la roue. Si vraiment il faut scoper maintenant, un simple

function(){

}();

Peut faire l'affaire.

sandhose commented 10 years ago

A vrai dire, je voulais proposer Angular, mais je m'attendais qu'on me dises genre "c'est un peu overkill pour le peu de JS qu'il y a"...

J'ai failli aussi proposer RequireJS, ou Browserify...

Il n'empêche que pour le moment, c'est un peu le bordel niveau organisation du JS... :-° (Mais si tu me dis qu'a terme, avec la V2, ça sera réécrit, et organisé avec Angular, pas de problème :) )

Alex-D commented 10 years ago

Angular fait le même poids que jQuery en définitive... donc c'est pas si overkill.

Et actuellement, c'est pas si sale, c'est juste qu'il manque quelques var devant les noms de variable par ci par là pour qu'ils ne sortent pas de la fonction où ils sont créés.

Je vais nettoyer un peu ça de ce pas :)

sandhose commented 10 years ago

Hum... Globalement je l'ai déjà fait en local, puisque j'ai conformé tout le code à JSHint... (voir #782 ). Cependant, j'attends le merge de #777 (si c'est merge un jour ^_^ ) pour envoyer tout ça :)

Situphen commented 9 years ago

@sandhose : On fait quoi ici ?

ghost commented 9 years ago

Je pense que ça serait une bonne idée peut-être créer un sujet sur le forum ?

@sandhose Les variables globales sont peut-être des variables qui sont non déclarées ou mal déclarées.

GerardPaligot commented 8 years ago

@sandhose Est-ce que cette issue est toujours d'actualité ?

GerardPaligot commented 8 years ago

J'entends de plus en plus parlé de refacto du front. N'oubliez pas cette issue quand vous démarrez ce chantier ! @sandhose

A-312 commented 5 years ago

AngularJS ne risque pas d'ajouter une nouvelle barrière à l'accès de zds-site ?


Pour fire un event en attendant autres choses, il y a : $(...).trigger("mon-event")


Je ferais bien une PR qui tend vers la solution 1 mais prépare la solution 2. (Pour un projet j'ai déjà fait quelques choses comme ça)

Avec :


App = { //où true est une fonction avec bcp d'imagination
    registerModule:true,
    getModule:true,
    init:true
};

App.registerModule("editor", function () {
    var smiley = "...";

   var private_function = function () {

   };

   return {
        dependencies: "modal forum", //separate with space or array ?
        init: () {},
        load: () {},
        public_function: function () {}
   }
});

App.init();

Il y a-t-il vraiment un intérêt à utiliser set et get ?

Pour le onload, il faudra faire comme ça : https://github.com/A-312/chat-client/blob/master/javascript/require.file.js#L116 + Le fire à chaque fois qu'un module fini de charger pour gagner du temps.

App.getModule("editor");

On part la dessus ?