Owner

The app framework is going to need a way to coalesce changes to multiple attribute values (via setAttr()) into a single change event.

An app model might have a large number of attributes and many of those may change at once. The default app view behavior (though this is really up to the implementer) is to re-render an entire view
when a change occurs, and it's no good to have to re-render a view for each individual attribute rather than only once for the batch.

Satyen Desai

YUI Developer

I think Ryan and I discussed the transaction approach when it was implemented at the Model level, so nothing to really change there in terms of the implementation.

Need to address 2 concerns in moving it down to Attribute though. a) is solvable. I'm not sure b) is solvable without a performance hit.

a) At the attribute level, it seems like the name of the event needs to be something more specific than "change", since that's likely to conflict with impls. mixing in Attribute.

Thinking "attrChange", with the understanding that it rules out having an attribute called attr. Essentially I wanted something which conveys *Change.

I have it configurable currently on the prototype, so the component can change in back to "change" if required.

b) Performance hit if set() is also routed through setAttrs() which model currently does, so that it results in an "attrChange" event.

I think this is the right thing to do - since the developer listening for after("attrChange") expects to be notified even if a single attribute changes through the set() method.

However I'm concerned about doubling every attribute event fired (fooChange and attrChange). I'm not publishing the event to help with this (it's currently published with preventable:false, in Model, but if there's no defaultFn there's really no point publishing it with just preventable:false AFAIK), but even then, it seems heavy, until we make event firing closer to no-ops if no-one is listening.

Continuing to look at potential performance implications.

Satyen Desai

YUI Developer

There's a 40% increase on a Base based impl, setting 20 attributes, when set is routed through setAttrs (https://gist.github.com/2879339 added to src/base/tests/benchmark/base-benchmark.js) on Chrome. 20% on an iPad1 with iOS 5.

A. WITH set routed through setAttrs (2 events fired, no listeners):

Chrome:

1. 313 ops/sec
2. 292 ops/sec
3. 279 ops/sec

iOS 5, iPad1:

1. 48 ops/sec
2. 48 ops/sec
3. 49 ops/sec

B. WITHOUT set routed setAttrs (1 event fired, no listeners):

Chrome:

1. 398 ops/sec
2. 432 ops/sec
3. 421 ops/sec

iOS 5, iPad1:

1. 58 ops/sec
2. 59 ops/sec
3. 59 ops/sec

Based on the above, holding off rolling the setAttrs down to the Attribute layer, until I've had a chance to see if there's some low hanging performance fruit in Event, which we can get (especially for the case of no listeners) to not only offset the performance hit, but get a bit of a savings also.