[elm-discuss] Re: Best practices for designing models in the Elm Architecture - lean or rich?

[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.

On Tuesday, July 25, 2017 at 3:23:44 AM UTC+2, Ray Toal wrote:
>
> 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).
>
>

-- 
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.

Re: [elm-discuss] Re: Best practices for designing models in the Elm Architecture - lean or rich?

[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

On Tue, Jul 25, 2017 at 7:29 AM Kasey Speakman  wrote:

> 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:
>
>> 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).
>>
>> --
> 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.

[elm-discuss] Re: Best practices for designing models in the Elm Architecture - lean or rich?

[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:
>
> 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).
>
>

-- 
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.

[elm-discuss] Re: Best practices for designing models in the Elm Architecture - lean or rich?

[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.

On Monday, July 24, 2017 at 8:23:44 PM UTC-5, Ray Toal wrote:
>
> 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).
>
>

-- 
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.