Enhance the @bindable decorator with a <propertyName>Set handler

[estaylorco]

I'm submitting a feature request

• Library Version:
  1.4.1 (aurelia-templating)

Please tell us about your environment:

• Operating System:
  OSX 10.11.6

• Node Version:
  6.10.0

• NPM Version:
  4.3.0

• JSPM OR Webpack AND Version
  JSPM 0.16.53

• Browser:
  all

• Language:
  ESNext

Current behavior:
@bindable supports <propertyName>Changed event handlers. So, if one has a bindable property in a custom element named value, and if a method on the custom element's class called valueChanged is present, it will fire. This is great!

Expected/desired behavior:

It would be nice if @bindable supported <propertyName>Set event handlers. So, if one has a bindable property named value, and if a method on the custom element's class called valueSet is present, it will fire, anytime there's an attempt to set the value and regardless of whether the new value is the same as, or different from, the old value.

• What is the motivation / use case for changing the behavior?
  Sometimes the very act of setting a value on a bindable is meaningful in itself. Both setting and changing can have independent significance.

[bigopon]

@EisenbergEffect Is this desired? If yes how does this behavior play together with type coercion? I could put down some base gist if you could give some direction.

[EisenbergEffect]

Let's hold off for now.

…

Sent from my iPhone

On Aug 8, 2017, at 11:50 PM, bigopon ***@***.***> wrote: @EisenbergEffect Is this desired? If yes how does this behavior play together with type coercion? I could put down some base gist if you could give some direction. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[Alexander-Taran]

@EisenbergEffect keep in mind? won't happen?

[EisenbergEffect]

It might be better to investigate supporting existing getter/setter rather than more callbacks for vNext. I'd need to investigate how that might work. Maybe something like this psuedo code generated by the framework:

get foo() {
  return originalGet();
}
set foo(value) {
  originalSet(value);
  fooObservable.setValue(originalGet());
}

For this to work, there can't really be any other state that affects the values....

[fkleuver]

Thought about proxies?

[Alexander-Taran]

reminds me of this one
#579

[EisenbergEffect]

Can't use proxies for this because a proxy can't change the existing instance. It can only wrap an instance and then all activity has to go through the proxy. If anything has access to the original object, all observation would break.

[fkleuver]

The logic that applies the proxy could also peel the get/set property desciptors off of the original object and place them on the proxy instead. Then the proxy just needs to pass the changes back and forth - and with some flag you could tell it not to, so that binding won't notice a change. Whether it's clean is another story, but it should work right?

[EisenbergEffect]

The issue is that you would have to strictly control creation and referencing of all objects to make a proxy-based system work. Also, proxies are much slower.