On Wednesday, 21 December 2016 18:04:44 UTC-3, Alexandre Galays wrote: > > - 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. >
The problem manifests in elm even if the name or id attribute of the input is different. > > - 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.
