Basically that meant, the application could push an update of the inputs value when it seemed fitting. We used the onBlur event to push updates. Internally though, the model could store an up-to-date value.
How was this useful?
When having input fields that need to be validated or parsed (for example as int or float), the user often types invalid inputs in the course of producing valid inputs.
This was fine, because we didn't care. We received an update with every keystroke, and the model updated with every keystroke, but basically the DOM stored the invalid results and the user was able to continue typing.
When the user finished, and moved to the next input field, or the submit button, we would send an update of the input-fields contents by incrementing the textKey. If its was invalid, the user would now look at an empty input field, and notice their error.
Current Situation
With the bug now fixed, we cannot control when the DOM is updated without keeping some extra state in the model. That would basically result in something like reimplementing the bug; keeping all the textKeys, the extra Msgs and more complex calls to Input.text. Probably one would need to store two values per field, current and currently displayed.
See this ellie-example. (It use plain html instead of style-elements but the problem is identical)
The underlying problem is, that every keystroke results in an update. (Text.onChanged is actually implemented as Html.Event.onInput: here and here
Every update results in a call to view, and now, with #91 fixed, every call to Input.text results in its value being displayed correctly.
The possible solution
If updates are only sent onChange, though this problem is far less significant (if not actually fixed).
The user can type, and if they press enter or change focus, we get our update.
I realize, that this is a massive breaking change. I also agree, that style-elements is somehow obsolete.
So consider this issue more of a hint for people who also run into this problem.
The proposed change is trivial and implemented in our fork.
With elm 0.18 input fields where buggy: when their value was set in the view, the change would not be reflected in the DOM correctly.
To fix this,
textKeyswhere used. Link to the docs for historical referenceBasically that meant, the application could push an update of the inputs value when it seemed fitting. We used the
onBlurevent to push updates. Internally though, the model could store an up-to-date value.How was this useful?
When having input fields that need to be validated or parsed (for example as int or float), the user often types invalid inputs in the course of producing valid inputs.
This was fine, because we didn't care. We received an update with every keystroke, and the model updated with every keystroke, but basically the DOM stored the invalid results and the user was able to continue typing.
When the user finished, and moved to the next input field, or the submit button, we would send an update of the input-fields contents by incrementing the
textKey. If its was invalid, the user would now look at an empty input field, and notice their error.Current Situation
With the bug now fixed, we cannot control when the DOM is updated without keeping some extra state in the model. That would basically result in something like reimplementing the bug; keeping all the textKeys, the extra
Msgs and more complex calls toInput.text. Probably one would need to store two values per field, current and currently displayed.See this ellie-example. (It use plain html instead of style-elements but the problem is identical)
The underlying problem is, that every keystroke results in an update. (
Text.onChangedis actually implemented asHtml.Event.onInput: here and here Every update results in a call to view, and now, with #91 fixed, every call toInput.textresults in its value being displayed correctly.The possible solution
If updates are only sent
onChange, though this problem is far less significant (if not actually fixed). The user can type, and if they press enter or change focus, we get our update.See this example.
I realize, that this is a massive breaking change. I also agree, that style-elements is somehow obsolete. So consider this issue more of a hint for people who also run into this problem.
The proposed change is trivial and implemented in our fork.