Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Awkward situation with text inputs and the fix of #91 #158

Open
JDemler opened this issue Sep 3, 2018 · 0 comments
Open

Awkward situation with text inputs and the fix of #91 #158

JDemler opened this issue Sep 3, 2018 · 0 comments

Comments

@JDemler
Copy link
Contributor

JDemler commented Sep 3, 2018

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, textKeys where used. Link to the docs for historical reference

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.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant