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
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
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?
> 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 <pda...@gmail.com
>> 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
>> 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:
>> On Mon, Oct 17, 2016 at 12:00 AM, clouddie <contact....@gmail.com
>>> 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
>>> 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
>> For more options, visit https://groups.google.com/d/optout.
You received this message because you are subscribed to the Google Groups "Elm
To unsubscribe from this group and stop receiving emails from it, send an email
For more options, visit https://groups.google.com/d/optout.