Subscriptions (Elm 0.17)

[menelaos]

What are your thoughts on Elm 0.17-like subscriptions?

From what I can tell there are basically two advantages to signals:

1. The ability to unsubscribe from subscriptions. This seems especially useful for e.g. MouseMove events.
2. To encapsulate functionality, such as e.g. retrying AJAX requests.

It should also make the architecture simpler in some cases: Suppose there's a deeply nested component in your app that needs to know about window dimensions. With the current architecture you would need to feed Signal.DOM.windowDimensions to the inputs array at the top-level and manually pass that information down your component tree either via props or via actions.

With the subscription-based approach, it should be possible to have a deeply nested component declare that it wants to listen to window dimensions and let the framework take care of the rest.

-- Deeply nested component
data Action = ResizeEvent WindowDimensions

updateSub :: Action -> Model -> Sub Action
updateSub _ _ = Subscription.DOM.windowDimensions ResizeEvent

-- Intermediate components would simply map over the child components
data Action = ChildAction Child.Action

updateSub :: Action -> Model -> Sub Action
updateSub (ChildAction act) state =
  possiblyLocalSubscriptions <> map ChildAction (Child.updateSub act state.childState)

What do you think about this?

[megamaddu]

Some extra thoughts:

• Will this start to overlap with the purescript-elm effort or would Pux want to push a different architecture because purescript-elm is already aiming to fill that gap?
• Can subscriptions be based on something else that exists? (purescript-elm or purescript-observable + custom stuff, etc etc)

[alexmingoia]

In my experience, flattening the app architecture (a la Redux) is the simplest and ideal solution to all the problems with a deeply nested "elm architecture".

So I see subscriptions as solving for a problem that doesn't need to be there in the first place (nesting update functions N-deep).