如何管理更新路径/消息构建器的爆炸?

时间:2017-05-30 20:35:58

标签: elm

我已经完成了榆树指南并注意到very simple examplesupdate函数增长到3个案例,Msg类型可以有3个构造函数。我想在一个中间项目,这将增长到20,在一个高级项目,它可能是数百。你是如何管理的?我预见如果每个开发人员都需要为其功能添加新的构造函数,那么这就是版本控制争用的来源。

我参与了react-redux项目,它有combining reducers的概念来解决这个问题。我没有在Elm遇到过这个概念。它有吗?

3 个答案:

答案 0 :(得分:6)

您可以定义msg类型由子/子msg类型组成,当然,updater可以与子功能组合。即

button{
  background-color:darkblue;
  color:white;
  padding:5px 10px;
  border:none;
  font-size:20px;
}

#stripe >*{
  vertical-align:top;/*or bottom, middle....*/
}

答案 1 :(得分:1)

看看Richard's implementation for RealWorld/Conduit。它提供了一种构建足够大的应用程序(几千行代码)的现实方法。

简而言之,在复杂的项目中,有一个Page可以拥有自己的模型,更新和查看的想法。

在每个页面中,您可以拥有一个大的Msg,但这不是一个真正的问题。 20个标签实际上非常易于管理。 NoRedInk程序员在其生产代码中发现50也是可管理的。

答案 2 :(得分:0)

这里有一个关于这个主题的体面教程:https://www.elm-tutorial.org/en-v01/02-elm-arch/07-composing-2.html

我希望它显示Widget的来源,但我可以想象它的样子。后续内联。

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
        }

我认为这与https://stackoverflow.com/a/44275318/61624背后的想法相同,但它有更多描述。