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 <pda...@gmail.com 
> <javascript:>> 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 <contact....@gmail.com 
>> <javascript:>> 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 elm-discuss...@googlegroups.com <javascript:>.
>>> 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 elm-discuss...@googlegroups.com <javascript:>.
>> 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.

Reply via email to