Ok. So in short, your point being: If your template depends on it, have it assigned even if you don’t see any reason for it (e.g. being only a transformation of other data that is already assigned), in order not to worry of whatever discrepancy / side effects that may pop up in the future.
DaAnalyst
benwilson512
Author of Craft GraphQL APIs in Elixir with Absinthe
The absence of code examples has me a little bit lost here. Let’s make this slightly more concrete. You have @foo, and there is some transform(@foo) that produces a bunch of data you actually want to render, but transform/1 is somewhat expensive yes? So you want to make sure that it only actually gets called if @foo changes, and not simply because some other value @bar changes?
Eg:
# index.html.leex
<html>
<body>
<p><%= @bar %></p>
<p><%= transform(@foo) %></p>
</body>
</html>
If @bar changes a lot, but @foo changes very rarely, you don’t want to re-run transform/1 every time @bar changes.
The first thing I’d do is make sure that this problem actually happens, live view is getting new optimizations all the time, I’d put some kind of debug logging inside transform/1 and validate that it is being in fact called every time @bar changes.
If it is, try moving transform(@foo) into a partial (make sure the partial is .leex):
# _foo.html.leex
<p><%= transform(@foo) %></p>
# index.html.leex
<html>
<body>
<p><%= @bar %></p>
<p><%= render(@live_view_module, "_foo.html.leex", foo: @foo) %></p>
</body>
</html>
This allows optimizations around rendering partials to take place. If that still isn’t working then that sounds like a bug, those optimizations have been in for a while. If you have a BUNCH of state you want to manage around @foo a component may help, but this should help.
You can create some |> assign(:baz, transform(assigns.foo)), and then use @baz in the template, which helps avoid having transform/1 called unnecessarily, but at the expense of having to keep the result of transform/1 in memory. If this is an issue we can explore the temporary assigns route, but without a good illustration of the issue it’s hard to talk about specific tactics. It depends a lot on exactly how expensive transform/1 actually is.
2
DaAnalyst
Yes, that is precisely what I am doing now. I was just asking if there was a way not to. And transform/1 is expensive enough for not having to invoke it more than once per cycle.
But, now that you’ve mentioned this private key thing, I’m considering changing the design a bit so that the result of transform/1 keeps gettting assigned but its input data does not (but stored as private instead). Need to check of whether that’s gonna be possible. Thanks!
1
benwilson512
Author of Craft GraphQL APIs in Elixir with Absinthe
No problem, hope it helps! I’d also definitely check out whether using a partial solves your issue without any extra fuss.
Can you elaborate on what you mean by cycle here? Do you have some kind of timer or something that updates a value every X seconds? Or is this more like you’ve got a form on the page with phx-validate and you don’t want key strokes to cause transform/1 to run?
0
DaAnalyst
The result of transform/1 is a tuple of two structures (A & B) so the above example with partials won’t do. Besides, there’s is always the problem I originally mentioned. The structure B is getting modified by the transform/1 function (it is also one of the inputs) and it therefore must be assigned to live on until the next page/LV refresh (unlike structure A).
Rendering cycle. Not related to any timer, it’s just that the structure A is rebuilt on each re-render (re-render being triggered by change of the underlying structure that transform/1 takes for input in addition to structure B).
0
benwilson512
Author of Craft GraphQL APIs in Elixir with Absinthe
Just to make sure we’re on the same page, if there data isn’t changed, no re-render occurs. There isn’t some continuous re-rendering cycle that’s happening all the time that would cause transform to use a lot of CPU.
I’m not really following, can you provide a concrete example? It can still be a sketch, but I’m having trouble following the relationships between the values here.
0
DaAnalyst
The app is intended for use by really many users simultaneously. This particular part can be quite costly as events are fired on even the slightest changes to the model, which again, triggers re-rendering and transform/1 along with it.
{ a, b} = transform( c, b)
- a is obviously constructed from the scratch on each re-render and is moderately large (in terms of data contained, it can be thought of as a subset of c but a transformed one)
- b is very small, is updated and must therefore be kept assigned to socket.assigns
- c is potentially large and is getting updated by the server-side API functions and persisted into the DB
- both a and b are read from by the template
0
benwilson512
Author of Craft GraphQL APIs in Elixir with Absinthe
Ah. So this is important, I thought transform was pure. If transform isn’t pure then definitely call it inside the live view module and create assigns for a and the updated b.
0
DaAnalyst
I am already doing it for I have no other choice. As noted before, I intend to check if c can be put in private key instead of assigning it for a and c are data-redundant from the template perspective.
0