I authored a library that handles this problem pretty simply and the abstraction is definitely worth it as I am writing backend Elm and we have complex libraries that are 6 levels deep. You can check it out at: https://github.com/panosoft/elm-parent-child-update
On Friday, June 16, 2017 at 4:13:09 AM UTC-7, Rupert Smith wrote: > > On Friday, June 16, 2017 at 12:04:48 PM UTC+1, Rupert Smith wrote: >> >> As above, make my own ElmqMessage type and pull the routing logic out of >> the effects module. This would result in a message router that retains the >> dynamic routing capability, should anyone ever need such a thing. >> > > This would actually be better - one of the problems elmq has is that the > internal representations of Cmd and Sub in an effects module need to be > declared in it as a particular concrete type: > > https://github.com/rupertlssmith/elmq/blob/master/src/Elmq.elm#L2 > > As the consumer of the module cannot vary this type with type parameters, > it settles on passing everything as a Json.Encode.Value. This means that > the message router is not as strongly typed as it could be - the compiler > cannot make sure that when I pass a chat message of type String, the > receiver of that message is also expecting a String and not say an Int. > > Doing it all outside of an effects module with a type of 'ElmqMessage a' > would allow stronger guarantees to be enforced. > -- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
