YUI, how dare you make me rethink

So I've been spending time working on moving ahead with my project using YUI. So it's been a lot of trying to port over old jQuery code into YUI, going through docs on the various widgets and plugins, and just trying to figure out how to rearrange how I think with this stuff.

The hard part is that YUI3 enforces something we all consider good practice. Don't pollute the global namespace. What's the bad in that? Well, it presents some challenges with the way I used to do things.

[sourcecode lang="javascript"] MyApp = {};

MyApp.home_page = {

'init': function () { // do some stuff here // like load some social content or crap MyApp.home_page.bind_stuff(); },

'bind_stuff': function () { // hey, we have fancy events we bind/catch // woooo } };

// and then in the page onReady I just MyApp.home_page.init(); [/sourcecode]

So that's how I have been doing things. Parts get abstracted out, shared, but basically each page tends to have an object for each page and any extra handling of events or whatever that requires.

However, YUI3 does this cool thing that breaks that. When you use YUI3 you have a YUI().use() and everything gets encapsulated within that bit of code. So if I were to just move the MyApp code into the YUI block I'm no longer able to access it from the page of content I want to run JS on. So this is good, no JS globals, but it's bad...not the way I've been doing things.

So I've had to figure out how to adjust my old code to the new YUI3 way, and I came across this great video on structuring your code a bit better. It makes some sense, but it seemed to just scratch the surface. Unfortunately, his example is a single page application so it's a bit simpler than what I needed, but it got the point across for me.

So what's the new stuff look like? It looks like YUI3 modules

[sourcecode lang="javascript"] YUI.add('myapp', function (Y) { var MyApp,

MyApp = function (config) { MyApp.superclass.constructor.apply(this, arguments); };

/** Static **/ MyApp.NAME = 'MyApp'; MyApp.ATTRS = {

};

Y.extend(MyApp, Y.Base, { initializer : function (config) { },

destructor : function () {},

/** Public Methods **/ 'some_page': function () { var that = {};

that.init = function () { // do some stuff that.bind_stuff();

};

that.bind_stuff = function () { // and we're doing stuff };

// return the page object with all the controls/method return that;

}

});

Y.namespace('MyApp'); Y.MyApp.Window = MyApp;

}, '0.1', { requires: ['base', 'node', 'my-ui', 'yui2-datatable', 'yui2-button'] });

// and then I use it from my page with YUI({ }).use('myapp', function (Y) { win = new Y.MyApp.Window(); my_page = win.qcontent_admin() my_page.init(); });

[/sourcecode]

So this has me creating a module for my application code. It allows me to specify versions, requirements, etc. It keeps the YUI3 way of not polluting any global namespace for the application, and while a bit more verbose, seems to be working out. I like this since it's getting to what I was talking about back before when I was looking at moving to YUI from jQuery. This feels more like treating the JS code like application code.

I could split up the code into different modules based on different logical sections of the application and I might be able to reuse bits of this down the road. For instance, we use a common base bit of application code for our authentication across apps. I could break out the JS code for the auth pages into their own module, version it, and reuse it much easier.

What do you think? Am I heading in the right direction or am I just making life more complicated than it's supposed to be?