The text in a multiline input doesn't always match the value set in its `text` field. about elm-ui HOT 11 CLOSED

Ok, yeah this is something on the elm/html level. If I switch to an Input.text, then I don't see them getting out of sync:

https://ellie-app.com/3cLXQcSYMcqa1

I know the virtualdom library special-cases input elements and input, so it might not be special-casing textarea.

from elm-ui.

I added a PR. It seems to fix the examples here, like this one: https://ellie-app.com/52FxBzLnVFDa1

from elm-ui.

mdgriffith suggested trying the value attrib on Slack, so I gave it a try. So far this is working well, and no key counters to keep track of:

import Html.Attributes as HA
import Json.Encode as JE

workAroundMultiLine :
    List (Attribute msg)
    ->
        { onChange : String -> msg
        , text : String
        , placeholder : Maybe (Input.Placeholder msg)
        , label : Input.Label msg
        , spellcheck : Bool
        }
    -> Element msg
workAroundMultiLine attribs mlspec =
    Input.multiline (htmlAttribute (HA.property "value" (JE.string mlspec.text)) :: attribs)
        mlspec

from elm-ui.

Thank you @bburdette . My solution was to use Html.textarea instead.

            Element.html
                (Html.textarea
                    [ Html.Attributes.value model.currentMessage
                    , Html.Events.onInput MessageUpdate
                    , Html.Attributes.rows (rowCount model.currentMessage)
                    ]
                    []
                )

Where rowCount is a function that estimates the needed number of rows.

from elm-ui.

@mdgriffith I can confirm the fix by @bburdette

from elm-ui.

Interesting!

I'm wondering if this is really behavior due to Elm itself versus this library.

I've put your code into an ellie.

The super weird part, is if you open up the inspector and take a look at the textarea elements when they get out of sync...they're actually showing the same internal text, it's just not rendering. 🤔 At least in firefox.

from elm-ui.

I've found this issue in elm/html:
elm/html#55

There is also mentioned a workaround in a comment in another issue:
evancz/elm-html#81 (comment)

from elm-ui.

Just logging that this still is an issue with recent elm/[email protected].
Also, Keyed workaround suggested in evancz/elm-html#81 (comment) has a flaw that newly generated textarea DOM will lose focus (since it is a different DOM than the previous one?), makes it almost unusable.
Edit: Actually, I misread the workaround which introduces "sequence counter" that will be incremented on reset/submit and uses that number as a key for Keyed. That should work.
On the other hand, naively using text stored in your model as a key will cause new DOMs to be generated every keystroke, which doesn't work (loses focus on every keystroke).

from elm-ui.

Here is an ellie where I compare the behaviour of elm-ui and elm/html. https://ellie-app.com/52FxBzLnVFDa1

The fields are Html.input, Html.textarea, Input.text and Input.multiline. All except the last behaves as expected. When the model changes, so do they. The last one, multiline, does also change unless you have typed anything. Then what you have typed, gets stuck.

I expected the multiline to behave more like the others.

from elm-ui.

Looking into this with developer tools, I can see a difference between Html.textarea and Input.multiline. When I change the text, Html.textarea still is <textarea></textarea> while Input.multiline becomes <textarea>Entered text</textarea>.

It is beyond me how the textarea element works in the browser. I thought what elm-ui does was correct.

from elm-ui.

Ok, some more digging. When I change the model, Html.textarea changes the value attribute of the <textarea>. Input.multiline does not, it changes what is between the tags, instead.

I found this by setting id on the textareas and looking in the console.

from elm-ui.