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 <lars.jac...@gmail.com > <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 elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
