That is quite true, taking only the parts the function needs via matching
out `{ parts, of, a, model }` is quite nice and extendable as needed. :-)
On Tuesday, August 23, 2016 at 3:30:46 PM UTC-6, Richard Feldman wrote:
>
>
>
> On Tuesday, August 23, 2016 at 11:43:49 AM UTC-7, OvermindDL1 wrote:
>>
>> On Tuesday, August 23, 2016 at 11:24:22 AM UTC-6, Richard Feldman wrote:
>>>
>>> You are on the road to #2, so my macro-level suggestion would be to go
>>> back to #1. :)
>>>
>>
>> #1 also ends up making utterly *huge* model and message unions though,
>> with extremely non-reusable parts. :-)
>>
>
> Regarding re-usable parts, I definitely recommend making things reusable
> on an as-needed basis. Splitting out a helper function takes about two
> seconds. ;)
>
> As for big models, they are easy to maintain in Elm. *I highly recommend
> big models!*
>
> At work we have 36,000 LoC of production Elm. One of our most complicated
> pages has a Model with 55 fields in it, and a Msg with 40 type
> constructors, and it feels *nice to maintain*. A year ago it was a bunch
> of nested React components and everyone dreaded touching it. Now we make
> changes to it all the time and it's no big deal.
>
> Having that big a Model and that big a Msg sounds like it ought to be
> painful, but in practice, it's actually great. We don't talk about
> splitting it up because there's no pain point. I understand the reflex to
> eagerly split things up, but as counterintuitive as it sounds, I think it's
> the exact opposite of what leads to a good experience in Elm. :)
>
> "If it ain't broke, don't fix it" is a good mantra here.
>
--
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.
