Run this fiddle with the console open and you'll see that externally updating one of the two bound properties actually triggers setValue to be called for both properties even though only one of them was changed. What's worse is that I can't determine if the value was actually changed or not so any code I put in setValue would execute needlessly.
$.views.tags({
mytag: {
bindTo:["prop1", "prop2"],
template: "",
setValue: function(value, index, elseBlock) {
if (index == 0)
console.log("prop1 changed from " + value + " to " +this.tagCtx.props.prop1);
else if (index == 1)
console.log("prop2 changed from " + value + " to " +this.tagCtx.props.prop2);
}
}
});
var vm = {
prop1:"a",
prop2:"b"
};
$.templates("{^{mytag prop1=prop1 prop2=prop2 /}}").link("#ph", vm);
setTimeout(function() {
console.log("timeout..")
$.observable(vm).setProperty("prop1", "blah")
});
Usually I prefer to manually attach/detach $.observe listeners like this fiddle. Here you'll notice that only the event for the changed property is triggered and I have access to both the old value and the new value.
I know I've asked about this part before but I want to reiterate again, this time with some ideas.
Anyway I'm taking option 2 one step further as in this fiddle you can see how I introduced a helper function on prop2. I've deliberately named it scramble to make it obvious that it does have side effects. When prop1 is changed observably it triggers the whole tag to re-link and re-evaluate all it's bindings. This is giving me quite some headache.
1) onDataLinkedTagChange(ev, eventArgs) is called and eventArgs contains the name of the property that was actually changed. In this case prop1.
2) onDataLinkedTagChange executes this sourceValue = linkFn(source, view, $sub); which is responsible for re-evaluating all the bindings. In my case it looks like this:
3) onDataLinkedTagChange goes on to call mergeCtxs(tag, sourceValue, forceUpdate);
4) mergeCtxs calls $observable(tagCtx.props).setProperty(newTagCtx.props); which will trigger calling onProp2Change because onDataLinkedTagChange re-evaluated the links in step 2 and the scramble method returned a new value.
One thing that I'm hoping would be easy to fix is that onDataLinkedTagChange could pass along the name of the prop that actually did change when calling mergeCtxs such that it could update the property that did change and nothing else.
At least this prevents any change handlers from executing where you don't expect them to.
Next thing is the fact that all linked properties are re-evaluated and not just the one that changed.
One way to prevent needless execution would be to change the way the compiled link function is generated so that links are evaluated lazily such as this:
I'm hoping such a change wouldn't be all to hard to implement.
I can't imagine that the added overhead of calling a function would give any performance penalty nor should it add much to the code size.
The benefit would be way more efficient templates. Some of the problems I've noticed during the course of our project is related to this. The fact that you expect one change handler to be triggered but some other change handler also trigger. If these change handlers in turn trigger other change handlers the code quickly becomes very complex and I find that we have to write quite a lot of code to try to ignore false change events and the like.
Aside from less spaghetti code related to the change handlers, templates would also become more performant. In this contrived example nothing happens when prop2 is changed falsily but imagine that this tag was a root tag which contains a whole tree of other tags and changing prop2 as happens in this example would cause the whole tag tree to re-render and execute a bunch of logic.
So whatever minute performance impact adding lazyness to the compiled link function would incur it will most definitely be gained back by more efficient templates.
Thanks for commenting.
Yes it's more of a "nice to have" than something really important. Better leave it as is if complexity is high and time is low.
I think you can close this issue now.
Run this fiddle with the console open and you'll see that externally updating one of the two bound properties actually triggers setValue to be called for both properties even though only one of them was changed. What's worse is that I can't determine if the value was actually changed or not so any code I put in setValue would execute needlessly.
Usually I prefer to manually attach/detach $.observe listeners like this fiddle. Here you'll notice that only the event for the changed property is triggered and I have access to both the old value and the new value.
I know I've asked about this part before but I want to reiterate again, this time with some ideas. Anyway I'm taking option 2 one step further as in this fiddle you can see how I introduced a helper function on prop2. I've deliberately named it scramble to make it obvious that it does have side effects. When prop1 is changed observably it triggers the whole tag to re-link and re-evaluate all it's bindings. This is giving me quite some headache.
This is a stack trace as seen by setting a breakpoint in the
onProp2Change
handler1) onDataLinkedTagChange(ev, eventArgs) is called and eventArgs contains the name of the property that was actually changed. In this case prop1. 2) onDataLinkedTagChange executes this
sourceValue = linkFn(source, view, $sub);
which is responsible for re-evaluating all the bindings. In my case it looks like this:3) onDataLinkedTagChange goes on to call
mergeCtxs(tag, sourceValue, forceUpdate);
4) mergeCtxs calls$observable(tagCtx.props).setProperty(newTagCtx.props);
which will trigger calling onProp2Change because onDataLinkedTagChange re-evaluated the links in step 2 and the scramble method returned a new value.One thing that I'm hoping would be easy to fix is that onDataLinkedTagChange could pass along the name of the prop that actually did change when calling mergeCtxs such that it could update the property that did change and nothing else. At least this prevents any change handlers from executing where you don't expect them to.
Next thing is the fact that all linked properties are re-evaluated and not just the one that changed. One way to prevent needless execution would be to change the way the compiled link function is generated so that links are evaluated lazily such as this:
I'm hoping such a change wouldn't be all to hard to implement. I can't imagine that the added overhead of calling a function would give any performance penalty nor should it add much to the code size.
The benefit would be way more efficient templates. Some of the problems I've noticed during the course of our project is related to this. The fact that you expect one change handler to be triggered but some other change handler also trigger. If these change handlers in turn trigger other change handlers the code quickly becomes very complex and I find that we have to write quite a lot of code to try to ignore false change events and the like. Aside from less spaghetti code related to the change handlers, templates would also become more performant. In this contrived example nothing happens when prop2 is changed falsily but imagine that this tag was a root tag which contains a whole tree of other tags and changing prop2 as happens in this example would cause the whole tag tree to re-render and execute a bunch of logic.
So whatever minute performance impact adding lazyness to the compiled link function would incur it will most definitely be gained back by more efficient templates.