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 <kjspeak...@gmail.com> 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.
