Best practices for designing models in the Elm Architecture - lean or rich?

[Ray Toal]

This might be an opinion-based question so I can't ask it on StackOverflow. :-)

I have a trivial beginnerProgram using the Elm Architecture. It has two text fields (HTML input elements), one for weight and one for height. The onInput attributes of each generate a message. The update function accepts the message and produces the new model.

The question is: Should the model (a) consist of the width and height only, or (b) also include the computed BMI (width / height^2)? If the former, I compute the BMI in the view function; if the latter, I would compute it in the update function.

Does anyone have a lot of experience with Elm applications that would lead them to believe that keeping models as small as possible and computing derived data in the view function is better than making rich models? I don't have enough experience with Elm to know. I sense that for a problem as simple as mine it really doesn't matter (and I in fact got it working both ways), but as I start scaling up my apps it would be nice to know if there is best practice here (or not).

[Christian Charukiewicz]

You should not keep derived values in the model.  The model should be a single source of truth.  This property is violated if you store derived data in the model.  What happens if you create a new input that fires a different Msg that only updates the height, but does not recompute and update the BMI?  Should you now be reading from the weight and height fields?  Or should you be reading from the BMI?  Or what happens if you add a reset Msg?  If you store this derived BMI calculation in your model, you have 3 fields to worry about rather than 2.

[Peter Damoc]

Keep derived data in the model if it makes sense to keep derived data in the model. 

If you have an expensive function that runs and computes a derived value and you would have to call frequently this function in your view, then by all means, computer the derived value in update and save it in the model. 

If you don't run into a performance problem like the above, keep your model clean and just extract the computation in a function. for example, you could have something like 

bmiText : Model -> Html msg 
bmiText {weight, height} = 
    weight / height ^ 2 |> toString |> text 

this way, everywhere you need that textual representation, you can use it. 

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

--

There is NO FATE, we are the creators.
blog: http://damoc.ro/

[Christian Charukiewicz]

In your expensive function example, you should be able to take advantage of Html.Lazy to prevent the view from re-running the expensive function unless its parameters change.  By storing the derived data in the model rather than letting Elm handling the caching through the Lazy functions, you are effectively doing something similar but at the cost of adding a lot of complexity to your application.

To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Kasey Speakman]

I don't think it matters one way or another. Whatever you end up finding easier to maintain.

What I would do is explicitly represent the BMI as its own module, probably with an accompanying data type. In the module operations like `updateHeight` and `updateWeight`, you could make sure that the calculation is getting rerun. Update would call the module instead of directly setting individual properties. Then you have this logic encapsulated and centralized.

On Monday, July 24, 2017 at 8:23:44 PM UTC-5, Ray Toal wrote:

[Ray Toal]

Great tip, thanks!

[Mark Hamburg]

Agreed that encapsulation is the way to isolate the engineering trade offs because that's what this really is about. Ideally, one would never store values more than once and derived data would always get re-derived. But that ideal world ignores the cost of computations. Sometimes the cost of computation is going to be really noticeable if you keep doing it.

So, a simple pattern here as Kasey points out is to put the input values into a type and then provide an evaluation function for the type to get the derived value. Maybe the evaluation function just does the computation. This is great if the computation is cheap. Maybe the evaluation is done every time the inputs are updated. This is great if we read more than we write. Maybe writing to the inputs creates a new lazy function that gets forced when read. This is good if we may have bursts of writes without an intervening read.

Something like JaneStreet's Incremental library for ML would be cool for more complex situations but it almost certainly uses mutability in its implementation. (Incremental feels a lot like many other FRP systems though it is focused on more of a spreadsheet model  of computation than on an event flow model.)

And as noted lazy views can help, but only to the extent that the structure of the data and the structure of the views aligns well. In my case, they don't. I have a custom layout of a scrolling grid of cells of varying dimensions. The layout depends on the cell list and the width of the view. The cells I actually want to instantiate in the view function depend on the layout and the currently visible range in the scroll. While the cell list and the width change relatively rarely, the visible range can change frequently. Since the view function needs to depend on the scroll range, laziness there can't be the way to avoid running the layout computation. So, I have explicit dependence logic to update it. What this thread points out to me is that I should wrap up those dependencies and just those dependencies in a type to better document the logic.

Mark

[John Bortins]

Ha! I just stumbled onto this recently to solve an ugly performance issue and it works great.

The cost is a layer of complexity added to the update function. In this way, the intermediate calculations need be done just once per update rather than spread out many times over the view. Well worth the effort to keep users oblivious to the difficulties and happy with the results. 

Perhaps there is a way to store such dependent state separately? Until then I shall keep this technique close to hand.

On Tuesday, July 25, 2017 at 3:11:22 AM UTC-4, Peter Damoc wrote:

Keep derived data in the model if it makes sense to keep derived data in the model. 

   . . . 

[Erkal Selman]

This is a nice question I kept asking myself. 

I came to the conclusion that it is best to keep your model and your update function as simple as possible.

In the model, there shouldn't be more than one representation of the same datum.

The calculations should be made inside the view function, unless you encounter performance issues.

Here are two reasons:

- This way, I understand the program better. When I look at an elm-program, I first look at the model. So the model should be comprehensible. If you have two different representations of the same datum, I think you should write a comment and make that clear that it is for performance reasons. Performance should be the only reason for breaking this rule. As long as you don't encounter performance problems, keep the model simple, even if this makes you calculate things more than once. 

- It also prevents bugs because if you have two fields holding different representations of the same thing, every time you update one field you also should update the other. Sometimes, you forget that and then you lose your time to find out where you made the mistake.