Hi I wrote that article as a general overview of how I structured a single 
page app after reviewing different approaches, and relying on some of my 
knowledge of what worked for me in F# too.  Having the code structured in 
functions residing in modules made it really easy to update a specific part 
of the app, and also to refactor parts that needed it.  The hardest part 
was actually getting webpack to work with bootstrap4!


On Monday, October 17, 2016 at 7:41:23 PM UTC+1, 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/
>
> 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