Repository navigation
[0.8]: observer callbacks changed parameter ordering #1363
Description
Activity
Since the order in attributeChangedCallback is oldValue, newValue, it would
seem that the 0.5 order was more consistent, and so more memorable. So
that's a reason to NOT change the ordering and leave it as it is in 0.5.On Thu, Apr 2, 2015 at 1:58 PM, Eric Bidelman notifications@github.com
wrote:0.5: disabledChanged: function(oldValue, newValue) {
0.8: disabledChanged: function(newValue, oldValue) {
It's a very subtle change and easy to miss...adds "one more thing to do"
when porting 0.5 code :(Was there a reason to change the ordering?
—
Reply to this email directly or view it on GitHub
#1363.+1 also good point.
FWIW,
newValueas the first argument is much more convenient for use with one-arg functions.I haven't seen many people use Changed handlers as callbacks. 90% of the time you just use
this.disabledto get the latest value.Would prefer all official elements going forward to use:
fooChanged: function(foo) { }
style.
But the lack of parallelism wrt
attributeChangedCallbackis a bit of a wrinkle.Why do you prefer to use the parameter instead of
this.foo?It's more compact and less stateful. Parameterization is generally good factoring.
if it is implicit that
this.foois alwaysfoowhen the observer callback occurs, then isn'tfoojust more state? Doesn't0.8require explicit observer properties configuration which may heighten how stative it is?<script> FooChanges = { properties: { foo:{ type:String, value:"orderMatters!", observer:"fooChanged" } }, fooChanged:function(){ this._biasTowardsTheNew(this.foo); }, _biasTowardsTheNew:function(foo){ console.log("Communicating about how to communicate change is difficult"); } } </script>
Perhaps exposing an additional configuration parameter when annotating a property observer might be useful to appease single arg new bias
0.8and existing0.5styles. A default can be decided over a thumb wrestling match.I think Scott's point was that if the order is new, old, then you can use a single-argument observer, too. That is, in your example,
observercould simple point to_biasTowardsTheNewdirectly.@arthurevans thank you for emphasizing this and have no argument for those who have that preference. I was addressing the parameter
foobeing more stateless and compact thanthis.fooin the context of a polymer element with a properties object and explicit observer configuration. It seems like it adds more to the mix to me. I am definitely PRO single argument observer but seems to be more of a preference when setting up your observations.A function that does not include
thisis truly stateless. In general, an observer that uses an argument name rather than a specific property can be used to observe different properties.TYVM! I absolutely agree with stateless function definition and ease of reuse! Just reiterating, the polymer/behavior declaration has no additional state after the observer callback using
thisassuming no state is added in the implementation compared to the argument approach. Different element properties of the same name seem possible using thethisapproach and not sure if that would be the frequent case.Additional decoupling in a
behavioror in an element instance may occur after the properties are specifically mapped to an observer. A single property observer when attached tonproperties of the same element instance firesntimes when one of them is changed with no way to differentiate. I believe this does require some delegation in the implementation already to have reuse.
0.5:
disabledChanged: function(oldValue, newValue) {0.8:
disabledChanged: function(newValue, oldValue) {It's a very subtle change and easy to miss...adds "one more thing to do" when porting 0.5 code :(
Was there a reason to change the ordering?