Thanks for a very informative answer! I think this is a very important part of making an elm application work when it grows. I'm pretty sure that we should be very careful before breaking stuff "prematurely". I started writing an app breaking it up like i used to break up my react/redux -apps, i.e something like app.elm -> itemlist.elm -> item.elm. It's a nightmare where you end up having to handle multiple levels of sub-messages and stuff. Breaking stuff up organically and trying to keep the types and update together as long as possible is the key and makes a BIG difference in how much fun the app is to maintain. I also believe we should not have multiple "pages" in the same elm app. If you have two "views" (like eg. "itemlist" and "itemdetail") - thats two separate elm apps!
On Tuesday, September 20, 2016 at 5:03:23 PM UTC+2, Peter Damoc wrote: > > On Tue, Sep 20, 2016 at 5:18 PM, Lars Jacobsson <[email protected] > <javascript:>> wrote: > >> Peter - just out of curiosity: How did you split those 8000 LOC up? Did >> you go for a structured component/react type splitup, or did you split >> "organically" when the need occurred? >> > > It was more of an organic kind of split, mostly around functionality. > > With the exception of some static pages that were handled directly by the > MainApp.elm, all the other pages had their own separate file. > Most of them were following TEA but some ended up not needing their own > model and update because they could delegate their actions to the top > level. > Functionality around routing was in its own file, same for the server > access API. > Business Objects Types were in their own file that was imported all over > the place > Serialization (encoders and decoders) was in its own file. > There was a Components.elm that was mainly various aggregates of elm-html > (simple functions). > There were also a few components (Dropbox, Carousel) that lived in their > own .elm files. > Some complex forms got also extracted at one point into their own files. > There were also some CSS only files. > One of them, SharedCSS.elm taught me a very important lesson: > Don't put code that changes frequently in a file that is imported by a lot > of other files. > changes to this file led to the longest compilation times. :) > > > > > > -- > 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]. For more options, visit https://groups.google.com/d/optout.
