- About the input being reused in another view; that's entirely normal. Any VDOM implementation can't know whether the input should be a physically different one unless it has a different class, id or key.
- About the cursor going crazy; this is a bug in Elm. I've seen that kind of bugs in at least 3 Virtual DOM implementations but it got fixed fast. Example: https://github.com/Matt-Esch/virtual-dom/blob/master/virtual-hyperscript/index.js#L44 On Tuesday, December 20, 2016 at 10:03:28 PM UTC+1, Wouter In t Velt wrote: > > Over on Slack the other day, there was some dialogue about input fields > going on. > > One was about an issue when you set the value in your elm code like this: > > input [ type_ "text", onInput HandleInput, value model.fieldValue ] [] > > Issue: when user types really fast, the cursor jumps to the end of the > input field. > > The proposed direction to take was to not set the value, but use > defaultValue instead. > > input [ type_ "text", onInput HandleInput, defaultValue model.fieldValue ] > [] > > Then, the DOM's input field value state is "unmanaged" by Elm, and the > cursor no longer jumps to the end when the user types. > And since the suggestion on slack was made by Richard Feldman, it must be > good, right :) > > But this creates a *potential leak of input field values*. > > When the next view output also contains an input field, the virtual DOM > may reuse that original input field (with good reason of course). > But reusing the input does not reset the input's value. In normal > situations this is exactly what we want, but not all cases. > > Not if the input field is on a different page. > The the user expects the field to be new, and the input to be empty. But > if vdom reused the previous field, it will again show the previous value. > Even if Elm code did set the defaultValue (the actual value always > overrides defaultValue). > > This may also happen if the input was a password. If after login a new > view is rendered with an input field, this new field (if it is a plain text > field), will then *reveal the previously typed password*. Which is surely > not what we want. > Elm example with "leaking" password here <https://runelm.io/c/tcp>. (on > awesome runelm.io). From discussion over on slack here > <https://elmlang.slack.com/archives/help/p1482099641001714>. > > Such a "leak" can be solved by using Html.Keyed, to make sure that the > input field will not be reused by virtual DOM. > (example here on runelm.io <https://runelm.io/c/y2j>) > > But I was wondering: > > - Has anyone else run into similar issues of input field values > "leaking" into new views? > - Is there a better way to *prevent* this from happening (rather than > relying on our predictive instincts and applying Keyed when we suspect a > leak)? > > PS this also happens in react (fiddle here > <https://fiddle.jshell.net/zpdfLqbh/1/>) > > -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
