Thanks for the extended feedback :) I will be back here once I have something big enough!
Regards, Witold Szczerba On Wed, Nov 16, 2016 at 10:13 AM, Wouter In t Velt <[email protected] > wrote: > Op dinsdag 15 november 2016 23:03:31 UTC+1 schreef Witold Szczerba: >> >> Thank you, Wouter for explanation. I was reading the documentation, but >> the chapter covers just the reusable views. View functions seems fine, >> using modules one can create, group, nest, etc. >> > > You are right that the example is mostly about views, but the principles > apply to other bits as well. > > >> I am wondering how making everything "flat" scales in a long term. >> > > In the SPA I developed, I started out with a simple structure with > Main.elm, Update.Elm, Msg.elm, Model.elm. > > At some point I needed a datepicker, and built one with Elm. I started of > with a DatePicker.elm module, which I put inside a separate Views folder. > The DatePicker also required some additional messages: HandleUpMonth, > HandleDownMonth, DateSelected Date. And somewhere in my update, these > messages need to be handled. And somewhere in my model, I needed to keep > track of the currentMonth, in view in the DatePicker. (so the DatePicker > view knows which month to display). > I started out by simply adding stuff to Msg.elm, Update.elm and Model.elm. > Putting the extra info in the model at the highest level on purpose. So my > structure remained flat, not nested. > > In the next round, I found out that actually processing the selected date > required quite a bit of code, to do the correct validations, update the > right record in my data structure, and close my DatePicker page. > > This was related to the data update, not to the DatePicker, so I created a > separate module for Exams, which handles the validation and updates for the > exam. > > At this point, my folder structure was something like this: > > src > |- Main.elm > |- Model.elm > |- Msg.elm > |- Update.elm > |- Updates (folder) > |- Exams.elm > |- View.elm > |- Views (folder) > |- DatePicker.elm > > > The nice thing about scaling in this way, is that the compiler has your > back: once you add messages in Msg.elm, the compiler will complain that you > need to change something in your Update.elm, because not all Msg are > handled there. So it is not a big deal that your DatePicker view function > and the related Msg are in different files. The compiler will protect their > consistency. > > In short, the way I scale is simply: > > - Only put different pages in different view modules (and import them > in the overall View.elm) > - Everything else: simply put it in Msg.elm, Update.elm, etc. And only > if one of these files becomes too big (300-400 lines is my threshold), take > out stuff and put it in a separate module. > > By now, my app is getting pretty big. But it remains very managable. > I use the DatePicker now in several different places, and the flat > structure still works for me. > > Hope this helps! > > -- > 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. > -- 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.
