The next YUI: Open Hours will be Wednesday the 14th. We're trying out this Wednesday thing in hopes of catching more folks in later time zones that would otherwise be hitting the pub going into the weekend

This time we're going to focus on a recurring theme for YUI community contributors that are just getting started building their own modules: How to build a Widget and how to build a Plugin in a YUI 3 way.

Anthony Pipkin, aka apipkin of #yui IRC channel fame, will be the guest, guiding us through his learnings over the last year and showing how to move from copying and pasting the YUI 3 documentation examples to feeling confident that you're making the right choices for how to approach a problem in a "YUI 3 way of thinking".

We'll take a look at two of his simpler Gallery modules, the Button Widget and the Node IO Plugin. He'll discuss what they looked like originally, versus today, and why they changed.

Then we'll play around a while, maybe build something from scratch based on what the folks on the call want to cover.

Matt Sweeney (Node, Selector, TabView, Grids, etc) and Satyen "the Guru" Desai (Widget, Plugin, Base, Attribute, etc) from the YUI team will also be on the call. So there will be best practices in the house.

For YUI 3 consumers that aren't (yet?) contributors, this call should still be valuable for understanding the thinking behind how YUI 3 widgets and plugins are built and what sort of patterns to expect from new YUI components. And no doubt there will be other great takeaways as always.

So add your 2 cents here for finer points that you want to discuss, or just get the conversation started early!

I'm going to have to push out this Open Hours to next Wednesday. I'm running behind on some upstream code for code freeze Friday.

I've really been looking forward to this episode, too. Aw well, delayed is better than canceled.

I'm looking forward to this, but an extra week will give me some more time to learn some new tricks. Thanks for the heads up Luke.

Here are some takeaways that I jotted down during the call:

Upcoming in 3.2_
Was going to be a larger release, but was shortened to focus on the mobile experience. Still, full of updates and new features, like
* Transition module for css3 transitions to take advantage of hardware acceleration when available.
* More submodularization of code that previously forked internally based on which browser the user is in. So use('moduleA',...) might resolve to moduleA-ie.js or moduleA-webkit.js. This has size and performance implications (in a good way).
* History module is being replaced with a new lighter implementation
* Synthetic events can now be defined to support delegation
* Offline cache utility
* And finally, grids are back in YUI 3 with a new leaner approach using inline-block

I'm personally really excited about the new grids, and look forward to earlier adopter feedback.

There was a bit of explanation around the pattern


that was eventually obviated by


and Satyen mentioning that he will be creating a new method to avoid the odd empty array in there. I'm curious if folks think it would be valuable to document this explanation given the latter method is effectively the new recommended way to create subclasses.

Include @since (some version)
in your API docs (if you use YUI Doc) to denote new methods or attributes added after the initial module offering.

initializer (provided by Base) is where to put instance-construction-time code rather than in the constructor function itself. All instance attributes will be set up before initializer is executed.

this.publish( someEvent, { defaultFn: someBehavior } );
in the initializer facilitates an indirect method call to someBehavior, allowing implementers easy access to tweak the behavior of the code. So rather than


which could only be modified by clobbering the handleResponse method or using Y.Do.before/after (read up on these, they're pretty cool, too).

would allow subscribers to the success event to modify the response text or take action before or after the content was applied to the host object.

And finally, a little code pattern that seems to be coming into vogue right now:


This avoids an unnecessary assignment if foo is set coming into the function. It should be noted that jslint complains about this pattern and it compresses to 2 more characters than the "before" pattern. But it has the performance of the "original" pattern with 3 fewer characters. It's a bit idiomatic, though. It may become a common defaulting pattern, but probably for now it would be a good idea to include a code comment explaining that it's just applying a default value if not set (or otherwise falsey).