Passing whole state to each view function

[Tomaž Žlender]

Is it performance expensive if each view function gets a whole state as an argument? So instead of passing only a portion of a data that view function needs for rendering, each function gets whole state and inside that function another function is called first that transforms data in a format needed to generate view.

[Aaron VonderHaar]

There is no performance penalty to passing the entire model to all nested view functions.  Elm will simply pass the reference to the object around, so the performance of passing the entire model vs passing just the necessary parts should be equivalent.

However, the downside of doing passing the entire model everywhere is that you have to keep the entire model in your head when looking at any of your view functions.  In contrast, if you limit what data you pass to each function, then it limits the possibility of bugs and makes it easier to focus when you work on the smaller functions.  The smaller functions will also be potentially more reusable and it will be easier to set up initial data when testing.  This also makes it easier to extract modules later, since if all the functions take a Model, then any module you extract would also need to import Model and any other modules that data in the model depends on.

I also personally find that having the caller process the data (instead of having the called function transform the entire model into the data that it needs to render) usually leads to a nicer separation of responsibilities.

On Wed, Jun 21, 2017 at 10:03 AM, Tomaž Žlender <tomaz....@gmail.com> wrote:

Is it performance expensive if each view function gets a whole state as an argument? So instead of passing only a portion of a data that view function needs for rendering, each function gets whole state and inside that function another function is called first that transforms data in a format needed to generate view.

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

[Mark Hamburg]

Also note that while the approach of transforming your model into a more view-specific data structure — e.g., extracting the pieces of interest — can be a great pattern in terms of code clarity, it works against using Html.Lazy. For background on the pattern, see Charlie Koster's piece on selectors and view models: https://medium.com/@ckoster22/upgrade-your-elm-views-with-selectors-1d8c8308b336.

Concretely, structuring your code as:

toViewData : Model -> ViewData

displayViewData : ViewData -> Html Msg

and thence

view : Model -> Html Msg

view =

    toViewData >> displayViewData

works well — particularly if it allows for putting the view function into its own module where you might feel more free about doing lots of exposes for Html, Css, etc. However, it also means that the view function and any pieces thereof cannot effectively be lazy based on the ViewData it is passed because the ViewData instance will be new each time (even if it is actually equal to the previous value) and Html.Lazy does a naive (also known as fast) equality check based on instance identity.

If you know how Html.Lazy works, this issue is perhaps obvious in the code above, but as view functions get bigger to deal with more complicated views or moves to its own module, I've seen cases where developers think "this is an obvious place to put in some laziness" only to have it simply result in more work for the view system.

Why do we even care about laziness? Because it's the functional programming answer when engineers from other backgrounds say "You re-render the whole model on every change? Isn't that vastly less efficient than just updating the parts of the view that changed?" It's also part of how Elm gets the performance numbers that it gets on UI benchmarks.

So, great pattern. Use with caution.

Further notes below on laziness. Read if interested.

Mark

P.S. The way to get laziness in the above is:

view : Model -> Html Msg

view model =

    Html.Lazy.lazy doView model

doView : Model -> Html Msg

doView =

    toViewData >> displayViewData

We need to specifically define doView because every time we execute >> we get a new function instance which will then fail the laziness match.

The unfortunate thing here is that if the model contains pieces that don't directly affect the display — e.g., a queue of messages to send — then the laziness also depends on those pieces of the model. Part of the appeal of the ViewData intermediary is that it projects that stuff away.

P.P.S. Over-engineered solution (though it would also help subscriptions as well): The implementation strategy that makes Html.Lazy work could probably be extended to a general recompute pattern with laziness. The basic idea is that while evaluating the tree, you can look at the previous tree and see whether a lazy node has the same inputs as before and if so just use the answer from before. You need a small imperative piece that deals with the update from one tree to the next but that can live in the runtime. Something like this could immediately address the potential issue that calculating subscriptions after every update could be rather expensive depending on the size of the model and the number of subscriptions. For the discussion above, one would formalize the notion of view data — with identity being the simple implementation for converting the model to view data — and then do a "smart" re-computation of the view data as the first step in rendering the view.

One could probably even do this without changing the runtime model with just the addition of a native module akin to the Lazy module. Let's call that module Cache and give it an interface like the following:

eval : Cache a b -> (a -> b) -> a -> b

    -- (eval cache fn a) evaluates to an equivalent value as (fn a); it may use and/or update the supplied cache

eval2 : Cache2 a b c -> (a -> b -> c) -> a -> b -> c

    -- (eval cache fn a b) evaluates to an equivalent value to (fn a b); it may use and/or update the supplied cache

etc

Caches are mutable but opaque state and their specification should mean that the only visible effect from them should be reduced code execution.

Enhancements around deeper — but non-exception-throwing -- equality checks could also help drive things back to states that will match with the laziness match detectors.

If anyone writes this, let me know and I would be happy to start using it. :-) If I get there first, I'll say so though obviously this would not be available via the Elm package manager because of the need to access Elm's internal data structures.

 

[Max Goldstein]

To state Mark's point clearly: if your view depends on only a small number of the model's fields, then you are likely to rerender the view only when some other fields changed, which is unnecessary.

