Actually, just to testify on nested components : got severely burnt by this pattern as I spent my Sunday refactoring my app before discovering that one nested component had to update the state of an other one, and realized I just did not want to go through the whole sibling or child whatever pattern (https://www.brianthicks.com/post/2016/06/27/candy-and-allowances-part-ii-child-child-communication-in-elm/) which seems way too complicated.
So I just refactored out my main file into Model, Msg, Update, View, and used helper functions, and now my mind is clear again. "Better flat than nested" might be a good idea after all... Le lundi 17 octobre 2016 21:38:14 UTC+2, Eric G a écrit : > > I'm no expert, and would like clarification on this as well, but "pages of > an app" seems like the main place where using nested modules makes sense -- > unless your pages can be modeled more easily as variants of each other, as > sometimes happens. > > My experience* has been that just about everywhere else it's easier to > have flat modules, using helper update functions, view functions with > generic msg types, config records, etc., and extracting common bits as > needed into separate modules. Sometimes I have nested msg types, and do the > Html.App.map / Cmd.map internally, within one module. Richard Feldman had > a list of "steps to take before breaking code out into separate modules" > awhile back that I thought was helpful. > > As for that article you linked to, it seems overkill, esp. for what is > mostly a static site. All of the static pages can just be functions in > Main, just split out the ones that have actual actions like the Contact > page, and then only if it seems unwieldy to handle those in Main too. > > Basically my advice is start with Main, or Main and one page module, and > see how far you get, rather than planning ahead what your file structure is > going to look like. > > (*My experience is limited to business-y company-internal applications, > someone else will have to say what works for games and other kinds of > applications.) > > > On Monday, October 17, 2016 at 2:41:23 PM UTC-4, Marcus Roberts wrote: >> >> Is this article (and the one it refers to) taking a good or bad approach >> to program structure? >> >> http://7sharpnine.com/2016/10/03/building-an-spa-with-elm/ >> <http://www.google.com/url?q=http%3A%2F%2F7sharpnine.com%2F2016%2F10%2F03%2Fbuilding-an-spa-with-elm%2F&sa=D&sntz=1&usg=AFQjCNE5Nbw5uyy5sAih-hs_cDS18y6OrA> >> >> I copied the structure as a way of seeing how a program might perhaps be >> broken down, but it feels like a very component based approach, given each >> level has its own update function. I learnt a fair bit about mapping >> between message types, so it was useful. >> >> I've broken my app down into pages using this structure, and so each page >> has a view, model, etc. Then the top level model has a model record for >> each page. This seems to work as it means the page doesn't need to know >> how it's being used at the level above. But the general conversations I >> see suggests this is not the right way to go and to break things down more >> into modules of related code. So I guess back to the original question, >> is this structure a good way to work? >> >> >> >> >> On Mon, Oct 17, 2016 at 7:50 AM, Peter Damoc <[email protected]> wrote: >> >>> update is a function that takes a message and a model and produces the >>> updated version of the model. In some cases, update also can produce some >>> requests for more input (http requests, requests for random numbers, ports >>> requests) this is why the top level update has (Model, Cmd Msg) as return. >>> Internal updates however, might not need these requests and can be >>> simpler. >>> What you see in the repository you linked is a pattern of nesting >>> "components" that is currently passively discouraged. (there use to be a >>> set of examples around this but they are gone). >>> >>> The official recommendation around scaling is to focus on breaking the >>> functionality into functions: >>> https://guide.elm-lang.org/reuse/ >>> >>> >>> >>> >>> On Mon, Oct 17, 2016 at 12:00 AM, clouddie <[email protected]> >>> wrote: >>> >>>> Hi, are there official guidelines for structuring large scale apps ? >>>> For instance, what is the community take on things like >>>> https://github.com/rogeriochaves/structured-elm-todomvc/tree/modular ? >>>> This is quite neat although I cannot quite m'y head round the fact the >>>> Update fonctions in TaskList deal with messages for Task ans TaskList, and >>>> they do not respect thé standard (Model, Cmd Msg) signatures ? >>>> >>>> -- >>>> 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. >>> >> >> -- 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.
