Learn how to leverage the YUI 3.x infrastructure to create custom code that can be loaded easily and efficiently onto any page. Also discover how these mashups can combine YUI widgets and utilities with your own code and how to reuse code between different YUI instances.
Caridy is a Senior Frontend Engineer and JavaScript Nerd at Yahoo! and an active YUI contributor. He's also the creator of the Bubbling Library YUI Extension.
This talk will cover how to use YUI 3.x infrastructure to create individual pieces of code that can be injected in any page to carry on a certain functionality. Also how these mashups can combine YUI widgets and utilities with 3rd party codes and how to reuse them between different YUI instances.
I will talk about modules as the basic structures in YUI 3 Modules that are not part of YUI 3.0 How to Use and extend modules Organization and granularity: From global to granular approaches (Wordpress, Drupal, to Y! Front Page, Y! Mail, Gmail, Mint.com, etc) And finally, we will see how to bring legacy code into a YUI 3 implementation, including yui 2 stuff
Let’s start from the very beginning: Every piece of code, in yui 3, is a module, just like in yui 2 All the code in yui 3 was designed with the sandboxing capabilities in mind A module represent an individual piece of software that can work alone, or in conjunction with other modules. - YUI 3.0 was shipped with a limited set of modules
As you can see, modules can represent a widget: something that you will see in the page, like an overlay. Or just a low level utility to parse an string, like json utility. - Let’s see how we can use these built-in modules in a page
First of all, to use a module, we need a YUI instance, we call it sandbox. “ use” is the basic method to inject modules into a sandbox. RED elements represent a reference to the sandbox object “ use” includes the requirements in the page (in this case, just “node”) and then it calls the callback function
In this example we have 2 different modules playing together in the same sandbox
The origin of the new syntax in yui 3.x, and how sandbox works
similar feature, different syntax
you can call “use” at anytime. In this case the second callback receive a reference to a sandbox. Y2 === Y.
Now, what about those modules that are not part of YUI 3.0? Those modules that we will like to use in the daily basics Or those specific modules that we will like to have for one particular project
Now that we have the brand new YUI 3 Gallery, we will have custom modules created by YUI Contributors
And Finally, those modules that you will create for your app, for an specific project or just a piece of code that you will use in your daily basics.
Few example of modules from the gallery: YQL wrapper Time Picker Collapsible and Expandable elements
Few more examples of project and legacy modules: YUI 2.x tabview Survey widget
The module registration process represents the action of adding module’s metadata to YUI 3 Loader. It needs to know: what is the name of the module? where is located? what are the dependencies (requirements)? and few more settings at the module level
There are 3 different ways to register a module in yui 3. - By Seed - By Inclusion - By Configuration Let’s see each of them in details:
- Just keep an eye on the performance with this approach
- Recommended implementation
- You can organize your repository of modules at the top. - YUI_config is not ready yet, it will be ready in 3.1 - In the meantime, you can use MY_YUI_config object to pass it thru all the YUI instances in your page
Let’s focus on the implementation part and how we can extend the sandbox object
Let’s go deeper in these different types of implementations
Before going into the classes definitions, I will like to cover a set of utilities provided by YUI 3 to facilitate the creation of new classes.
Continuing with the counter example, this module can be build using a class implementation, defining the prototype for that class as a new member for the current sandbox.
Using the counter class
Plugin Definition
project-layout-lhs is a Custom Module to wrap a mashup implementation based on the previous example this new module can be now easily re-used thru a project/site/app It can also support specific configurations
Legacy code is a big pain, specially for FE, and YUI 3 is not an exception. As you know YUI 2 and YUI 3 can play nicely in the same page, but who should control who? And what about the code that we wrote on top of YUI 2.x? Or any other JS code? In this slide you can see a muckup using YUI 2.x tabview, and also a custom survey system How can we bring this to YUI 3?
Again, there are two ways to handle this: - Building a sandbox to wrap the legacy code, to delegate the loading process of all JS files to YUI 3 - The second option is to build a Custom Module to wrap the legacy code, and using this new module in your pages.
- Building a sandbox to wrap the legacy code, to delegate the loading process of all JS files to YUI 3
- The second option is to build a Custom Module to wrap the legacy code, and using this new module in your pages.