That said, you might not be at the point of needing laziness for performance. In particular, allocating and copying a new record has a cost of its own, and you'll have to measure to find if it's worth the lazy call to the function. Important: because of the virtual DOM, Html.lazy only saves you the overhead of calling the view function, both its logic and creating the virtual DOM. If the view function returns virtual DOM that matches the existing, real DOM, no DOM manipulation is performed, and that's the real performance win.

So, it is definitely simpler and easier, and possibly no less performant, to pass the model directly to the view. It would be nice if we could use the type system to limit which fields of the model the view can see, so we can isolate it better for understanding and testing. Fortunately there is a neat trick that does just that:

view : { r | foo : Int } -> Html Msg

view {foo} = ...

This function accepts any record which has a foo field of type Int. If your model has that field, it can be passed in, but no other fields in the model are available to the view function.

[Mark Hamburg]

Actually, Html.Lazy also saves the differ the task of comparing the subtrees when laziness saves us from work, so it can be a big win if UI updates are a significant chunk of the work.

That said, Max is correct that memory allocation for new structures is also a cost and is something to be avoided. (Functional programming loves to allocate memory...)

So, the basic rules of thumb are:

• If you have a big model pieces of which get rendered in various combinations by other code, try splitting those pieces out and using the record extension syntax to access just the fields needed while avoiding the cost of building a separate record.
• If you only need a little bit of information from the model for a subview, you can just extract it and call the subview function and avoid the record syntax overhead.
• If your model is structured in a way that makes it easy to keep valid but harder to draw, that's probably a good trade off — make impossible states impossible and all that — but may call for using an intermediate structure between the model and the actual view code. (See Charlie Koster's piece on "selectors".)
• Laziness can be a big win for both render and diff times with complex views BUT you need to be aware of how the lazy logic works and not hand it data that isn't likely to use the same data instances from render to render.
• Laziness can be good as one approaches the leaves and the data becomes more primitive.
• Laziness can be good near the top if there are large chunks of your model that won't be changing from cycle to cycle.
• Laziness gets a bit tricky in between these two because it can be useful to build intermediate structures while rendering and those break laziness.
• Experiment with the signature to your view functions. The basic idea of a view function is that it takes some data and returns some HTML. For example:
• Config records can handle views that need more set up (but you will likely want to move them out to module scope for performance if possible.
• If you have theme support in your UX, it may be useful to pass the theme down to all view functions that care as a separate parameter.
• Sometimes it is useful to have view functions return lists of HTML nodes rather than a single node.

Mark

--

[Max Goldstein]

Great points, Mark!

I came across this r/elm thread and they conclude that Html.lazy only skips a computation if the argument is referentially equivalent to some previous value. If true, this would invalidate the toView approach in Mark's first post on this thread.

I think this suggests having viewstate already split out in the model, i.e. a record or records. Then you pass each smaller record to a view function. But the idea of defining your model in a way to make your view functions more performant.... is not a pleasant one.

[Mark Hamburg]

Thanks for the term "referentially equivalent". It's a nice counterpart to "referentially transparent". (Long-time LISPers would know these as "EQ" v "EQUAL".)

Mark

--

[ajs]

> However, the downside of doing passing the entire model everywhere is that you have to keep the entire model in your head when looking at any of your view functions.

This is correct, but how can you avoid passing the whole model to all views if the data model isn't structured similarly to your view hierarchy? The idea of doing pre-processing on your data into a view-friendly structure seems to add overhead and complexity, while also more or less duplicating your view structure in two places: the view stack, and the view data.

We have found that as apps grow in size, it is unreasonable to couple a data model's internal structure to the requirements of a UI, and thus passing The whole model is the only valid option for most view functions. The exception are leaf nodes down the line that have few or no children, in which case they can receive focused inputs only.

[Mark Hamburg]

Per the other thread discussing this this morning, I don't know that passing the whole data model to all of the view-side functions is that horrendous. (We pass around a UXConfig structure in all of our views to provide access to translation functions amongst other things and the biggest pain is that I'm not certain that making it he first parameter by convention was the right choice.) Passing the whole data model feels icky, but you can document the dependencies using different modules to access different parts of the data model and you can still keep data model mutation out of the views by emulating the command mechanism.

That said, there are, definitely friction points where being able to subscribe to pieces of the data model would be a significant improvement. See my other message for some examples of these. But the friction is not in needing to pass the whole data model through the rendering process.

Mark

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

[Raoul Duke]

if passing the whole db, i wonder if i want something like structural types on the consuming apis to keep things more clear & safe & sane.

[Andrew Stoeckley]

Hi Mark, feel free to hit me up on Slack sometime to discuss further. My last two messages to this list have had more than one week delay in posting (ignore the timestamp, I'm posting this on Friday July 21), so that might be easier. 

I discussed these ideas quite a bit with @ilias and he made a rather interesting example of doing some things relating to state access: https://github.com/zwilias/elm-disco

I'm a firm believer that view functions should only receive data that they directly interact with, and nothing more. I've just found that to be a much better way to reason about interfaces.

You received this message because you are subscribed to a topic in the Google Groups "Elm Discuss" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/elm-discuss/F5pdcsls1Zc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to elm-discuss...@googlegroups.com.

[Simon]

Just bumping this to the top as it has the best discussion of html lazy that I know of in this mailing list and Evan's latest talk (React Rally) emphasised lazy there is such a way that I think I had better start using it better