3

假设我有这样的嵌套 Elmish 组件：Acontains Bcontains C。

然后如果C有状态和消息，这些必须从 to 传递C到B然后 to A。

例如，消息和模型类型B可能是：

type Message = 
  | CMessage of C.Message
  | UpdateFoo of string

type Model = 
  {
    Foo : string
    C : C.Model
  }

然后updateforB会做一些路由：

let update message model = 
  match message with
  | CMessage m -> 
    {
      model with
        C = C.update m model.C 
    }
  | UpdateFoo foo -> { model with Foo = foo }

然后必须为A消费B消息做同样的事情。

setState例如，与 相比，这非常冗长。

在 Elmish 中管理此问题的一些策略是什么？

4

1 回答 1

1

如果您创建模型类型的层次结构，则需要通过该层次结构在update. 如果您不想通过 中的该层次结构路由消息update，则不要创建模型类型的层次结构。这意味着你有一个平面模型。

但是，我认为拥有平面模型是不可持续的。随着应用程序复杂性的增加，您需要通过将相关概念分组到包含它们自己的模型类型的（子）模块来管理这种复杂性。

setState例如，与 相比，这非常冗长。在 Elmish 中管理此问题的一些策略是什么？

该功能setState适用​​于图书馆作者。您的问题是关于特定模型和消息类型的，所以我的印象是您是 Elmish 的“最终用户”（而不是库作者）。因此，我认为将您的示例update函数与使用的某些替代函数进行比较是不公平的，setState因为您应该使用setState.

我认为你描述的这种冗长是严格控制突变的权衡。通过使用 Elmish，您是在说您想要严格控制突变（通过让几乎所有突变发生在 Elmish 而不是您的代码中），所以我认为这种冗长是必要的。

于 2019-09-20T16:08:27.243 回答