>
> Are you suggesting that each self-contained Elm "app" ("page", "game"
> etc.) should only have one Model/View/Update and avoid using nested modules
> for sub-components?
Yeah -
do you mean that something like the nested counter example from the Elm
> Archtecture guide is a bad idea?
It's not *necessarily* a bad idea, just not the first thing you should
reach for. Or the second thing you should reach for. Or the third thing you
should reach for.
The first three things you should reach for are, in no particular order:
1. Splitting view into smaller functions (without reorganizing Model or
update)
2. Splitting Model into smaller values (without reorganizing view or
update)
3. Splitting update into smaller functions (without reorganizing Model
or view)
Do one of these 3 things, one at a time, over and over, until either you're
thinking "I need to split out some of this to reuse it elsewhere" (in which
case you enter the realm of API design, and there is no one-size-fits-all
answer to what you should do next), or you find yourself thinking "even
after these small refactors, there is a big chunk of code that still feels
unwieldy, and it's self-contained enough that I could separate it out into
essentially its own little application, and have it communicate with the
rest of the application, and that communication overhead sounds like it
would be worth it."
As the guide says:
what happens when our code starts getting big? It would be crazy to just
> grow your Model and update functions endlessly. This is where Elm's
> module system comes in.
The nested counter is a demonstration of how to do this technique *once
your code base grows crazy enough to make it seem worthwhile*, but it's
super common to build something straightforward enough that it never needs
this kind of nesting at all!
I get where you are coming from in saying that the update function becomes
> essentially fifty smaller functions. Some of the questions on modularity
> then stem from whether you ever expect someone to read through and consider
> an entire Elm module or whether you expect that people will make changes to
> pieces of code within a module and simply ignore the rest of it. The latter
> is probably common no matter what. To me, it's a question of whether the
> former should be viable or whether it's basically considered irrelevant as
> a practice.
>
In my experience the latter hasn't been a problem, so it doesn't seem like
looking for a solution would be a good use of anyone's time. ;)
--
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.
