Thanks for the explanation. I understand the choices made so far, but I still haven't been able to find good solutions for some simple problems:
1. I don't want to have every single possible message handled in the same place. It gets too big. 2. My global update function deals with everything in the app, including a message to update the value of the e-mail input field when the user is typing. This seems like a small concern that should be handled by the login page (or a component?). I don't want to clutter my model with temporary data. 3. On my User info page, my model is the same as other pages, so it has Maybe User. Since I have authorization, I *know* that there will always be a user when I go to the user info page. I want this to be reflected on the code, so I never have to check if there is a user. So far these issues are pointing me towards some sort of page separation, but I haven't been able to come up with something I like yet. On Wed, Mar 29, 2017 at 9:54 PM, Mark Hamburg <[email protected]> wrote: > The config approach pops up various places — e.g., elm-sortable-table — > but isn't as well specified anywhere that I've seen because it doesn't have > as clear a pattern to specify. > > Cmd.map (and Html,map) come out of what could be called Classic TEA. The > classic Elm architecture was built to allow decomposition by using tagged > messages to route through the compound model. For example, if you wanted to > have a number of pages, you could have a top level model that served as a > page switcher and it would use tagged messages to route to the current page > (or to discard messages if they weren't bound for the current page). This > worked well though I know programmers who grouse at the amount of message > routing boilerplate one has to write. > > But then people started trying to build React style component models with > this and had trouble. At which point, various people in the Elm community > decided that nesting was a bad idea and advocated strongly for flatness > with functions being the only decomposition mechanism and those without > much in the way of architectural guidance. Basically, this was a case of > the pendulum swinging wildly and the architecture for building complex > applications seemingly getting cast aside without a replacement. > > My advice would be to use the message routing patterns from classic TEA in > the places it makes sense to break ones app apart — just know that it isn't > particularly well suited to building components. > > For example, our codebase contains a module providing a model and > corresponding messages and update function for managing the sign up/sign in > process. It knows how to talk to our server. It knows what validation to > do. It understands the errors coming back from the server. It knows nothing > about how to display the data and instead provides a function to fill in a > ViewData structure that contains the information needed by the view code. > We can now reuse this logic in a variety of places where we need SUSI > logic. Each of those hosting cases then routes messages to and from the > logic using a message case of the form `ToLogic Logic.Msg` and using > `Cmd.map ToLogic` to promote logic layer messages to view layer messages. > > Mark > > On Wed, Mar 29, 2017 at 11:50 AM, Juan Ibiapina <[email protected]> > wrote: > >> Where can I find more information about that Config approach? I'm not >> able to find a way to organise multiple page applications that I like. >> >> On Wed, Mar 29, 2017 at 6:24 AM, Peter Damoc <[email protected]> wrote: >> >>> If you have a series of pages that each has Cmds and you have these >>> pages unified under one app, you need to lift each page Cmd to become an >>> app Cmd. >>> >>> There used to be a nesting architecture where this was demonstrated but >>> now that's been dropped in favor of the Config approach. >>> >>> >>> >>> On Wed, Mar 29, 2017 at 1:09 AM, Brian Marick <[email protected]> >>> wrote: >>> >>>> I’m having trouble thinking of a scenario in which you’d use `Cmd.map`. >>>> >>>> Is it for a case where you create a `Cmd a` where `a` is something >>>> different than the usual `Msg`, then transform it into a `Msg`? (When would >>>> you do such a thing?) >>>> >>>> Or for a case where you want to change the `Msg` constructor that `Cmd` >>>> “wraps”? (Ditto.) >>>> >>>> -- >>>> 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. >>>> >>> >>> >>> >>> -- >>> There is NO FATE, we are the creators. >>> blog: http://damoc.ro/ >>> >>> -- >>> 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. >>> >> >> >> >> -- >> Juan >> >> -- >> 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. >> > > -- > 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. > -- Juan -- 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.
