Alex, There used to be a documented way of decomposing apps into components by nesting the model, update and view of the components into the main model, update and view.
This lead to a lot of debates about inter-components communication and communication between children and parents. The approach ended up being abandoned and there is actually a line in de guide discouraging people from going that route. Personally, I believe that the warning from the guide is valid with one exception: pages. If you have a complex enough app, you should break it into pages and use the nesting architecture to put the pages together BUT avoid using the nesting architecture inside the pages, favoring an approach more similar to the one you can see in sortable table <https://github.com/evancz/elm-sortable-table>. I have tried adapting some of the old nesting examples to this new architecture (at least the way I understood it). You can take a look at example 4 https://github.com/pdamoc/elm-new-achitecture/tree/master/examples/4 You can also take a look at elm-taco, a more complex and full featured example of decomposition. https://github.com/ohanhi/elm-taco I'll end by saying that the main problem I see is not the fact that there is no approach but that there is a lot of freedom afforded by the language and you can split your code in so many ways. To my knowledge, there is no official, default way of structuring large scale, mainly Elm apps. On Wed, Mar 8, 2017 at 5:17 AM, Alex Rice <rice.gu...@gmail.com> wrote: > Hi all, I am new to Elm, and functional programming, and have been reading > through all the docs and tutorials. One question that keeps cropping up for > me is: > > How do you break up the Msg union type and the update function into > logical, manageable and editable pieces in a large Elm project? > > type Msg = > many | things > > and > > update : Msg -> Model -> ( Model, Cmd Msg ) = > case msg of all... those.. things > > So the pattern is, the Msg is a union type of many things, and the update > function is similarly lengthy case statement. > > How does that scale in real web apps? What if you have 100 messages, then > the update function is always 100 cases long? In the the scenario where you > are using Navigation.program, then shouldn't the update function only be > testing the cases which are in scope for the current route of the SPA, not > all 100 cases? In the Navigation.program examples I have seen, all the > cases are evaluated. > > I hope there is a way to decompose the messages and the update function > perhaps using some kind of pattern matching, or by some FP techniques, I > just have not seen it yet. Looking forward to hearing what you think! > > -- > 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. > -- 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.
