42 votes

Comment organisez-vous de grandes bases de code JS / jQuery sur l'ensemble de votre site Web?

Comment voulez-vous organiser de grands JS/jQuery code de l'ensemble de votre site web? Il ya beaucoup de bonnes ressources sur la façon d'organiser les éléments de votre code, mais rien de vraiment sur la façon de tirer tous ensemble et de s'adapter à chaque pièce en place: du côté de code à l'échelle de l'organisation, de plusieurs pages en utilisant le même code, en restant bien au SEC avec couplage lâche, etc.

Ci-dessous est la façon dont je traite avec lui. Je n'ai jamais été à l'aise l'organisation de mon code comme ceci, parce que je pense que c'est bâclé et peut conduire à la facilité de maintenance/mise à l'échelle des problèmes, mais je ne sais pas vraiment mieux.

Je me rends compte que chacun a son propre ensemble d'exigences, et il n'y a pas de solutions clés en main, mais j'aimerais entendre quelques opinions sur ce que je fais mal, POURQUOI je le fais mal, et des suggestions sur la façon d'écrire du code plus maintenable.

Ce que je pense que je vais vraiment essayer d'obtenir au:

  1. Comment traitez-vous logique que vous besoin de l'utiliser dans de multiples endroits, sur plusieurs pages?

  2. Comment vous organisez-vous à la page spécifique code? Est namespacing chaque page dans un objet global, une bonne idée?1.

  3. Que faites-vous depuis le début de vous assurer que vous n'êtes pas constamment la ré-écriture de votre organisation les schémas de votre application devient plus grand et les plus grands? Je suis probablement sur ma 4ème itération de l'écriture de cette chose.2.

