Idea: Address as API; one address per cross-cutting concern;

[rileylark]

In #2, @slorber said:

The counter should only expose an Increment(Int) action as public API.

I think this might be really helpful language for us, especially if we also include the address in our concept of "the API." In most languages it is acceptable to break up your api into modules according to the shape of your problem, but in the elm architecture examples we have to break up our api into modules according to the shape of our DOM. In redux we don't even get to use modules except by convention.

In this spec we only have the one cross-cutting business concern, but in real apps we have many many cross-cutting concerns:

• Tracking user actions for analytics & customer success
• Showing the state of general operations (e.g. the counter in this spec)
• Checking for new versions of the app
• Undo / redo (which btw does not come free in Elm, what an exaggerated claim!!)
• Caching & prefetching resources
• So many!
• And of course the current state of the UI. This is the only one that matches the shape of my DOM!

Extending the Elm Architecture Tutorial examples would have us divide these concerns into a single Tagged Union, but what if we just had an address + type for each one?

I think I can code up an example soon, but maybe not =/ Lemme know if I can clarify anything!

[slorber]

Hi,

We agree on the number of cross-cutting concerns that real apps do have.

I think using multiple adresses is fine and should work, but is only an implementation detail maybe?

I mean, weither you use a single adresse, and you discriminate events (for example you can have "local" or "global" events), or you use 2 adresses (one for local, one for global), or your use an adress for local, and one address per concern. I think all 3 are valid things to do to solve the problem, but maybe I didn't understand your point?

[tomsdev]

Hi @rileylark, I understand the benefit of separating local and global events but I don't understand how other "addresses" would work.

[tomkis]

@rileylark I definitely disagree with

but in the elm architecture examples we have to break up our api into modules according to the shape of our DOM

Just because it's done that way in examples, doesn't mean that you need to model your API according to DOM tree structure, the only condition is to model your API according your Component hierarchy. Keep in mind that Component does not need to have any View associated and can represent just some business behaviour (even side effects)

For example who said that you can't have top level Component for "Tracking user actions for analytics & customer success" ?

Component is orthogonal to View.

[rileylark]

@tomkis1 we found that Component is NOT orthogonal to View, because your view function can only send Actions of a certain type, and that type must also be matched in your update function.

For example who said that you can't have top level Component for "Tracking user actions for analytics & customer success" ?

Can you give an example of how a click event could both increment a counter and also track the action in a separate analytics component? We have found it to be very difficult, and generally require our update functions to be in the same shape as our DOM.

[tomkis]

Can you give an example of how a click event could both increment a counter and also track the action in a separate analytics component? We have found it to be very difficult, and generally require our update functions to be in the same shape as our DOM.

Not exactly the same, but just an idea

https://github.com/salsita/redux-elm-skeleton/blob/examples/src/custom-matcher/updater.js#L37-L42