Forums

This was something I found very strange when I began working with YUI 3. Arguments passed to a custom event do some sort of mix with the event façade.

Here's the documentation: http://yuilibrary.com/yui/docs/api/clas ... ethod_fire

If the first argument is an object literal and the event is configured to emit an event façade, the event façade will replace that parameter after the properties the object literal contains are copied to the event façade.

Does this seem weird to anyone else? Why would I want my arguments to get garbled with the event façade?

I don't have many custom events which accept arguments, but when I do I always have to code around this. I insert an empty object so my real arguments don't get mixed.



Then I can easily listen to the event:



This feature doesn't make sense to me so I'm just wondering if I'm missing something. What do people use this for?

Okay, I can see that. I usually use custom events in a very different way from DOM events so it hadn't occurred to me to try to mimic them.

I agree about passing objects around instead of individual arguments.

I usually follow a pattern something like this:



That has been working out quite well. I just have to remember the extra {}.

In most of my custom event handlers I ignore the eventFacade object; I don't frequently need it. I'm not afraid of copying over its properties but I am afraid of its properties contaminating my data. Here's a made up example:

Suppose my object, which extends base, has some function which requests data of a web service through jsonp. When the response comes in, a 'response' event is fired on my object. If the jsonp response object was passed as a parameter, it suddenly gets extra properties added to it when the event handler receives it. This isn't good when my event handler is expecting a clean response object.

I see two fairly simple ways to overcome this. The first is the way I described above, by passing an empty object as the 2nd parameter to fire. The 2nd is to wrap the response in a new object like

{response: responseObject}

then this new response property will be available on the eventFacade.

I've been using the first way because it happened to be the first thing I thought of the first time I realized my event data was getting mixed in with extra properties.

I just now started a jsFiddle so I could test what happens either way when emitFacade is turned on or off. I published events 'a' and 'b'. I gave them both the same defaultFn which spat out its arguments. For 'a' I set emitFacade: true and for 'b' I set emitFacade: false. Then I fired both events and passed along an object of stuff as the 2nd argument.

The first thing I discovered, it seemed like 'b' wasn't getting fired. The common defaultFn only ran once. I tested by trying: .on('b', defaultFn) and that worked, the arguments were unexpectedly very different, and it took me a moment to figure this out.

The api docs for eventTarget.publish say that emitFacade defaults to false. I don't frequently use the eventFacade, so I usually omit this parameter and let it default to false. When I first tried out YUI 3's custom events, I did this and it worked. I never had any big need to enable facades. I've been copying this pattern ever since.

In my jsFiddle, I specifically set emitFacade to false and it works very different from what I've seen in my other projects. Are the docs wrong? Has emitFacade been defaulting to true on all my events?

If that's the case, this is a silly thing for me not to have noticed all this time. Now I'll need to adjust my way of thinking when it comes to custom events. I am glad I posted my little design decision question. I was thinking event facades were only useful when bubbling or broadcasting the event. I use default functions frequently.

Indeed! I learned something too.

I appreciate the ticket. I'll have to think about the best way to handle it, though. The Attribute API doc link you included has the publish method because it's inherited from EventTarget. So those are EventTarget's method docs showing, which as you noted, are only appropriate for some of the configuration properties.

If I changed the ET API docs, it would likely have to include the removal of default values, which is seldom a good thing for API docs. Otherwise, new API docs would need to be written in Attribute's source to indicate different behavior, but such would need to happen for every class that directly extends or is augmented with EventTarget. That would be a maintenance nightmare if EventTarget should change.

I'll think on it. Let me know in the ticket if you think of some better language.