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
select(
value <-- $value,
children <-- $children
)
When we set the value property, what the DOM "really" does is set selected := true attribute on the corresponding option element inside the select element. But, it is quite possible that such an option does not exist yet when the select element's value and children are coming from different observables – they might not sync naturally, so when a change happens it's possible that $value will emit before the change propagates to $children. This case should be fixable with the syncDelay operator and/or moving the children <-- $children modifier to beforevalue <-- $value. However, what exactly needs to be done depends on whether the observables involved are signals or streams or a mix.
In the more general case, $children might be completely out of sync with $value, e.g. the former might have an async delay (yet the $value still knows what the value should be without the delay? Kinda sus...). In this case, $value should be something more like $value.combineWithFn($children)((v, _) => v) (but not exactly that).
Proper solution right now that is guaranteed to work in all cases is setting the selected prop on every option instead of setting the value prop on the parent select element. But that can get annoying.
We provide an API for controlled inputs, which fundamentally solves a similar problem. Maybe we could provide a similar helper here as well which would do the right thing. Something like this perhaps?
select(
controlled(
value <-- $value,
children <-- $children
)
)
It's not quite clear what "the right thing" should be in this case. Not sure how this would interact with setting the selected prop on child option elements, or with the controlled inputs feature (what if we want this select to be a traditional controlled input too).
The text was updated successfully, but these errors were encountered:
Reported in gitter. Consider this:
When we set the
value
property, what the DOM "really" does is setselected := true
attribute on the correspondingoption
element inside theselect
element. But, it is quite possible that such an option does not exist yet when theselect
element'svalue
andchildren
are coming from different observables – they might not sync naturally, so when a change happens it's possible that$value
will emit before the change propagates to$children
. This case should be fixable with thesyncDelay
operator and/or moving thechildren <-- $children
modifier to beforevalue <-- $value
. However, what exactly needs to be done depends on whether the observables involved are signals or streams or a mix.In the more general case,
$children
might be completely out of sync with$value
, e.g. the former might have an async delay (yet the$value
still knows what the value should be without the delay? Kinda sus...). In this case, $value should be something more like$value.combineWithFn($children)((v, _) => v)
(but not exactly that).Proper solution right now that is guaranteed to work in all cases is setting the
selected
prop on everyoption
instead of setting thevalue
prop on the parentselect
element. But that can get annoying.We provide an API for controlled inputs, which fundamentally solves a similar problem. Maybe we could provide a similar helper here as well which would do the right thing. Something like this perhaps?
It's not quite clear what "the right thing" should be in this case. Not sure how this would interact with setting the
selected
prop on childoption
elements, or with the controlled inputs feature (what if we want this select to be a traditional controlled input too).The text was updated successfully, but these errors were encountered: