I get where you are coming from in saying that the update function becomes
essentially fifty smaller functions. Some of the questions on modularity
then stem from whether you ever expect someone to read through and consider
an entire Elm module or whether you expect that people will make changes to
pieces of code within a module and simply ignore the rest of it. The latter
is probably common no matter what. To me, it's a question of whether the
former should be viable or whether it's basically considered irrelevant as
a practice.
Mark
On Wednesday, August 10, 2016 at 10:33:48 PM UTC-7, Richard Feldman wrote:
>
> How big do the case statements in your update functions get? Or are your
>> pages just not that complex?
>>
>> I tend to like to keep modules in any language to a size that can be
>> reasonably read and comprehended. That doesn't always happen. I've written
>> some behemoths. But I tend to feel guilty when doing so.
>>
>
> They definitely get big, but one surprising thing I've learned is that a
> gigantic update function basically reads like a bunch of small, decoupled
> functions.
>
> For example, here are a few cases from one of our update functions at
> work:
>
> ToggleDescriptions ->
> ( { model | showDescriptions = not model.showDescriptions },
> Cmd.none )
>
> SetGradeFilterTooltipVisibility visibility ->
> ( { model | gradeFilterTooltipVisible = visibility }, Cmd.none
> )
>
> OpenQuestionTooltip questionId ->
> ( { model | tooltipShowing = Just questionId }, Cmd.none )
>
> CloseTooltips ->
> ( { model | tooltipShowing = Nothing,
> gradeFilterTooltipVisible = False }, Cmd.none )
>
> One way to look at this is that it's 12 lines of code inside an update
> function.
>
> Another way to look at it is that it's basically four one-liner functions,
> in terms of how decoupled they are and how easy it is to tell what they're
> doing.
>
> That's what it feels like maintaining these. If I want to know what
> CloseTooltips does, I go look up its implementation. As it happens, its
> implementation lives inside a long update function, but it wouldn't have
> been any easier or harder to look up if the implementation happened to be a
> one-liner function instead. Obviously pattern matches aren't as composable
> as functions, but that doesn't make it any harder to follow what they're
> doing.
>
> In practice a long update function feels like a lot of short, decoupled
> functions: really pleasant to maintain. :)
>
>
> I took these four examples from our longest update function. It's about
> 600 LoC, and its Msg is a union type with about 50 constructors.
>
> One way to look at that is "that function is way too big by the heuristics
> I'm used to!"
>
> Another way to look at it is "that will feel about the same as maintaining
> 50 small independent functions, each an average of 12 LoC in length. Sounds
> like it'd be really easy to tell what each of them is doing!"
>
> And so it is. :)
>
--
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.
