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.
I am wondering how making everything "flat" scales in a long term. Having
everything in just 4 files (Model/Mgs/Update/View) would eventually lead to
huge, separated silos with all the "business domains" mixed, wouldn't it?
What wrong happens when the application gets divided by features (in
opposite to features being divided by those 4 files)?
Maybe when app gets bigger, some kind of hybrid approach would emerge?
Thanks,
Witold Szczerba
On Mon, Nov 14, 2016 at 10:58 AM, Wouter In t Velt <wouter.intv...@gmail.com
> wrote:
> Op maandag 14 november 2016 02:24:16 UTC+1 schreef Witold Szczerba:
>>
>> Can you provide some real-life example of "moving away from components"?
>> That could be helpful…
>>
>
> Sure. My background is in React, where everything there is components too.
> No examples of my own to share just yet. My app is very much "work in
> progress", and not yet clean enough to share I am afraid.
>
> In the first version of my app (to plan homework), I would have e.g. an
> EditExam.elm file that contained its own Model, init, update, Msg and view.
> And in my main.elm, I would import this module and integrate each of these
> into the main Model, init etc.
> So basically, EditExam.elm was a "component". With the purpose of
> displaying an Exam, and allowing user to edit details.
>
> When moving away from components, I created top-level files in my root
> directory:
>
> - Model.elm
> - Msg.elm
> - Update.elm
> - View.elm
> - Main.elm (which imports all of the above).
>
> I copied the code bits from the component into each of these files. So for
> example:
> type alias Model =
> { ...
> , exams : List Exam
> , currentExam : Exam
> }
>
> type alias Exam =
> { subject : String
> , ...
> }
>
> So the Exam type is the Model from the old EditExam.elm file.
> Did the same for init, Msg, update, and view.
>
> A (larger) real-life example that I use as a reference is the time-tracker
> SPA (here on github <https://github.com/knewter/time-tracker>). Which is
> a project as part of a DailyDrip <http://dailydrip.com/> series.
>
> A very good explanation (with simple examples) of non-component scaling in
> Elm is in the Official Guide here <https://guide.elm-lang.org/reuse/>.
> That explanation helped me a lot, along with the video's on sortable table
> linked there.
>
> 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.
>
--
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.
