对于http request 函数，the Elm tutorial和the docs都建议将构造函数（例如GotText）传递给期望函数（例如{{1 }}），用于expectString字段，例如：
expect我理解这一点，但是在我看来，约束API以要求构造函数（例如type Msg
= GotText (Result Http.Error String)
getPublicOpinion : Cmd Msg
getPublicOpinion =
Http.get
{ url = "https://elm-lang.org/assets/public-opinion.txt"
, expect = Http.expectString GotText
}
）过于严格。
例如，可以使用GotText从请求函数identity中提取构造函数GotText：
get但这引出了一个问题：为什么HTTP API完全需要构造函数*？
*或至少允许我们忽略getPublicOpinion = Cmd.map GotText (
Http.get
{ url = "https://elm-lang.org/assets/public-opinion.txt"
, expect = Http.expectString identity
})
字段并返回expect。
答案 0 :(得分：1)
这不是限制，实际上是方便。
如果Http.expectString没有采取功能(Result Http.Error String -> msg)，然后按Http.get会返回一个Cmd (Result Http.Error String)这是如果你通过它做什么identity。< / p>
由于所有Cmd的结果必须始终是Msg，运行时才能传递给您的update函数，因此始终必须Cmd.map将结果每次调用Http.get的次数，将Cmd (Result Http.Error String)转换为Cmd Msg。
要避免必须呼叫Cmd.map每次调用时间Http.get该API允许你传递，将做转换直到函数Http.expectString。这种类型的输入更少，嵌套更少，因此对读者来说更清楚。
您将在许多模块中看到这种约定。例如：
Json.Encode.list的类型为list : (a -> Value) -> List a -> Value它需要一个函数来做到的列表的元素的编码JSON，这样可以节省您不必使用List.map，以JSON编码列表中的元素。
Html.Events.onInput的类型为onInput : (String -> msg) -> Attribute msg，它需要一个函数来将String转换为msg的值，这使您不必再使用{{1} } Html.Attribute.map的结果，将onInput转换为Attribute String。这将是一个真正的痛苦，如果你不得不调用Attribute msg每一个事件处理程序和Html.Attribute.map上的任何HTML元素。