与CMD结合

Question

我有一个函数

convertMsg : Msg1 -> List Msg2

，其中msg1和msg2是某些消息类型。我想将其转变为一个函数：

convertCmd : Cmd Msg1 -> Cmd Msg2

对于批处理中的每条消息，它将用一些消息替换为1个或超过1个。

作为Hastkell程序员的心脏，我立即达到了一个单调绑定（（）（＆gt（＆gt） ;＆gt; =）在haskell和中and 中的），具有类型的函数：

bind : (a -> Cmd b) -> Cmd a -> Cmd b

我可以轻松地将我的convertmsg更改为以下内容：

convertMsg : msg1 -> Cmd Msg2

在这一点上，它将非常适合绑定。

但是在 platform.cmd ，在那里，我无法找到这样的功能。有一个相似的地图，但是convertmsg不能真正是convertmsg：msg1-＆gt; MSG2，因为它并不总是会完全回馈一条消息。

有没有办法实现这一目标？ cmd类型是否会阻止这种事情？

Answer 1

你想对消息做什么，你会如何做，以及这是否是一个好的计划

我保证我会尽力回答我认为你想做的事情，但首先我认为有更重要的事情...

您可能假设 Cmd 类似于 Haskell 中的 IO，但 Cmd 是异步的，而不是旨在连锁行动。您的更新是将结果粘合到输出上的：

update : Msg -> Model -> (Model,Cmd Msg)

在更新结束时，您可以发出Cmd Msg来要求elm在外部执行某些操作，通常会传递一个构造函数来包装其输出。此输出返回到您的 update 函数。

您不做的是将Cmd链接在一起，就像在单子中一样。 Cmd 没有 bind，或者换句话说，Cmd 的唯一 bind 是您的 更新功能！

现在我想，如果您想捕获 MyComplexMsg : Msg 并将其转换为 [SimpleMsg1,SimpleMsg2]，您可以在 update< 中对其进行模式匹配/code> 函数，保持模型不变并发出新的 Cmd Msg，但是第二次运行什么命令？

你当然可以接受一个纯粹的 Msg ->;列出 Msg 函数并使用 Cmd.map 来应用它，或者在 update 开头的模式匹配中手动应用它，就像

update msg model = case msg of
    MyComplexMsg -> myHandler [SimpleMsg1,SimpleMsg2]
    ...

甚至进入完整状态monad 风格

update msg model0 = case msg of
    MyComplexMsg -> 
        let 
            (model1,cmd1) = update SimpleMsg1 model0
            (model2,cmd2) = update SimpleMsg2 model1
        in
            (model2,Cmd.batch [cmd1,cmd2])

尝试模拟 Monadic 绑定，但我不知道为什么你可能想要这个，并且 elm 文献和社区中的很多建议是，如果你从 update 调用 update 你可能会这样做错误的。为这些东西创建一个单独的单一用途辅助函数，而不是重新运行整个程序逻辑两次！

放弃对单子的需求

我怀疑问题在于你没有放弃单子控制流心态。 update 就是它所在的位置。 update 是您让事情发生的地方。用户输入和异步消息是您的驱动程序，而不是排序。 Cmd 仅用于外部通信。您无需将结果返回，elm 架构会为您完成此操作。只需将 Cmd 的结果（将以消息形式到达）作为 update 中的分支进行处理，一切都会顺利进行，并且如果用户按下某个按钮他们自己的选择，如果你不让他们发生，那就这样吧。你也可以处理这个问题。

我担心你试图在 elm 中编写一个 monad 转换器堆栈，这有点像试图在 haskell 中编写一个面向对象的编程库。 Haskell 不进行面向对象编程，人们越早放弃 OO 思维并放弃将数据和函数捆绑在一起的需求，他们就越早编写出好的 Haskell 代码。 Elm 不做类型类，它做模型/视图/更新，而且做得非常好。不再需要查找和使用 monad 来控制程序流程，而是响应所提供的消息。为您想要发生的事情创建一个 Msg，提供一种在您的 view 中适当触发它的方法，然后在您的 update 中处理它。

什么时候一条消息应该变成三条消息？

如果您的一条消息确实是三条消息，为什么它不是三条消息呢？如果只是为了响应该特定消息，您只需对模型执行三件事并发出五个命令，为什么不只使用一条消息并获取更新使用纯代码对模型执行这三件事并批量发出五个命令？

