Forums

Hey,

I just started using YUI 3 for our web app and enjoy developing so far. I've come across one really weird issue, which brought up the question of whether to use multiple YUI instances or not.

Let me show you what I did first:


In this example, log function is not called in the order you would expect (the code in test.js was called last). I had this working in a test script and could not figure out what the difference was, until I finally saw that I had used

which made it work.

The documentation seems to suggest that you should use separate YUI instances, so I created a new instance for pretty much every call to YUI.

So what is the best practice concerning instantiation of YUI? Is it "ok" to just use

And use this (global) instance everywhere? This works great in the example I listed above, but is it really the way to go?

Caridy, thanks for the quick answer.


We're a team of two developing a web app that doesn't need high performance, so I'd like to make developing with YUI as easy as possible.


Well if that's so than I spotted a bug! Check this example (basically a working version of the code in the opening post). I would expect the different scripts to be executed in the order they appear in the document. If I use a global instance, this is exactly what happens!

As I said in the opening post, if I use "YUI.use()" (instead of "YUI().use()") everywhere, the code works as expected. But is that a bug or a feature?


What do you mean with XYZ?


That sounds like a good idea for js-driven apps, but it's a bit overkill for ours. We just want to enhance usability here and there and use one library for cookies, AJAX requests, DOM enhancements, tabs, etc.

Like I described, if I use different instances, the domready events don't fire in order, so I was wondering if adding
var Y = YUI().use( '*' );
to the bottom of yui.js and using Y everywhere is considered a bad practice with significant drawbacks.

Kind regards,
Jeroen

Btw, wraping with XYZ.use was just a statement. What It means is that you should wrap any YUI related code into a YUI().use() statement.



Best Regards,
Caridy

Thanks a lot for all your replies Caridy and Luke!


Ok, I see that my use of YUI caused the problem. I don't understand at all why the order of calls is in reverse though, but let's just accept that if I don't play by the rules, quirky behavior is the appropriate punishment



I use a library called mktree which converts a <ul> into a expandable / collapsable tree. So on every page load, the library scours the page for lists to convert. That's the first call. The second call is output dynamically (if the user is editing the form where an option from the tree was selected) and expands the tree to show a particular item and highlights it. This second call must be made after the tree has been converted.

I think this might be common pattern. One call does setup, the second assumes setup has been done. Of course it would be nicer to create a setup function which takes one (or more) callbacks as arguments instead of doing the calls, but that's the way it's written right now.


Ok, that's what I thought you meant. I actually don't like that elaborate setup because it makes simple code a lot harder to read. For example, if all I want to do is get a cookie, I'd prefer that to not take more than one simple line of code. That's why I'm looking for a way to do the initialization of one YUI instance once and use that everywhere.



That's exactly what I've done in the second example, and also add var Y = YUI().use( '*' ); to the end of yui.js, and use that global variable everywhere I need it.

That makes code easy to read, as I don't require the setup-with-callback, and all the calls are synchronous.

Dav Glass's quick_yui.js looks easy and clean, but since I load every module we need, what's the advantage of using this over of my "naive" one-liner initialization? As far as I can tell, quick_yui makes sure calls are made synchronously, but since I've loaded everything I need, YUI().use() is synchronous anyway, right?