You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
outerProperty is set to undefined, so SomeComponent.property will also be set to undefined, while in JS semantics undefined is treated as no value, so a default 1 should be used instead.
This is related both to initial assignment, and to further outerProperty changes.
馃 Expected Behavior
When first assigning values to SomeComponent instance, undefined values should not be set, so that default values are left untouched.
On further outerProperty value changes BindableObserver should check if new value is undefined and set a default in that case. Default values could be cached (may be in metadata) after viewModel invocation.
If I am not wrong, the current behaviour is similar to v1. Hence, introducing this behaviour would a breaking change and will potentially break many apps. Also, IMO that is counterintuitive. Currently, if you bind undefined, you get undefined.
Note that you can always use the BindableDefinition#set or the component lifecycle hooks to set the default values yourself.
For backward compat, we can leave it to our compat-v1 package, I think it's ok to focus on the intuitiveness of the behavior:
Does it make more sense to ignore first undefined value in binding, or does it make more sense to always react to the stream, regardless the value. I can see the pros:
if we ignore first undefined value (this proposal/request), child component can decide their own default value during construction, less surprising behavior
if we always react to value (v1 behavior), child component cannot distinguish between default value and value coming from parent easily, but it's simpler in the mental model, since there' no separation.
if we ignore first undefined value (this proposal/request), child component can decide their own default value during construction, less surprising behavior
I think this makes sense; for an initialundefined to mean "use default if you've got one". It also adds the possibility for the parent to only specify that which it wants to be specific about/knows about (while still having the outer properties present).
馃檵 Feature Request
Consider that we have an CE:
And a usage like this:
outerProperty
is set toundefined
, soSomeComponent.property
will also be set toundefined
, while in JS semanticsundefined
is treated as no value, so a default1
should be used instead.This is related both to initial assignment, and to further
outerProperty
changes.馃 Expected Behavior
When first assigning values to SomeComponent instance,
undefined
values should not be set, so that default values are left untouched.On further
outerProperty
value changesBindableObserver
should check if new value is undefined and set a default in that case. Default values could be cached (may be in metadata) after viewModel invocation.馃槸 Current Behavior
undefined
is passed to bindableshttps://discord.com/channels/448698263508615178/545423969642217474/1007215994248384523
馃拋 Possible Solution
馃敠 Context
馃捇 Examples
The text was updated successfully, but these errors were encountered: