Forums

I have just solved a problem that appeared to be difficult to solve using the documented API, and I wonder whether it is a new use case, or perhaps I am doing something stupid.

Here's the situation: I have a widget, and it has a data attribute containing a lot of complex data, including very long arrays. I like the luxury of change events fired when I set the attribute, but I cannot afford the duplication of my huge data object in newVal and prevVal. Because it is unlikely that my data attribute will change entirely, the newVal-prevVal pair does not really represent the change. Instead, I can use subAttrName to indicate where the change has occurred, but when the event fires, the facade object presents two deep-copied versions of the entire data object. I am concerned with the waste of resource this operation involves.

This is how the problem is created:

When the dataChange event fires, the listener gets two complete copies of the attribute, although it is also correctly informed about the change limited to in data.sbuAttr (and by the way, in this case, I don't need the old value).

The solution:

This works exactly as I need, but as with all solutions requiring poking around under the hood, I am convened with this solution's viability. Also, it makes me wonder wether I've got into this situation my making a wrong turn somewhere. But if it is a legitimate use case, why not provide a method for it?

In other words, I've often found myself wanting to decouple attribute setting and event firing, and I want it both ways. I have situations when I want to set the attribute value just once without firing the change event (I can unsubscribe all listeners for that one instant, but doing so can be painful), and there are situations when firing the change event without going through the vast ramifications of set() may be the right thing to do.

Thank you very much Satien,

All your recommendations are very helpful. Rejecting the event in the listener based on a payload parameter is a much better way than silencing it at the source. I did not realise I could mark the change events with a payload parameter to set() until I started poking around in the code yesterday. Somehow I missed it in the docs.

I need a different sort of decoupling of setting attributes and event firing...

I need to be able to set several different attributes as a group before the change events fire for any one of them. In other words, someone subscribing to the change event for A should be able to see the newly updated values of attributes A,B,C in the update event callback (because I set A,B,C as a "group").

The syntax of setAttrs() is what I want, but it fires a change event as each item in the group is set, whereas I need all items in the group set before then firing events for each item in the group.

I need this because it is my understanding that I can't subscribe to update events for subvalues foo.A or foo.B or foo.C; i.e. I can only subscribe to foo as a whole. Therefore I have made A,B,C separate ATTRs.
PLUS, even if I could, sometimes the A,B,C are so unrelated that it wouldn't make sense to cram them into a single foo ATTR.