RealWorld example app architected with the Effect pattern

[dmy]

Despite being both able to instruct an upper layer to act on a state out of Msg scope, I think that the OutMsg pattern and the Extended Effect one as used in the example app have actually very few in common:

1. Effect is a global pattern, OutMsg is a local one.
   Consequently:

   1. Effects are implemented once, used any time.
      Whereas OutMsg must be deployed again each time it’s used and for each Msg scope level.
   2. Effects implementation can be changed without having to modify its users.

2. With Effect, an upper layer is independent from a lower one.
   This means that a parent page does not need to be modified when a new effect is used in a subpage. As I wrote earlier, I see the Effect module acting as an application runtime, and this runtime does not have to know where it is used exactly.

I think that these properties make the Extended Effect pattern scale well with the complexity of an application.

On the other hand, it does not work that well to tell something only to the parent page (intercepting and inspecting a subpage effect does not seem to be a good idea, and this is kind of an advantage for Cmd as it prevents it), so I don’t think it encourages nesting too much. For such cases, both patterns could be mixed by having the subpage returning an OutMsg in addition to its Effect, but I usually prefer other patterns for such cases.

@glasserc

Would you say that the main difference between the OutMsg pattern and the Effect pattern is that in OutMsg , we only define effects for sub-pages, but with Effect , we define them for the main update function as well?

I would not say that. When I started to use the Effect pattern, I actually used it only on pages and not in the Main, and the result is really not that different.

@glasserc

the main way to compose Elm applications is by recapitulating the Elm architecture at each level (each page gets its own model, view, and update). In this way, each “page” or “subapplication” or even “component” is being managed by the larger application in the same way that the application is itself being managed by the Elm runtime.

I’m not sure I would say it like this. Some pages in the RealWorld app do not need this, like Page.Blank or Page.NotFound, they are simple views. You can also find a lot of functions in View.elm that use the toMsg pattern to render complex views, those could be called “components” or “widgets”. On the other hand there is Article.Feed that uses its own Msg and an update function without being a page.

There are different kinds of programs in Browser, and there are a myriad of way to implement views or pages or widgets. This is something that elm-spa for example tries to formalize with its 4 kinds of pages. It would be interesting to have a version of elm-spa-example that uses it to compare the results.