如果您需要记录成功登录，然后获取用户的照片，然后在数据库中查询他们最近的活动，然后显示所有内容，然后我不同意即时性，它们都是异步的。您可以发出命令来批量执行这些操作，当响应返回时，您将需要单独处理每个操作 - 在图像到达时使用图像更新您的模型，在图像到达时使用最近活动的列表更新您的模型。一旦您的模型处于图片和最近活动都在那里的状态，您就可以更改视图，但为什么不一出现就显示它们呢？

使用 monad 有时会训练我们在不需要的情况下进行效果编程时按顺序思考，但现在，最后，我将解决当迫切需要对命令进行排序时该怎么做。

真正必要的顺序命令

也许确实存在您需要的顺序命令。也许您必须在向其他地方发送某些请求之前查询某些数据存储。您仍然不使用绑定，只需使用更新：

update msg model = case msg of

    StartsMultiStageProcess userID -> 
        ({model|multiStageProcessStatus = RequestedData}
        , getDataPart1 userID PartOneReceived )

    PartOneReceived userData -> 
        ({model|multiStageProcessStatus = Fired}
        , fireRockets userData.nemesis.location RocketResult)

    RocketResult r -> if model.multiStageProcessStatus == Fire then 
      case r of
        Ok UtterlyDestroyed -> 
            ....
        Ok DamagedBeyondUse ->
            ....
        Err disappointment -> 
            ....
      ...

一个方便的点是，如果您的模型没有所需的数据，它会自动不会在视图中显示丢失的数据（获胜的总和类型），并且您可以在模型中存储多阶段过程所处的任何状态。

您可能更愿意将所有这些消息放入一个新类型中，以便它在处理程序中进一步缩进，并且永远不会与顺序中的其他消息混合，就像

    MSPmsg msg -> case msg of
        Started userId ->
            ... 
        GotPartOne userData ->

但更可能使用像 MSPmsg 这样的辅助函数消息->更新MultiStageProcess。

结论性建议

也许有一些很好的用例可以深入研究消息和命令并对其进行编辑，但您尚未明确说明，但是 Cmd 是不透明的，您所能做的就是发出它们并处理生成的消息，所以我对此表示怀疑，但绝对感兴趣。

另外，在为您提供要编写的 update 时，几乎就像他们为您提供了要编写的特定于应用程序的 bind （但它不是一个函子）而且你绝对确实查看数据），所以他们给了你特斯拉的钥匙。这需要一些时间来适应，但您真的会喜欢红绿灯处发生的事情。在您学会驾驶门铰链之前，请勿尝试拆卸门铰链。

编辑：您的具体用例：页面间通信

事实证明，在聊天中，您试图从一个页面获取消息以便在其他页面或整体更新中使用 - 有时一个页面需要告诉应用程序更改页面并告诉新页面开始动画。如果我一开始就知道的话，我可能会跳过上面的所有建议，但我认为这对于来自 Haskell 的任何人来说都是很好的建议，我将其保留下来！

多条消息

我仍然认为重要的是要接受有时一条消息需要涵盖多个操作，并且您可以在 update 函数中对其进行排序，而不是尝试创建多条消息来响应单个用户操作。

许多 elm 人给出的建议是，您的消息应该描述过去发生的事情，而不是像 AddProduct 那样描述要做的事情，部分原因是这就是消息在您的 更新中发送给您的方式 因此，您对 elm 运行时正在执行的操作的心理模型是准确的，部分原因是您不太可能想要发送两条消息，并在应该发送一条消息时进行奇怪的消息翻译。

在 update 的 ClickedViewOffers 分支中执行多项操作，而不是尝试同时创建 SwitchToOffersPage 和
AnimatePickOfTheDay 消息。

我想指出的是，您在消息类型中转换消息并以某种方式过滤它们的想法是在错误的位置进行的。无论如何，您必须在 update 中进行过滤，以便您的主页不会获取登录页面的所有消息 - 不要在创建或传递消息时尝试过滤它们。 update 是决定如何响应用户输入的地方。消息用于描述用户输入。

好的，但是如何让消息跨越页面之间的障碍呢？！

有几种方法可以实现这一点，并且可能值得研究在 Elm 中制作单页应用程序 (SPA) 的不同方法。我找到了 这篇文章 作者：Rogério Chaves 在 Medium 上发表的关于从子页面到父应用程序组织消息的各种方式的主题非常具有启发性。他在 此存储库中以不同的方式完成了 TodoMVC 应用程序 堆栈溢出帖子更好如果它内嵌想法，那么我们就开始：

