[elm-discuss] Re: Multiple "Middleware" pattern instead of single *.program
On Thursday, November 2, 2017 at 12:56:52 PM UTC+1, Martin Janiczek wrote: > 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.) > (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 :) -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[elm-discuss] Re: Multiple "Middleware" pattern instead of single *.program
On Thursday, November 2, 2017 at 10:30:10 AM UTC+1, Rupert Smith wrote: > > 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. > 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)*. -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[elm-discuss] Re: Multiple "Middleware" pattern instead of single *.program
On Thursday, November 2, 2017 at 12:09:55 AM UTC, Martin Janiczek wrote: > > >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 -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
