Wie verwalten Sie eine Explosion von Update-Pfaden/Msg-Konstruktoren?

Question

Ich habe den Elm Guide fertiggestellt und bemerkt auf very simple examples, die update Funktion wächst auf 3 Fälle und der Msg Typ kann 3 Konstruktoren haben. Ich stelle mir vor, dass es bei einem Zwischenprojekt 20 werden würde und bei einem Vorprojekt könnten es Hunderte sein. Wie schaffen Sie das? Ich sehe voraus, dass dies eine Quelle für Versionskontrollkonflikte ist, wenn jeder Entwickler einen neuen Konstruktor für sein Feature hinzufügen muss.

Ich arbeitete an einem Reaktion-Redox-Projekt und es hat ein Konzept von combining reducers, um dieses Problem zu lösen. Ich bin in Elm nicht auf dieses Konzept gestoßen. Hat es eins?

Answer 1

Sie können definieren, msg type besteht aus Kind/Unter-msg-Typen, und natürlich kann Updater mit Unterfunktionen kombiniert werden. dh.

-- 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

Werfen Sie einen Blick auf Richard's implementation for RealWorld/Conduit. Es bietet eine realistische Möglichkeit, eine groß genug App (einige tausend Zeilen Code) zu strukturieren.

Kurz gesagt, bei komplexen Projekten gibt es die Idee einer Seite, die ihr eigenes Modell haben und aktualisieren und anzeigen kann.

Innerhalb jeder Seite könnten Sie eine große Msg haben, aber das ist nicht wirklich ein Problem. 20 Tags sind eigentlich recht überschaubar. 50 ist auch überschaubar, wie es von NoRedInk-Programmierern in ihrem Produktionscode entdeckt wurde.

Answer 3

Es ist ein anständiges Tutorial zum Thema hier: https://www.elm-tutorial.org/en-v01/02-elm-arch/07-composing-2.html

Ich wünsche es die Quelle des Widget zeigte, aber ich kann mir vorstellen, wie es aussieht. Inlining für die Nachwelt.

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 
     } 

Ich denke, das die gleiche Idee hinter https://stackoverflow.com/a/44275318/61624 ist aber mehr Beschreibung.