Cursor jumps around with onChange

[JBetz]

The virtual-dom bug with cursors jumping on text input fields has carried into style-elements. But unlike elm-html, we don't have the ability to use defaultValue instead of value for text input elements, so we don't have a (temporary) solution for this problem.

Can support for defaultValue be added, at least until virtual-dom gets fixed?

Specific issue: https://github.com/elm-lang/html/issues/105 General issue: https://github.com/elm-lang/virtual-dom/issues/107

Problem: https://ellie-app.com/9z4fG4JSVa1/0 Solution: https://ellie-app.com/3fPSxX6VHK7a1/0

Note: you have to type really fast to reproduce the issue in the given Ellie, but as soon as the onChange event becomes non-trivial, it really becomes a problem.

Versions

• Elm: 0.18
• style-elements: 4.0.0

[mdgriffith]

Thanks for bringing this up.

I'm trying to work out a solution, though not quite sure how to 100% resolve this.

If make it so that the text inputs use defaultValue instead of value, things seem to work, except as soon as the input loses focus it won't respond to the value being set for it. In that case if your model were to change, those changes wouldn't be reflected in the input.

I thought about added the text inputs behind a keyed element, with the key being the content of the text input...but that fails because as soon as the key changes, you get kicked off of focusing on the element, which makes sense in retrospect.

Maybe the solution is to render to defaultValue and then have the library-user write the keyed, refresh part if they're changing the value in the model. That's not ideal because it's still unexpected behavior...but maybe that works for the interim?

Thoughts?

[mdgriffith]

OK, I'm also adding textKey as an option so at least the key part of everything is slightly easier.

[JBetz]

If make it so that the text inputs use defaultValue instead of value, things seem to work [...].

That seems to have fixed it for me. I haven't been able to reproduce on any of the text input fields in my application. Thanks!

[...] except as soon as the input loses focus it won't respond to the value being set for it. In that case if your model were to change, those changes wouldn't be reflected in the input.

Hmm. Does that mean that there isn't a way to mark the input field as dirty from the perspective of the virtual DOM? And what if an element wrapping the input field were to be modified on some way?

Maybe the solution is to render to defaultValue and then have the library-user write the keyed, refresh part if they're changing the value in the model. That's not ideal because it's still unexpected behavior...but maybe that works for the interim?

Can you write an example of this? I'm not sure what the "refresh part" you're referring to is, and this is a case I'll need to be able to handle relatively soon.

[eniac314]

I am having the same problem, I don't understand how to write the keyed, refresh part when changing the value in the model.

[mdgriffith]

Ok, so the textKey should be a value that only changes when your update changes the value in a way that's not directly a result of the user input.

A classic example would be to store a counter : Int in your model, and if the value of your text input is modified at all by your update statement, meaning if you're doing anything other than storing the exact value the onChange msg is giving you, then increment the counter.

Then set the textKey on the input as toString model.counter.

[eniac314]

That did the trick, thank you!

[JDemler]

Can I safely assume, that this is fixed with elm 0.19 and style-elements 5.0.0?

[mdgriffith]

I believe it is, yeah: https://github.com/elm/html/commit/4912804dadbb2e7cdb6effa8ee737d2e08a96247

[JDemler]

Awesome. Thanks!