3

I am setting up a brand new site and structuring my javascript in a way that seems to make sense to me. I have created a site namespace, along with a widget/functionality 'namespace' that encapsulates methods for those widgets/functionalities. I have scoped each 'namespace' in a way that any given page on a site can call certain (public) methods to instantiate widgets/functionalities.

Here's an example of my javascript structure:

var THESITE = THESITE || (function(){
    navigation = function(){
        var init = function(){
            // do navigation stuff
        }

        return {
            init : init
        }
    },

    widgets = {
         widget1 : (function(){
            var newWidget = function(){
                // do widget1 stuff
            }

            return {
                newWidget : newWidget
            }
         })(),
         widget2 : (function(){
            var newWidget = function(){
                // do widget2 stuff
            }

            return {
                newWidget : newWidget
            }
         })(),
         widget3 : (function(){
            var newWidget = function(){
                // do widget3 stuff
            }

            return {
                newWidget : newWidget
            }
         })();
    },

    init = function(){
        navigation.init();
    }

    return {
        init: init,
        navigation: navigation,
        widgets: widgets,
    }
})();

THESITE.init();

And an example of how one of these methods would be called:

THESITE.widgets.widget3.newWidget();

Is this way of structuring my javascript practical/common?

Fillip Peyton
  • 3,637
  • 2
  • 32
  • 60
  • 1
    Yes it is common, and here are several other related structures. The benefit of your method is that it hides anything except what you deliberately put in the return statement, this simulating public/private declarations. But it is only a simulation so less rigorous structures are also often used. See the discussion in the related thread below for your options. http://stackoverflow.com/questions/247209/current-commonly-accepted-best-practices-around-code-organization-in-javascript?rq=1 – Chris Allen Dec 16 '13 at 21:41

1 Answers1

1

Yes, I would say that your structure is common. However for a larger project it would be practical to keep modules/widgets in separate files and use namespacing to ensure that collisions in the global scope does not occur. See the thread that @chris-allen suggested for more information on good ways to structure your code.

Community
  • 1
  • 1
flitig
  • 531
  • 2
  • 11
  • I am doing something similar for page-specific JS. I'm extending `THESITE` to have a `Page` subnamespace; i.e. `THESITE.Page` and include all the page-specific functionality there. – Fillip Peyton Dec 23 '13 at 20:49
  • I would suggest to try to move away from page specific js and instead think of your functionality in terms of components, even if a particular component only is used on a specific page. – flitig Dec 25 '13 at 14:25
  • For what reason? Since I am already creating modularity, I don't think I need to create more by separating into a separate JS file. Plus the fact that separate JS would increase HTTP requests. I dare say that might be more of an opinion than a best practice. – Fillip Peyton Dec 26 '13 at 18:29
  • That all being said, I'm going for the least HTTP requests. One for the global.js file with the `THESITE` namespace, and one for a page-specific JS file. – Fillip Peyton Dec 26 '13 at 18:30
  • It all depends on your site/application of course, but it's generally a better approach to think components (rather than pages) since it promotes reuse. – flitig Dec 27 '13 at 11:56
  • The common practice to handle multiple HTTP requests is by concatenating files. Concatenation could be done on a page by page basis, but if you expect your users to visit multiple pages during one visit, concurrent page loads will deliver cached versions of your single js file. – flitig Dec 27 '13 at 12:09