[elm-discuss] Multiple "Middleware" pattern instead of single *.program

[Martin Janiczek]

Hello elm-discuss!

I've been thinking about the **.program* pattern. Currently one has to
choose one of the many different *.program functions
<http://klaftertief.github.io/elm-search/?q=program> and implement the rest
of the functionality themselves, ie. they can't mix and match, say,
*Navigation.program* and *TimeTravel.Html.program*.

A way to solve that would be to specify a list of "middlewares" that each
do a specific task, and have a "clean" program they all augment:

main =
combineMiddleware
Navigation.middleware
TimeTravel.middleware
DropboxAuth.middleware
App.program

I have tried to implement such a pattern and want to share it and ask for
opinions. *This could, after all, be a very bad idea!*

----

Some links:

- GitHub <https://github.com/Janiczek/middleware> (I didn't want to
publish that as a package just yet, but if it helps somebody, tell me and I
can do that)
- Tour of the code:
- The *main* function
<https://github.com/Janiczek/middleware/blob/master/src/Main.elm>
- The *program* (business logic)
<https://github.com/Janiczek/middleware/blob/master/src/ExampleProgram.elm>
(a counter)
- A *middleware* "talking" to the program
<https://github.com/Janiczek/middleware/blob/master/src/Middleware/ResetByMsg.elm> (returns
it from update)
- A *middleware* logging "all the Msgs under it"
<https://github.com/Janiczek/middleware/blob/master/src/Middleware/History.elm> (this
+ the Reset middleware could, with a bit of effort, become a Debugger
middleware)
- A *middleware* using its own Subs
<https://github.com/Janiczek/middleware/blob/master/src/Middleware/SubsTest.elm> (the
middlewares can use Subs, Cmds, have their own model)

----

This allows people to combine multiple behaviours instead of being limited
to just one.

*Questions I'm pondering are:*


1. Is this a good idea at all?
2. Comparison to the "fractal TEA" that we generally shun now. (Hiding
of behaviour; in fractal TEA one sees the extra functionality in the model,
here it's almost invisible; does one need to see it? This approach avoids
some boilerplate -- the only thing end user needs to supply is a Msg
constructor, similar to *.program)
3. Does this encourage some bad practices, code smell, OOP in a FP
language, componentization? Good/bad? (If bad, is the *.program pattern we
currently somehow embrace OK then? I'd say it does things /hides behaviour/
basically the same way.)

----

And, for the interested, some implementation details:

- Each middleware knows about the next model in the chain (they're
nested), but can't inspect it. (If it used concrete type instead of a type
variable, it would limit what other middlewares/programs can be next to it.)
- The Msgs are also nested: each middleware has to have one Msg for
wrapping the Msgs of the next middleware/program in the chain.
- All middlewares can send messages *to the program* (but not to each
other):
- the program exposes a record with Msg constructors it offers
alongside update, init, etc.
- each middleware declares what Msg constructors it needs (through an
extensible record) -- very similar to how Navigation.program needs a
Msg constructor for the location changes
<http://package.elm-lang.org/packages/elm-lang/navigation/2.1.0/Navigation#program>
.
- the compiler makes sure all middleware Msg needs are satisfied
- middleware's update gets the record with the constructors as an
argument, and returns a Maybe Program.Msg
- the Msg gets threaded through the Elm Runtime as any other, and the
user gets a nice clean Msg in their update.

And some API:

middleware :
{ init : (innerModel, Cmd innerMsg) -> (ownModel, Cmd ownMsg)
, update : ownMsg -> ownModel -> programMsgs -> (ownModel, Cmd ownMsg,
Maybe programMsg)
, subscriptions : ownModel -> Sub ownMsg
, view : ownModel -> innerHtml as Html ownMsg -> Html ownMsg
, wrapMsg : innerMsg -> ownMsg
, unwrapMsg : ownMsg -> Maybe innerMsg
}

where

ownModel = { ownFields | innerModel : innerModel }

program :
{ init : (model, Cmd msg)
, update : msg -> model -> (model, Cmd msg)
, subscriptions : model -> Sub msg
, view : model -> Html msg
, programMsgs : programMsgs
}

where

programMsgs = (eg.) { locationChanged : Location -> Msg }

['Rupert Smith' via Elm Discuss]

Post by Martin Janiczek
1. Is this a good idea at all?
Having stacked a few programs together by hand, this strikes me as an

excellent idea and one that is worth exploring.

One problem I had was with TimeTravel.program which I was wrapping a
RouteUrl.navigationApp with. All the messages were then nested at the
time-travel level, and its UI did not support nested filtering, so I could
not easily filter out animation messages. It occurs to me that if each
middleware knows about the next layer, and has wrap/unwrap functions for
it, that it would be possible to have set up the time-travel layer to
unwrap the nested messages, if I had such a system as yours.

Would love to see what a navigation example looks like.

Rupert

[Martin Janiczek]

Post by 'Rupert Smith' via Elm Discuss
One problem I had was with TimeTravel.program which I was wrapping a
RouteUrl.navigationApp with. All the messages were then nested at the
time-travel level, and its UI did not support nested filtering, so I could
not easily filter out animation messages. It occurs to me that if each
middleware knows about the next layer, and has wrap/unwrap functions for
it, that it would be possible to have set up the time-travel layer to
unwrap the nested messages, if I had such a system as yours.

Right now that seems problematic: the composing functions can't inspect the
types in runtime (to decide how much to unwrap), and the amount of wrapping
the time-travel middleware will see depends on where you'll put it in the
chain. It would make sense to put it right next to the user program - no
middle layers to unwrap then.

Post by 'Rupert Smith' via Elm Discuss
Would love to see what a navigation example looks like.

I have added a Navigation middleware example, see the updated demo:
https://janiczek.github.io/middleware/index.html
(Because *elm-lang/navigation* doesn't expose the *Location -> msg -> Sub
msg*, I've had to copy it to the user-space code to be able to connect the
subscription to the middleware.)

This brought a minor change to the API: middleware's *subscriptions* now
take the *programMsgs* record and return *(Sub msg, Sub programMsg)*.

[Martin Janiczek]

Post by Martin Janiczek
https://janiczek.github.io/middleware/index.html
(Because *elm-lang/navigation* doesn't expose the *Location -> msg -> Sub
msg*, I've had to copy it to the user-space code to be able to connect
the subscription to the middleware.)

(Of course I meant *(Location -> msg) -> Sub msg*.)

It seems to me that the Navigation example doesn't gain much from being
written in middleware pattern. It's *better than the *.program approach* in
that it can compose, but it's *worse than Sub approach* in that user
doesn't see where the Location msg came from. (In my opinion, it's better
to be explicit.)
The time-travel middleware does, I think, still have its value in being in
the middleware pattern: it's more "invasive" change, *view* and all, and
wouldn't be suited by simple Cmd/Sub.

I assume the reason Navigation has opted for the *.program approach, is the
custom *init* function. This (init) is one thing I haven't yet thought
about much for the middleware, and is probably subject to change. There
probably exists some nice middleware example that would make the API more
clear. Food for thought :)