YUI 3 Loader & Aggregated Files

With the launch of the ArenaNet Blog I’ve been working a lot with YUI3 since it is the JS framework that powers all the interactivity on the site. The other great thing it does is provide a Loader that can pull in JS files on-demand as defined by a configuration object you pass to it. Loader has the capability to roll up multiple requests into a single file using a CDN but the functionality to do the same without using a CDN appears to be broken. Adam Moore from the YUI team & I have been discussing the issue on YUI’s bug tracker without a resolution yet.

Since I need to keep moving on this stuff I’ve had to devise my own solution to the issue I’m experiencing. For background, we use Apache Ant to create a “Deploy” version of the WordPress theme on the blog. This process runs through CSS/JS & renames files, compresses them, updates references, does DataURI stuff, etc. It’s pretty nice and allows for easily deploying a very optimized site without making development a nightmare. As part of that I’ve had it roll up two JS files that are always requested together into one file to avoid making an extra HTTP request. Unfortunately when I tried a simple replace of the previous filenames with the new aggregate file’s name YUI 3′s Loader was loading the file twice.

So until I can get a working version of what Adam has suggested here’s how I’ve set up the build system to allow for replacing individual modules in development mode with a single aggregate file for deploying.

//DEV CONFIG
YUI_config = {
    //yes this is a little gross but sadly it's necessary to make loader work how we want w/ ant
    /* dev */ ignore : [ "sidebar-rollup" ], //dev */
    /* live ignore : [ "chiclet", "slider-plugin" ], //live */
    groups : {
        anet : {
            combine : false,
            base : "/blog/wp-content/themes/arenanet/js/lib/",
            modules : {
                "chiclet" : {
                    path : "chiclet.js",
                    skinnable: false,
                    requires : [ "base", "widget", "anim-base", "anim-easing", "sidebar-rollup" ]
                },

                "slider-plugin" : {
                    path : "slider.js",
                    requires : ["plugin", "node", "anim-base", "anim-easing", "sidebar-rollup" ]
                },

                "gallery-lightbox" : {
                    path : "lightbox.js",
                    requires : ["base", "node", "anim-base", "selector-css3"]
                },

                "scroller-plugin" : {
                    path : "scroll.js",
                    requires : ["plugin", "node", "selector-css3", "event-delegate", "anim-base", "anim-scroll", "anim-easing"]
                },

                "social-counts" : {
                    path : "social.js",
                    requires : [ "gallery-yql", "node" ]
                },

                "sidebar-rollup" : {
                    path : "sidebar.js"
                }
            }
        }
    }
};

which is modified by the Ant build script to

//DEPLOY MODE
YUI_config = {
    //yes this is a little gross but sadly it's necessary to make loader work how we want w/ ant
    /* dev  ignore : [ "sidebar-rollup" ], //dev */
    /* live */ ignore : [ "chiclet", "slider-plugin" ], //live */
    groups : {
        anet : {
            //omitted for brevity, see above code block because this doesn't change between them
            }
        }
    }
};

The comments get stripped out during compression so it doesn’t look quite so gnarly when sent to end-users. It’s also pretty easy to do as an Ant task, all it takes is this




to do the switch. Later in my custom loader script those two modules are used with

YUI().use("node", "event-base", "imageloader", "selector-css3", "chiclet", "slider-plugin", function(Y) {
    // Code goes here...
});

which will always make sure that both the “Chiclet” and “Slider-Plugin” modules are available. In dev mode it will request chiclet.js & slider.js versus just asking for sidebar.js when deployed.

Does anybody have a better way of doing this? I think Adam’s version is nicer looking in the config but I’m not sure how it will work if a) the rollup file doesn’t exist or b) you don’t want to use the rollup except in production. I guess you could always just do something similar to what I’m doing now to configure it. That all assumes that the issues with it not actually loading the module get figured out, because if the modules aren’t added to the Y instance what’s the point?

Comments are closed.