Use default value for bindable component properties when undefined is passed as a value

[ekzobrain]

🙋 Feature Request

Consider that we have an CE:

class SomeComponent {
  @bindable()
  property: number = 1;
}

And a usage like this:

class SomeParentComponent {
  static template = '<some-component property.bind="outerProperty"></some-component>';

  outerProperty;
}

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.

😯 Current Behavior

undefined is passed to bindables

https://discord.com/channels/448698263508615178/545423969642217474/1007215994248384523

💁 Possible Solution

🔦 Context

💻 Examples

[ekzobrain]

@bigopon

[Sayan751]

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.

[bigopon]

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.

cc @fkleuver @brandonseydel @jwx

[jwx]

• 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 initial undefined 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).