[0.8]: observer callbacks changed parameter ordering

[ebidel]

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?

[Jeff17Robbins]

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 [email protected]
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.

[ebidel]

+1 also good point.

[justinfagnani]

FWIW, newValue as the first argument is much more convenient for use with one-arg functions.

[ebidel]

I haven't seen many people use Changed handlers as callbacks. 90% of the time you just use this.disabled to get the latest value.

[sjmiles]

Would prefer all official elements going forward to use:

fooChanged: function(foo) {
}

style.

But the lack of parallelism wrt attributeChangedCallback is a bit of a wrinkle.

[morethanreal]

Why do you prefer to use the parameter instead of this.foo?

[sjmiles]

It's more compact and less stateful. Parameterization is generally good factoring.

[jlg7]

if it is implicit that this.foo is always foo when the observer callback occurs, then isn't foo just more state? Doesn't 0.8 require 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.8 and existing 0.5 styles. A default can be decided over a thumb wrestling match.

[arthurevans]

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, observer could simple point to _biasTowardsTheNew directly.

[jlg7]

@arthurevans thank you for emphasizing this and have no argument for those who have that preference. I was addressing the parameter foo being more stateless and compact than this.foo in 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.

[sorvell]

A function that does not include this is truly stateless. In general, an observer that uses an argument name rather than a specific property can be used to observe different properties.

[jlg7]

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 this assuming no state is added in the implementation compared to the argument approach. Different element properties of the same name seem possible using the this approach and not sure if that would be the frequent case.

Additional decoupling in a behavior or in an element instance may occur after the properties are specifically mapped to an observer. A single property observer when attached to n properties of the same element instance fires n times 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.