Great post. Thanks for sharing all of these detailed thoughts. I make similar decisions with an MVU application, so it is thought provoking to see the choices made by others.
However I saw some opportunities for improvement. First it seemed like a mix of concerns to have update potentially creating a side effect function. Secondly it left update less testable than it could be. You can test the model easily, but it is quite invasive to test whether the correct side effects were requested. The ideal would be for Cmd to be just data representing the side effect and its necessary arguments.
I called the type Effect. [...] I call the function for this perform.
In basic examples, I call the type CmdMsg and the function bindCmd. In my large application at work, I found the short type names like Model, Msg, and CmdMsg confusing because the tooltips don't include the namespace/module containing that type. As such, I now include the domain terms in the type names. For example, one group of types could be named BlogPost (without the suffix Model), BlogPostMsg, and BlogPostCmdMsg.
[...] Msg, InitArgs, and Model all have the same basic tree structure, but with different types as leaf nodes. To avoid conflicts, I must name them slightly differently.
There is another way to avoid naming conflicts. Instead of
RequireQualifiedAccess is another good option I did not think about. Thanks for mentioning it.
I am still evaluating the last option which would eliminate the duplicate tree structures altogether.
The first time I thought of the Effect pattern was in 2018. We were starting a new project and moving away from Elm. I wanted to designate a place for side effects so init/update could remain pure. But I'm sure I was not the first with the idea. And I'm glad to not be the only one finding it useful.
Best wishes!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Great post. Thanks for sharing all of these detailed thoughts. I make similar decisions with an MVU application, so it is thought provoking to see the choices made by others.
I like your names.
In Elmish.WPF, we call this the Command Message (CmdMsg) pattern. I don't know where that idea originated. It was part of the project before I became a co-maintiner.
In basic examples, I call the type
CmdMsgand the functionbindCmd. In my large application at work, I found the short type names likeModel,Msg, andCmdMsgconfusing because the tooltips don't include the namespace/module containing that type. As such, I now include the domain terms in the type names. For example, one group of types could be namedBlogPost(without the suffixModel),BlogPostMsg, andBlogPostCmdMsg.There is another way to avoid naming conflicts. Instead of
you can do
Thanks for the great comment!
RequireQualifiedAccessis another good option I did not think about. Thanks for mentioning it.I am still evaluating the last option which would eliminate the duplicate tree structures altogether.
The first time I thought of the Effect pattern was in 2018. We were starting a new project and moving away from Elm. I wanted to designate a place for side effects so init/update could remain pure. But I'm sure I was not the first with the idea. And I'm glad to not be the only one finding it useful.
Best wishes!