1. 所有页面的通用消息类型

这可以通过为所有模块导入的消息类型创建一个单独的模块来实现。消息看起来像 ProductsMsg (UserCreatedNewProduct ProductRecord)，无论如何它们都可能这样做，但因为所有消息类型都是全局的，所以您可以调用另一个页面的方法。

2. 各个页面还会从其更新函数中返回 OutMsg

使用比这些更好的名称（例如 Login.Msg 而不是 LoginMsg），但是...

loginPageUpdate : LoginMsg -> LoginModel -> (LoginModel,Cmd LoginMsg,OutMsgFromLogin)

update : GlobalMsg -> GlobalModel -> (GlobalModel,Cmd GlobalMsg)
update msg model = case msg of
   LoginMsg loginMsg ->
        let (newLoginModel,cmd,outMsgFromLogin) = loginPageUpdate loginMsg model.loginModel 
        in
           ...

（您需要 NoOp :: OutMsgFromLogin 或使用 Maybe OutMsgFromLogin 。我不喜欢 NoOp。将它用于未实现的功能非常诱人，并且它是所有脱离用户意图的消息之王，它无法解释为什么您应该什么也不做，或者我认为您如何编写一些生成无目的消息的内容。这是一种代码味道，表明有更好的编写方式。）

3. 拥有一条消息记录，稍后您可以使用该记录将页面的 Msg 消息转换为全局消息消息。

（再次，使用更好的特定于域的名称，我试图在我的名称中传达用法。）

type LoginMessagesRecord globalMsg = 
   { internalLoginMsgTag : LoginMsg -> globalMsg 
   , loginSucceeded : User -> globalMsg
   , loginFailed : globalMsg
   , newUserSuccessfullyRegistered : User -> globalMsg
   }

并且在您的 main 中，您可以指定这些：

loginMessages : LoginMessagesRecord GlobalMsg
loginMessages = 
   { internalLoginMsgTag = LocalLoginMsg
   , loginSucceeded = LoginSucceeded
   , loginFailed = LoginFailed
   , newUserSuccessfullyRegistered = NewUserSuccessfullyRegistered
   }

您可以在登录代码中使用这些参数化函数它们都使用 LoginMessagesRecord 并生成 msg，或者您可以使用真正的本地消息类型并在登录模块中编写翻译助手：

type HereOrThere here there = Here here | There there
type LocalLoginMessage = EditedUserName String | EditedPassword String | ....
type MessageForElsewhere = LoggedIn User | DidNotLogIn | MadeNewAccount User
type alias LoginMsg = HereOrThere LocalLoginMessage MessageForElsewhere

loginMsgTranslator : LoginMessagesRecord msg -> LoginMsg -> msg
loginMsgTranslator 
   { internalLoginMsgTag
   , loginSucceeded 
   , loginFailed 
   , newUserSuccessfullyRegistered 
   }
   loginMsg = case loginMsg of
       Here msg -> internalLoginMsgTag msg
       There msg -> case msg of
            LoggedIn user -> loginSucceeded user
            DidNotLogIn -> loginFailed 
            MadeNewAccount user -> newUserSuccessfullyRegistered user

然后您可以使用 Html.map loginMsgTranslator在全局视图中使用loginView，或者如果您使用非常出色的无html和css方式编写elm应用程序，则使用Element.map loginMsgTranslator loginView，elm-ui。

总结/要点

• 用一条消息描述用户意图并使用更新来处理所有后果。
• 不要编辑消息，在更新中做出适当的响应
• 用户掌控一切。运行时间尽在掌控。你无法控制。不要自己生成消息，只需回复它们即可。如果您生成消息而不是用户或运行时，那么您正在以一种奇怪的方式使用 elm，这会很困难。
• 你的程序逻辑主要在于更新。它不驻留在消息中。不要试图在消息中让事情发生，只需在消息中描述用户做了什么或系统做了什么。
• 在消息类型中使用 case 语句和描述性标签来帮助选择要运行的更新帮助程序函数。使用联合类型来描述消息的本地化程度通常会有所帮助。有时您使用本地更新函数，有时使用全局更新函数。

您可能还想阅读此 Reddit 帖子，了解如何扩展 elm 应用罗杰里奥·查维斯 (Rogério Chaves) 提到的。