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