The. Config parameter to generate messages is much like the out message approach in that essentially the child is listing off things that it either can't handle itself or that it doesn't actually care about but wants to let the parent know about. For example, a sign in module when finished may just want to say "We're signed in now!" or for that matter "The user canceled." Config basically is a way to say "I may need to send these messages to you, please tell me how to send them." Out messages list the things that will be returned and presumably the parent code will case over them.
As for which to choose, it probably comes down to a question of which approach does a better job of having manageable boiler plate. The out message approach does make me feel like I'm writing the same code over and over again, but it does follow a well defined pattern so it's not like I'm having to think hard while getting the structure in place. I assume that the config approach involves similar but different "boiler plate" in that each child response needs its own parent message and implementation in the update function. Another option for something like the sign in case is that the parent just queries the child after every update. "Are we signed in yet?" For some cases, this works well but it also means that children may need to store more state. For example, it's a lot easier to send a "close me" message to the parent in response to the close box being hit than it is to store a Boolean "I'm closed flag" and have the parent query it's status to discover that the modal child should be closed. All that said, I think elmq is really interesting for the case where the interaction isn't hierarchical. For example, model hierarchy might reflect the presentation which might be relatively different from the model needed to talk to the server. It's a pity it can't be typed. Lacking type support, it's interesting to think about it as being analogous to talking to a web server in the encode/decode process. Following that line of reasoning, however, leads to wanting a way to send a message and get a response delivered only to the sender rather than broadcast to every part of the app talking to that internal server. Mark P.S. To avoid triples in return values from update functions and corresponding complexity in support libraries, I folded commands into out messages. Conceptually, they are the same thing — requests for an effect beyond the bounds of the model being updated. This does, however, mean that every update has to include command forwarding logic as part of its out message processing. > On Jun 16, 2017, at 8:47 AM, Charles Scalfani <cscalf...@gmail.com> wrote: > > 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 elm-discuss+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- 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.
