对于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元素。