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 <[email protected] 
> <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 <[email protected] 
>> <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 [email protected] <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 [email protected] <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 [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to