What I found is that defaultValue can't really be used with number inputs that are controlled (in the sense that defaultValue is changes with the model as in the first example in the thread).
If you have such input, then start typing a valid number and then you add some commas/dots (depending on your locale) to make the input invalid – the value of the input gets erased. This problem doesn't exist with value. Here's an example: https://runelm.io/c/q6z 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.
