So I just want to save the answers because the questions just I’m show them. But I don’t know if there is a way to extract the value of the input by id or something like that because I don’t want to use a model atribute for each input of answer.
type alias Model =
{ answers : Dict Int String
, ..
}
type Msg =
Answered Int String
update : Msg -> Model -> Model
update msg model =
case msg of
Answered id answer =
{ model
| answers = model.answers |> Dict.insert id answer
}
view : Model -> Html
view =
div []
[ div []
[ text "What's the answer to question 1?"
, input [Html.Events.onInput (Answered 1) ] []
]
, div []
[ text "What's the answer to question 2?"
, input [Html.Events.onInput (Answered 2) ] []
]
]
Personally I feel like Elm itself is not to blame, but rather we as community have not yet figured out a good and scalable way to deal with forms. Because they come in a lot of different shapes and forms, it’s often easier to have a case-by-case solution rather than a universal one.
Here is a list of packages that I can recommend for dealing with forms:
arowM/elm-form-decoder - Very good package for bigger forms, but most often an overkill. Also comes with a blog post. Of all solutions, that the one I recommend the most.
hecrj/composable-form - A plug-and-play solution, but personally I feel it’s a bit too restrictive.
etaque/elm-form - The most universal solution. Uses a dictionary behind the scenes. Therefore, no type safety.
malinoff/elm-uniform - A very good solution for a very specific problem (in place editing).
Personally I feel like Elm itself is not to blame, but rather we as community have not yet figured out a good and scalable way to deal with forms. Because they come in a lot of different shapes and forms, it’s often easier to have a case-by-case solution rather than a universal one.
I very much agree with this. My last job where I used React was building out huge forms, 20-50 dynamic fields, for use in insurance. We went with an approach of defining the fields with JSON and then building a massive custom framework for rending, updating, validating, and swapping out the fields contextually. The was a rewrite, of a rewrite, of a rewrite of a desktop app.
Even after 3 rewrites it was still complicated and difficult to manage. The first thing that would have been easier about writing it in Elm is that Elm is easier to refactor so we might have been able to do refactors instead of rewrite. The second thing that would have been easier in Elm is catching errors with Elm’s static types. We spent a lot of time trying to debug edge case errors that just wouldn’t have existed in Elm.
