Update slot content without rerendering rest of component

[adamvleggett]

What problem does this feature solve?

I have developed some components that can generate large amounts of HTML, and allow content to be added via slot. It appears that if the slot content is updated, the render function is called for the component; however, this seems like something that could be avoided through optimization which would significantly improve the performance of my component in some instances.

Is this possible?

What does the proposed API look like?

Not proposing API changes.

[adamvleggett]

Note: I understand this wouldn't be possible for scoped slots. However, an optimization that might help even for scoped slots would be to only trigger rerender of the child component if the rerender of the parent component generated a delta for the actual slot content.

[LinusBorg]

Well, I think it would be possible to implement something that would diff slot contents before updateiung the components but - ignoring difficulties in implementing this for the moment, because I can't say much about this right now - it would come with a performance tradeoff:

With your proposal, we would save rendering the virtualdom of the child if nothing in the slot changed -
but everytime the diffing of slot content does find changes in the slot content, we would be diffing the slot content twice - because after the render function of the child has run, the new vdom has to be diffed again.

Essentially this means that now, children with big templates and small slot contents would run better, while children with small templates and big slots woudl run worse when changes happen.

Not sure what is better...

Also, technically the child would keep an outdated virtualDOM, because while the content of the slot nodes is the same, the parent created fresh nodes when it re-rendered, so I suspect that this might be a technical hurdle.

[adamvleggett]

In my case it's a slot that the component uses in a v-for loop to apply to hundreds or more repeats. In this case it's unquestionably faster to calculate the delta. I wonder if this can be reasonably detected.

[LinusBorg]

I wonder if this can be reasonably detected.

Hardly, and if so, only during compile time, not runtime. That would require some analysis during compilation that would have to derminate when a template is "expensive, then set some flag so the component resolts to slot diffing during runtime, and doesn't for cheap components.

Sounds easy but measuring "expensiveness" would be very tricky considering v-if having a big impactr on when a temnplate is actually expensive and when not, and the small fact that we cannot statically analyse during compilation how big the arrays that you render will be during runtime, etc. pp.

A new API would be thinkable to set that flag manually, at least in theory.

[adamvleggett]

I would say if either:

• the slot is used inside any loop
• the slot contents are smaller than the template

Then that's a time it's probably worth it to test the delta.

In my particular case, it would save me having to make some rather unintuitive changes to the structure of a library that's used by a lot of developers in my company.

[adamvleggett]

Also, calling the render function is typically much slower than performing a diff on two strings of data.

[rssfrncs]

Hi.

Is this issue still active?

[LinusBorg]

Yes.

[JosephSilber]

@LinusBorg

everytime the diffing of slot content does find changes in the slot content, we would be diffing the slot content twice - because after the render function of the child has run, the new vdom has to be diffed again.

Would it be possible to introduce a new watcher boundary API? This would be an internal implementation, to which template slot content would compile to.

This way, the slot's content wouldn't even have to re-render if the data it depends on doesn't change. Since it doesn't re-render, it doesn't need to be diffed.

[JosephSilber]

Just to show another use-case of how I bumped into this:

Vue's computed properties currently can't take any arguments. Instead, if you want to use some calculated data in a loop (which is generally where you'd need to pass data into a computed), you have to resort to one of these:

1. Using a regular method, such as calculateOrderTotal(order).

   However, using a regular method means that the data is recomputed with every render. That's bad for performance.

2. Create a separate functional component for the list item, and create an instance of that component for each item in the list, such as <Order v-for="order of orders" :order="order">. The component will then only re-render when the data passed to it is changed, which is what we want.

   However, putting the template in the component is not ideal because a) these are usually small snippets that don't really warrant being in their own template b) if the component uses a template then it needs its own .vue file, which makes this solution feel even heavier than it already is.

   So the solution I came up with is to have the component only calculate the data, but render all of its HTML via the default slot, thereby forgoing the template altogether. And now we get to the crux of the issue: if we pass content in the slot to the child component, it will always re-render along with the parent, which means that the data will also be recalculated on every single render¹. This totally negates any benefit we got over using a regular method.

Here's demo in action: https://codepen.io/JosephSilber/pen/MXJZro

---

¹ A potential solution would be to have a computed property within the child component, but then the component can no longer be functional. When rendering a big list, using functional components makes a huge difference.