2016-12-21 21:36 GMT+01:00 Wouter In t Velt :
> Seems input [ type_ "number" ] behaves weird in different ways.
Oh yes, definitely, I forgot to explicitly say that. :)
What I wanted to point out in my example is that defaultValue can't be
considered a viable solution not only because of the leaka
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 probl
Op woensdag 21 december 2016 22:04:44 UTC+1 schreef Alexandre Galays:
>
> - 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 t
- 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 l
Op woensdag 21 december 2016 21:02:04 UTC+1 schreef Rafał Cieślak:
>
> Here's an example: https://runelm.io/c/q6z
>
Interesting! The fast-typing-makes-cursor-jump-to-end does not appear to
happen in the number type with value set.
Still, I find different weird behavior in type number in both exa
śr., 21 gru 2016 o 19:09 użytkownik Wouter In t Velt <
wouter.intv...@gmail.com> napisał:
> Do you still set the input value + onInput handler in the lazy variant?
> And does that also somehow prevent the "leak" of input value to a next
> render?
>
>
> Recently I ported 0.16 app where I used "lazy
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 o
I'm not currently doing this as I was not aware of this problem. But what I
was thinking is very simple. What I'm doing now is always redirecting to a
new url (hash change) after the http request is successful. Then I would
change the redirect function like:
redirect location = Cmd.batch [formR
Is there a good reason (other than a defect) that the cursor jumps at all?
It seems to me that the correct behavior is for the cursor to stay right
after the text that was just typed.
On Wed, Dec 21, 2016 at 10:09 AM Wouter In t Velt
wrote:
> Thanks all for sharing your approach to this!
>
> Op
Thanks all for sharing your approach to this!
Op woensdag 21 december 2016 17:33:28 UTC+1 schreef Bernardo:
>
> For me the solution would be to perform a form.reset() before rendering
> the new view.
>
Interesting: Could you elaborate on how you do that?
Re-render the form with a one-time reset
When dealing with forms in SPAs I perform certain actions on form
submission to mimic the expected behavior, like scrolling to the top of the
page. For me the solution would be to perform a form.reset() before
rendering the new view.
On Tuesday, 20 December 2016 18:03:28 UTC-3, Wouter In t Velt
11 matches
Mail list logo
