Should I prefer big Elm files?

The update function cannot split, but it can become a proxy function:

type Msg
    = MessageFromFunctionalityA FunctionaliyAMsg
    | MessageFromFunctionalityB FunctionaliyBMsg

update : Msg -> Model -> Model
update proxyMsg model =
    case proxyMsg of
        MessageFromFunctionalityA msg ->
            updateForFunctionalityA msg model

        MessageFromFunctionalityB msg ->
            updateForFunctionalityB msg model

This would be a simple implementation. You can create components as @pdamoc says, which is what you do when you have specialized init, update, model, subscriptions, etc.

1 Like

The update function cannot split, but it can become a proxy function:

Of course this will shorten the main update function, but I would never add boilerplate proxy for the sole purpose of reducing a file’s length.

If functionality A and B are already reasonably different I might end up using this approach regardless to split responsibilities; on the other if they are not logically separated hand I personally wouldn’t want to model my data solely around a meta detail like file size…

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.