Chaque page reçoit le principal application.js fichier. Chaque page possède son propre application.pagename.js fichier. - Je l'utiliser côté serveur logique d'inclure les fichiers (vérifier d'abord pour voir si l'un existe même pour la page - certaines pages n'ont pas besoin de JS), et puis init dans l'ordre.

Donc, ma page d'accueil ressemble à:

<script src="js/application.js"></script>
<script src="js/application.index.js"></script>
<script>
    MyApp.init();
    MyApp.index.init();
</script>

mon URL convention est /page/page/id/. J'ai environ 10 pages et une flopée de sous-pages, chaque page exigeant leur propre logique. voir le dernier exemple dans ce post.

La plupart de mon code est déjà modulaire en jQuery UI widgets jQuery plugins, donc je dirais que 75% des le code de ces fichiers est require () " tion d'un widget et initing il.

J'utilise requireJS pour tirer dans les widgets que nécessaire.

// application.js
var MyApp = {
    init: function(){
        var self = this;

        // these widgets are available on every single page
        // notice the call to jquery.deparam.js - i'll use this later to init subpage logic.
        require(['js/widget1.js', 'js/widget2.js', 'js/widget3.js', 'js/jquery.deparam.js'], function(){

            // deparam the query string.  I'll use this later.
            self.querystring = $.deparam.querystring();

            // init widgets once the document is ready
            $(function(){
                $("#widget1").widget1();
                $("#widget2").widget2();

                // make these bindings available immediately as well.
                self.rebindable();
            });
        });
    },

    // I use jQuery UI Dialog extensively as a window manager, and each dialog is loaded
    // via an AJAX request.  I'll call this method after each AJAX request to
    // rebind some key widgets.
    rebindable: function(){
        $("#widget3").widget3();
    }
};

// application.index.js
// home page specific stuff.  this file is only included on the home page.
MyApp.index = {

    // my convention is that init is automatically called after the script
    // is included in a page, outside of a doc.ready statement.
    init: function(){
        var self = this;

        require(['js/widget4.js'], function(){
            $(function(){
                self.widget4( $("#foo") );
            });
        });
    },

    // passing elements to each method allows me to call this init code
    // outside of the index page.  I can require() this file, and only init
    // widget4, and even use a different element.
    widget4: function( element ){
        var config = {
            something: "custom to the home page"
        };

        element.widget4( config );
    }
};


// application.foo.js
// page "foo" stuff
MyApp.foo = {

    init: function(){
        var self = this;

        // this page happens to use the same widget3 and configuration present 
        // in MyApp.index.  this is where things can get sloppy and unmaintainable
        // really quickly.
        require(['js/application.index.js'], function(){
            $(function(){
                MyApp.index.widget3( $("#bar") );
            });
        });

        // page "foo" has three subpages (or actions) and require
        // their own logic.  url convention:  /foo/subpage1/
        // init whichever page we're on...
        switch( self.querystring.subpage ){
            case "subpage1":
                self.subpage1.init();
                break;
            case "subpage2":
                self.subpage2.init();
                break;
            case "subpage3":
                self.subpage3.init();
                break;
        }
    },

    subpage1: function(){
        init: function(){
            var self = this;

            // once the DOM is ready init dialog.
            $(function(){
                self.dialog( $("#openDialog") );
            });
        },

        dialog: function( element ){
            element.bind("click", function(){
                $('<div></div>').dialog({
                    open: function(){

                        // see what i'm doing here?
                        MyApp.rebindable();

                        // maybe more bindings specific to this
                        // dialog here
                    }
                });
            });
        }
    },

    subpage2: function(){
        init: function(){
        }
    },

    subpage3: function(){
        init: function(){
        }
    }
};

12voto

Justin Meyer Points 1221

Pour m'aider à répondre à vos questions, permettez-moi de parler un peu JavaScriptMVC's caractéristiques:

Contrôleur permettra d'améliorer vos widgets jQuery, en prenant soin de réglage / démontage, de l'extensibilité.

Vue ajoute côté client de modèles qui peuvent être intégrés dans votre application.

Modèle abstracts service ou de la couche de données de la minimisation et de la localisation du JS si votre serveur de changements.

Voler n'gestion de la dépendance, de compression et de nettoyage de code. Il va même jusqu'à prendre toutes vos scripts sur l'ensemble de vos pages, la figure communs dépendances, et de combiner les scripts dans un capacité de charge optimale.

FuncUnit fait le test de vos applications aussi facile que possible.

DocumentJS ... eh bien ... les documents de votre code

.

Maintenant à vos questions:

La façon de traiter avec la logique utilisé dans plusieurs endroits?

J'utilise StealJS de dépendance du système de gestion de charge les fonctionnalités dont j'ai besoin dans ma page. La gestion des dépendances est absolument nécessaire sur les applications d'une certaine taille. RequireJS est un bon choix si vous êtes capable de construire facilement.

Comment vous organisez-vous à la page de code spécifique

Page de code spécifique doit être aussi petite que possible. Habituellement, elle implique le chargement de dépendances et d'un "MainController". Que contrôleur principal configure la page d'obéir à l'fonctionnel / business exigences de cette page. C'est généralement des espaces de quelque chose comme:

App.Controllers.Main

comment voulez-vous arrêter d'écrire les mêmes modèles

Eh bien, je vous suggère d'utiliser un cadre qui a des modèles stables pour le développement. Aussi, gardez vos modules / plugins / widgets comme les petits (et vérifiable) que possible. Cela rendra ces parties beaucoup moins susceptibles de changer.

Enfin ....

Il semble que votre plus grande lutte de la tension entre:

  • partagé fonctionnalité
  • plusieurs pages
  • en temps opportun les temps de chargement

Afin de choisir une solide gestion de la dépendance de l'outil est super critique. StealJS pourrait vous aider à obtenir de très optimale des temps de chargement, mais vous auriez à s'écarter de JavaScriptMVC dossier standard de l'organisation en raison de votre grand nombre de pages.

RequireJS est plus souple, mais vous allez avoir à charge un grand nombre de fichiers. Ce ne sera pas seulement lent, ça va commencer à faire de vous créer beaucoup de gros fichiers JS qui ne sont pas très organisé.

Si vous êtes heureux avec les temps de chargement et se sentir comme ils ne vous causera pas de serrer le code dans les fichiers qu'il n'appartient pas, votre solution actuelle semble que cela va fonctionner.

Je pense que le secret de maintenable développement est de savoir comment facile votre système/framework permet d'isoler les préoccupations. Il est important de casser votre application dans la plus petite partie possible. De Plus, vous devriez être à l'essai de ces pièces. Les gens se perdre en pensant à leurs pages de la fonctionnalité. Mais pour vraiment échelle de développement, vous avez vraiment besoin de quelque chose qui vous permettra de vous échapper de votre application dans les petites pièces, la charge de ces pièces facilement, et en quelque sorte, obtenir l'application de toujours courir vite dans la production.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X