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

2017-08-01 Thread 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. 
>

   . . . 
 

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

-- 
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] Best practices for designing models in the Elm Architecture - lean or rich?

2017-07-25 Thread Ray Toal
Great tip, thanks!

On Tuesday, July 25, 2017 at 12:50:20 AM UTC-7, Christian Charukiewicz 
wrote:
>
> 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.
>
> On Tuesday, July 25, 2017 at 2:11:22 AM UTC-5, Peter Damoc wrote:
>>
>> 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. 
>>
>>
>>
>>
>> On Tue, Jul 25, 2017 at 4:23 AM, 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...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> -- 
>> There is NO FATE, we are the creators.
>> blog: http://damoc.ro/
>>
>

-- 
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] Best practices for designing models in the Elm Architecture - lean or rich?

2017-07-25 Thread 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.

On Tuesday, July 25, 2017 at 2:11:22 AM UTC-5, Peter Damoc wrote:
>
> 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. 
>
>
>
>
> On Tue, Jul 25, 2017 at 4:23 AM, 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...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
> There is NO FATE, we are the creators.
> blog: http://damoc.ro/
>

-- 
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] Best practices for designing models in the Elm Architecture - lean or rich?

2017-07-25 Thread 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.




On Tue, Jul 25, 2017 at 4:23 AM, 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.
>



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

-- 
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] Best practices for designing models in the Elm Architecture - lean or rich?

2017-07-24 Thread 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).

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