Change event does not always trigger on dropdowns with bound values

[rmehlinger]

In the following example, $input3's value is bound to the selected option of $input2. Which of $input2's options is selected is bound to $input1. If we manually change the selected value of $input2, $input3's value updates as expected. If we change the value of $input1, $input2's value also updates as expected; however, $input3's does not. I suspect this is because updating $input1 does not directly change the value of $input2, but rather changes the selected attribute on its options.

R.div {}, [
  $input1 = R.input {type: 'number', value: 0}
  $input2 = R.select {}, [
    R.option {value: 1,  selected: bind ->  parseInt($input1.rx('val').get()) > 0}, 'positive'
    R.option {value: 0,  selected: bind ->  parseInt($input1.rx('val').get()) == 0}, 'zero'
    R.option {value: -1, selected: bind -> parseInt($input1.rx('val').get()) < 0}, 'negative'
  ]
  $input3 = R.input {type: 'number', value: bind -> $input2.rx('val').get()}
]

[rmehlinger]

Workaround:
You can bind to the value attribute of the select instead, and it works as expected. If this is a no-fix, then we should document that binding to selected on options is deprecated.

[yang]

Damn, thought this was already documented. I'll document this.

Unfortunately there's no way to make that happen. .rx('val') is a
shortcut, but there are many ways that an input's state can be reset
without a .change() event getting fired. For instance, someone could
have simply set the maxchars on an input text box to be 0, and then
suddenly the value would be "". Or for a select, the code could have
removed some options from the select, including the currently selected
value, causing it to switch to another (remaining) value. It's not
impossible to exhaustively capture any possible such change (e.g. something
heavy handed like DOM mutation observers), but it's Hard. Another option
is to implement something that works in some scenarios (like if the input
is bound to something) but not others, but that's a halfway solution that
sometimes works and sometimes doesn't.

In this particular case, you can get what you want simply by lifting out
the states and explicitly actuating that state.

I'm not sure what you mean by saying you can bind to the value attribute of
the select—that sounds non-reactive, i.e. updating the select's value won't
propagate any events (unless there is some other event already happening).

On Wednesday, September 2, 2015, Richard Mehlinger <notifications@github.com
javascript:_e(%7B%7D,'cvml','notifications@github.com');> wrote:

Workaround:
You can bind to the value attribute of the select instead, and it works
as expected. If this is a no-fix, then we should document that binding to
selected on options is deprecated.

—
Reply to this email directly or view it on GitHub
#67 (comment)
.

[rmehlinger]

By binding the value, I mean the following:

R.div {}, [
  $input1 = R.input {type: 'number', value: 0}
  $input2 = R.select {value: bind -> parseInt($input1.rx('val').get()}, [
    R.option {value: 1}, 'positive'
    R.option {value: 0}, 'zero'
    R.option {value: -1}, 'negative'
  ]
  $input3 = R.input {type: 'number', value: bind -> $input2.rx('val').get()}
]

This works as intended, with $input3 reacting to changes in $input2's value triggered by changes to $input1