Hi, thanks for your answer, I also got the impression that component 
approach was being discouraged as the notorious "dual counters" and "list 
of counters" relying on the component approach have been withdrawn from 
documentation as it seems...

To be fair I have already read the docs, but my model, messages and update 
functions are becoming waaaay too unwieldy (> 1,000 lines), and Evan's 
footnote is not that helpful (I understand he must be the busiest man on 
earth) :

Note: I plan to fill this section in with more examples of growing your 
> Model and update functions. It is roughly the same ideas though. If you 
> find yourself repeating yourself, maybe break things out. If a function 
> gets too big, make a helper function. If you see related things, maybe move 
> them to a module. But at the end of the day, it is not a huge deal if you 
> let things get big. Elm is great at finding problems and making refactors 
> easy, so it is not actually a huge deal if you have a bunch of entries in 
> your Model because it does not seem better to break them out in some way. 
> I will be writing more about this!


 

Le lundi 17 octobre 2016 08:50:23 UTC+2, Peter Damoc a écrit :
>
> 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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to