gpt4 book ai didi

elm - Elm 中组件之间的通信

转载 作者:行者123 更新时间:2023-12-04 18:34:01 25 4
gpt4 key购买 nike

假设我正在尝试遵循 Elm 架构并将我的工作流程拆分为 User s 和 Invoice s 使用 StartApp .

用户有发票,但他们必须登录才能访问它们。

该模型可能看起来像这样:

type Model
= NotLoggedIn Credentials
| LoggedIn RealName (Maybe Invoices)

type alias State =
{ login : Model
, notification : ......
, ......


type alias Invoices = { invoices: List Invoice, ...... }

用户模块有 Action :

type Action
= Login (Result Http.Error String)
| Logout
| Submit
...

和更新功能:

update : Action -> Model -> (Model, Effects Action, Notification)
update action user =
case (action, user) of
(Login res, _) ->
case res of
Ok name ->
(LoggedIn name Nothing, Effects.none, Info "Welcome!")
...

我跳过了身份验证的细节,一切都很好。有趣的部分是 Login行动。元组被发送到 step main中的函数:

step : Action -> State -> (State, Effects Action)
step action state =
case action of
UserAction a ->
let (newstate, ef, n) = User.update a state.login
in ({ state | login = newstate, notification = n }, Effects.map UserAction ef)
InvoiceAction a -> ......

所以用户已经登录了。接下来我们要调用一些 init Invoice 中的操作模块。

但是这应该如何正确地完成呢?如何发起 Invoice 的操作保持封装?我可以返回 Effects.none 以外的其他内容吗? ?

最佳答案

这可能是可以通过对应用程序数据进行不同建模来解决的情况。

我理解它的方式,您有需要作为用户的操作和不需要用户的操作。 InvoiceAction 向我表明它应该属于 UserAction。

所以,你可以有

type MainAction = UserAction UAction | NonUserAction NonUAction 

type UAction = AuthAction Credentials | InvoiceAction Invoice.Action

用户模型将封装登录详细信息和发票详细信息。然后,在成功登录后,您可以重定向到 InvoiceAction。
update action model =
case action of
AuthAction credentials ->
let
(isLoggedIn, notifications) = Authentication.check credentials
model' = { model | credentials = credentials, notifications = notifications}
in
if isLoggedIn
then update (Invoice.initialize model'.credentials) model'
else (model', Effects.none)

InvoiceAction act ->
let
(invoices, fx) = Invoice.update model.credentials act model.invoices
in
({model | invoices = invoices}, Effects.map InvoiceAction fx)

实际操作由 Invoice 模块通过函数 initialize 提供。带有 initialize: Credentials -> Action 之类的签名.这样做是为了保持封装。 User 模块不需要知道特定的 Invoice Action ,只知道有一个与初始化相关,它可以通过该函数获取它。

另外,请注意我已经简化了更新签名并将通知移动到模型中。这是个人偏好,因为我认为通知没什么特别的。它们就像模型中的任何其他数据一样。当然,如果通知是通过一些自定义 StartApp 路由到端口并通过一些 JS 机制显示的任务,则将它们保留在返回中可能是有意义的。

关于elm - Elm 中组件之间的通信,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/36316766/

25 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com