How do you manage an explosion of update paths/Msg constructors? - elm

Question

I've finished the Elm guide and noticed on very simple examples, the update function grows to 3 cases and the Msg type can have 3 constructors. I imagine on an intermediate project, this would grow to 20 and on an advance project, it might be hundreds. How do you manage this? I foresee this being a source of version control contention if every developer needs to add a new constructor for their feature.
I worked on a react-redux project and it has a concept of combining reducers to solve this problem. I did not run across that concept in Elm. Does it have one?

Answer 1

You can define msg type consists of child/sub msg types, and of course, updater can be combined with sub functions. ie.
-- Counter
type CounterMsg
= Increment
| Decrement
type alias CounterModel =
Int
updateCounter : CounterMsg -> CounterModel -> ( CounterModel, Cmd msg )
updateCounter msg model =
case msg of
Increment ->
( model + 1, Cmd.none )
Decrement ->
( model - 1, Cmd.none )
-- Todo
type TodoMsg
= AddTodo String
type alias TodoModel =
List String
updateTodo : TodoMsg -> TodoModel -> ( TodoModel, Cmd msg )
updateTodo msg model =
case msg of
AddTodo str ->
( str :: model, Cmd.none )
-- unified
type alias Model =
{ counter : CounterModel
, todos : TodoModel
}
type Msg
= Counter CounterMsg
| Todo TodoMsg
initModel =
{ counter = 0, todos = [] }
update : Msg -> Model -> ( Model, Cmd msg )
update msg model =
case Debug.log "message" msg of
Counter countermsg ->
let
( newmodel, cmd ) =
updateCounter countermsg model.counter
in
( { model | counter = newmodel }, cmd )
-- etc...
_ ->
( model, Cmd.none )

Answer 2

Take a look at Richard's implementation for RealWorld/Conduit. It provides a realistic way to structure a large enough app (few thousands lines of code).
In short, on complex projects there is the idea of a Page that can have its own model and update and view.
Within each page you could have a large Msg but that is not really an issue. 20 tags is actually quite manageable. 50 is also manageable as discovered by NoRedInk programmers in their production code.

Answer 3

There's a decent tutorial on the topic here: https://www.elm-tutorial.org/en-v01/02-elm-arch/07-composing-2.html
I wish it showed the source of the Widget, but I can imagine what it looks like. Inlining for posterity.
module Main exposing (..)
import Html exposing (Html, program)
import Widget
-- MODEL
type alias AppModel =
{ widgetModel : Widget.Model
}
initialModel : AppModel
initialModel =
{ widgetModel = Widget.initialModel
}
init : ( AppModel, Cmd Msg )
init =
( initialModel, Cmd.none )
-- MESSAGES
type Msg
= WidgetMsg Widget.Msg
-- VIEW
view : AppModel -> Html Msg
view model =
Html.div []
[ Html.map WidgetMsg (Widget.view model.widgetModel)
]
-- UPDATE
update : Msg -> AppModel -> ( AppModel, Cmd Msg )
update message model =
case message of
WidgetMsg subMsg ->
let
( updatedWidgetModel, widgetCmd ) =
Widget.update subMsg model.widgetModel
in
( { model | widgetModel = updatedWidgetModel }, Cmd.map WidgetMsg widgetCmd )
-- SUBSCRIPTIONS
subscriptions : AppModel -> Sub Msg
subscriptions model =
Sub.none
-- APP
main : Program Never AppModel Msg
main =
program
{ init = init
, view = view
, update = update
, subscriptions = subscriptions
}
I think this is the same idea behind https://stackoverflow.com/a/44275318/61624 but it has more description.