Slot forwarding with render functions

[diachedelic]

For a few years now, we have been writing our Vue components using render functions rather than Vue's templating language. This allows us to write our components in plain JavaScript with no compilation step.

Until now we have had no problems. However, my teammate recently made a component that "forwards" its default slot to a child component. The component hierarchy looks like A -> B -> C. A passes content into B's default slot, and then B forwards its slot content to C. So far so good.

Our problem is that whenever B re-renders, the slot content is also re-rendered, leading to serious performance degradation. You can see the problem manifest in this Playground. Notice how the timestamp follows the cursor as you move the mouse around the preview. Now, the timestamp should not change. The render function passed in by A (Date.now), is not reactive and so only needs to be called once.

Interestingly, when the same set of components is written using Vue templates, the correct behaviour emerges. You can see that in this Playground.

Selecting Follow.vue's "JS" tab reveals the compiled template code. This is the working render function, and it appears to be aware that the slot is being forwarded:

function render(_ctx, _cache, $props, $setup, $data, $options) {
  return (_openBlock(), _createElementBlock("span", {
    style: _normalizeStyle($setup.style)
  }, [
    _createVNode($setup["Text"], null, {
      default: _withCtx(() => [
        _renderSlot(_ctx.$slots, "default")
      ]),
      _: 3 /* FORWARDED */
    })
  ], 4 /* STYLE */))
}

My question is, how do I get the behaviour of the working example using only render functions? Is it possible?

[skirtles-code]

I've been giving this some thought, but I still haven't really come up with an approach I'm happy with.

If you're exclusively using render functions, then perhaps you could switch to using a props to pass down the slots, rather than using actual slots? Many of the usual benefits of true slots don't really apply if you're just using render functions.

Another approach might be to use the $stable flag:

• Playground

The $stable flag tells Vue that the slot functions don't change, so it doesn't need to re-render every time. It doesn't turn off reactivity within the functions, it just means that the functions themselves don't change.

But I'm not really happy with that approach. It works OK in this example, but it could block updates if the App.vue conditionally changes the slot function it passes down, even though it's not passing the $stable flag itself.

I feel like there's a trick here I'm still missing, but I figured I'd share those ideas for now, maybe they'll work in your specific use case.

[jamesdiacono]

We still have many SFCs written using templates, so we need to maintain interoperability with them. I think we will try to use slots, rather than props, if possible.

I didn't know about the $stable flag, thanks for the tip. I think it might work for our specific use case, because the functions we pass as slots don't change. I verified that $stable respects reactive slot functions in this playground, and that updates are lost if the slot functions themselves are swapped in this playground.

However, I think Vue could provide a better way. Vue should be able to determine if a slot has been forwarded by comparing the slot function passed to setup with that returned by render. For example, consider the following component. All it does is wrap its default slot in a <div>.

export default {
    setup(props, {slots}) {
        return function render() {
            return h("div", slots.default);
        };
    }
};

If slots.default is Date.now, render will return the following vnode, redacted for clarity:

{
    __v_isVNode: true,
    type: "div",
    children: {
        default: Date.now,
    }
}

The slot is clearly forwarded if slots.default === vnode.children.default.

[Namidas]

I've been doing this (and avoiding re-renders) passing down the base compo as a prop and capturing slots in a computed or directly on the render function if any (on whatever deeply nested child compo).

Let's say you send a ctx prop down the line (which is just this on parent compo), just make sure EVERY nested compo (where you want to "inject" slots) recieves it, give "explodable" names to slots that make sense in your logic, like "compo1:compo2:real-slot-name" and on whatever other/nested compo, on render, traverse Object.keys(ctx.$slots) and you should know/get what to inject.

How you actually end up doing this (passing down this "context", traversing $parent, whatever) should be the same with this approach since you don't actually pass down the slots (which would cause the re-renders) but rather a source of slots (an Object, which shouldn't react on render since those slots are not rendered anywhere except in the one component that explicitly uses them)

[diachedelic]

I'm having trouble following this strategy. Passing a component instance as a prop seems very wrong to me. Is that necessary for your approach to work? Can you give an example?

[Namidas]

It's really no different (passing down a compo instance as a prop, security-wise or whatever) than traversing v-nodes upwards through $parent.
But in all cases any way of hooking/relating components will serve the same purpose.

Let's say for instance you create an input component with complex rules, and then you create a form component that checks the state of those rules on any compo that supports it before submitting, otherwise it disables submit...how would you "hook" those components to work together no matter how deeply nested the input compo is inside the form compo ? Whatever the answer, is the way you will also pass down (in whichever format of your preference) the slots objects from the original compo to "inject" (or even cascaded through every single parent compo not just the "base" one).

now, specifically (and probably with syntax errors), I proppossed something like this:

base compo:

<template>
	<div class="main-compo">
		<some-other-compo :ctx="ctx" />
	</div>
</template>


<script>
export default defineComponent({
	computed: {
		ctx() {
			return this
		}
	}
})
</script>

(of course, just for the sake of it, I'm using templates here...)

child compo render function, should include something like this:

function getSlots(src)
{
	/* traverse the provided slots object and determine which ones you want,
	probably based on slot names */
}

const slots = getSlots(props.ctx.$slots);
const mainSlots = {};
for (const x in slots)
	mainSlots[x] = (scope) => {
		var newScope = {
			//some child-compo specific props ?
		};

		// cycle this, don't spread it...
		for (const scopeKey in scope)
			newScope[scopeKey] = scope[scopeKey];

		return props.ctx.$slots[slots[x]](newScope);
	};

return h(ChildCompo, {
	ctx: props.ctx,
}, !Object.keys(mainSlots).length ? undefined : mainSlots);

Couple of notes...

• Notice how we're actually going a little further and actually "inheriting and extending" whatever scope the slot originally had
• We're also passing down props.ctx as a prop
• Slot names are (potentially) crucial and very dependant on what exactly do you intend to, in general I would assign UIDs to components and use that in slot names, something like [compo-uid]:[slot-inner-name], but again, how you approach slot naming depends on what exactly are you trying to achieve
• Following on the idea of slots naming, and how your getSlots function works and returns values, the line of code that actually returns the rendered slot return props.ctx.$slots[slots[x]](newScope); will have to change accordingly, in my example, in general and for the sake of simplicity I would make that function return an object in the form of {[inner-slot-name]: '[original-slot-name]'}, that's why when I'm assigning it on the mainSlots object for h() I'm using x (which would be the key or in this case the expected name for the slot in this child compo) but when calling it through ctx.$slots I'm using slots[x] (which in this example would hold the full name of the slot originally used in whatever parent compo)

That's how I would (and do) deal with passing down slots, again: just avoid using/passing-down those slots as slots on each compo on the whole chain of compos, or you'll get those nasty re-renders, never include them in any manner in any compo except the one that is intended to render them, and for that you need to hook/communicate/whatever compos some way, which leads us to the main point here...

How exactly are you going to connect those compos so that it can directly access an object of slots? (which in the end, are nothing more than functions themselves), here's a couple of ways...

• Passing down a context as a prop, potentially the base compo (as shown on the example above)
• Traverse v-nodes upwards through the $parent prop, how/when to stop, is up to you and your specific needs (but is actually no different than passing it down as a prop in terms of security, dirtiness, whatever, in all cases you'll end up with a full compo object)
• Use provide/inject to hook components ?
• Probably some other way that I'm forgetting about

Provide/Inject is probably the more "elegant" way, but seriously, I don't see the problem with just passing down a (so called) context.

Hope that clarified the idea a little.

EDIT: very important note, just noticed I actually gave you an example (for the child-compo render function) of a transparent wrapper renderer, intended to actually render another component (a component that renders components with the final slots, scopes, etc) and that's also why I'm still passing down the ctx prop, quite useful if you want to inject slots into whatever compo, not just one you have control of it's render function.

But in your case, if you do have control of that render function, then just ignore everything after the getSlots(props.ctx), by then you already have your compos hooked, and from that you already got the slot functions you needed from whatever parent, and just do your rendering as you would normally.

[diachedelic]

Your approach seems tailored towards templates and the Options API, both of which I am trying to avoid. I agree that passing render functions ($slots?) down via props or provide/inject is a workable strategy, as was suggested by @skirtles-code .

[Namidas]

Ok...with all due respect, this is all wrong XD
But I gotta thank you, all this really put my brain to work (I've been at this for the last 5hs), still having a working solution from the beginning (the one mentioned on my previous post), but still trying to figure out why it kept re-rendering, at least it got me to a conclusion of some sorts, and now without further ado...

---

First off your problem is not on passing down slots but reactivity inside your render functions triggering re-renders and slots react/get-called-again when their source compo is re-rendered.

Just put a console.log('rendering [compo]'); on each render function (including the one on App.vue) to check what's going on (don't rely on that timestamp) before moving forward.

In your example A (App.vue) is getting re-rendered even when there's no B or C child compos.
The reason is simple, you're using a reactive value inside a render function (left/top), so every time that value changes, the render is triggered, and that is true for just any child compo as well.

• You should change your App.vue render to pass down left instead of left.value, that way your passing down a constant (the reactive itself) instead of it's value (which as stated, when it reacts, triggers the re render)
• You would also need to slightly change Follow.js to use props.left.value or unref(props.left) instead of props.left directly (because now it's not the value but the reactive itself)

There you go...if you check your console now, you'll see you'll get re-renders on Follow and Text compos, but not anymore on App, which was the only unnecesary re-render there.

So...why does Follow get re-rendered as well ?

Simple, because left/top changes inside the render function trigger the re-render (and it's the intended behavior in your example, or it wouldn't update the style prop)

So...why does Text get re-rendered as well ?

Because you're passing down a slot that belongs to a component that is being re-rendered so it triggers reactivity on the slot and thus re-renders the child compo using that reactive (this is actually out of my head, not a proper documented answer, an excercise of imagination or an actual Vue thing wether intended or unintended?...who knows...).

Go back to my previous comment, "hook" your components in whichever way you find best fits your needs and instead of "sending slots down from the parent", "go up from your child compo searching for slots".

First off, on Follow.js, remove the slots param for h(Text) or you'll still get unnecessary re-renders on Text.

then, on Text.js...

const inst = getCurrentInstance();
const slots = inst.parent.slots;

Then just use slots.default() (or whatever slot name).

And there you go...you can check your console and see that only "Follow" is being re-rendered on mouse move.

Again, this approach (actually, how you look for the slots you need) depends a lot on the specific structure of the virtual dom, so it all comes down to what you're trying to achieve, but keep in mind what I said on my previous post about "explodable slot names that follow some logic of some sort", writing a function that looks for those (potentially, inject it from the top parent that "supports inheritable/injectable slots"), etc etc etc.

A personal comment on this...

When developing that transparent wrapper/renderer that I mentioned on my previous post, I think I remember trying to "send down" slots through props and still got the same problem of unnecesary re-renders (which would make sense for the reason I described above about reactives on the render function).

When checking this kind of stuff, just make sure you're console logging renders, don't rely on something like a non-reactive timestamp.

---

On a different subject...so why does the templates version work propperly ?

Simply put: it doesn't XD
Use a onRenderTriggered hook on each component console logging that it was triggered and you'll see that you get constant re-renders on all 3 components (App, Follow, Text).

So why doesn't the timestamp get constantly updated ?

Simply because on that implementation you're passing it down as Date.now() (the call to the function, not the function itself) which returns an static value that Vüe interprets as a static text node, while on the first case you're passing it down as Date.now (the function itself) which Vue interprets as a slot function and then it gets called over and over again (and thus the resulting value gets updated) on each re-render.

---

And now for something completelly different...

Nah, just kidding ñ_n
Here's a working example.

Cheers ♥

[diachedelic]

In your example A (App.vue) is getting re-rendered even when there's no B or C child compos.
The reason is simple, you're using a reactive value inside a render function (left/top), so every time that value changes, the render is triggered, and that is true for just any child compo as well.
You should change your App.vue render to pass down left instead of left.value, that way your passing down a constant (the reactive itself) instead of it's value (which as stated, when it reacts, triggers the re render)
You would also need to slightly change Follow.js to use props.left.value or unref(props.left) instead of props.left directly (because now it's not the value but the reactive itself)
There you go...if you check your console now, you'll see you'll get re-renders on Follow and Text compos, but not anymore on App, which was the only unnecesary re-render there.

I made those changes to the original playground in a new playground, and the behaviour is the same: the timestamp re-renders when it should not.

Because you're passing down a slot that belongs to a component that is being re-rendered so it triggers reactivity on the slot and thus re-renders the child compo using that reactive (this is actually out of my head, not a proper documented answer, an excercise of imagination or an actual Vue thing wether intended or unintended?...who knows...).

Vue is not restricted to the behaviour because it has the concept of a "forwarded" slot, as mentioned in the original post. My question is how to make use of this "slot forwarding" machinery without writing templates.

First off, on Follow.js, remove the slots param for h(Text) or you'll still get unnecessary re-renders on Text.
then, on Text.js...

const inst = getCurrentInstance();
const slots = inst.parent.slots;

A child component reaching into the internals of its parent component is very tight coupling, and defeats the point of making them separate components in the first place.

On a different subject...so why does the templates version work propperly ?
Simply put: it doesn't XD
Use a onRenderTriggered hook on each component console logging that it was triggered and you'll see that you get constant re-renders on all 3 components (App, Follow, Text).

That is not true. See this playground.

[Namidas]

Regarding your updated "templates" version...

That is not true. See this playground.

I will address this first because it's a serious misunderstanding of how Vue works.
I hope it's just a mistake (which I'm guessing not, since you insisted on the same idea even when I pointed this out, while further developing that approach and adding that console.log on that compo slot), but that's seriously wrong.

In that case (inside that slot) you're essentially passing down 2 static values (in your updated playground), null (from the call to console.log) and a string (from the call to Date.now), so they're correctly never updated because they're correctly being interpreted as static values, cached, and never re-rendered. That's the reason why you only get one call to console.log and one call to Date.now, on first render, and the only reason you're seeing it as "working properly, not having re-renders, not having constant updates on the timestamp or the console`.

Further more, if my memory serves me well, Date.now is often used (either in this exact same way or, usually, inside a computed) as the go-to example of understanding how reactivity doesn't work.

The "render function" way to replicate this behavior would be passing down () => Date.now() for the slot, instead of just Date.now, further more, if you tried to pass down Date.now() as-is for the slot it would give you a "non-function slot" warning.

In other words, putting Date.now() inside a slot or writing 1234567890 will have the same result: static string, never updated.

Now, especifically to the console.log part of it, why it never gets called again is the exact same as why Date.now never gets called again so I'm not going to go into that and explain why in no way represents the constant re-renders that you do have, but I would say that you need to pay a little more attention to what people is taking their precious time to reply to you, let me quote that for you...

On a different subject...so why does the templates version work propperly ?

Simply put: it doesn't XD Use a onRenderTriggered hook on each component console logging that it was triggered and you'll see that you get constant re-renders on all 3 components (App, Follow, Text).

So if you update your App.vue to something like this...

<script setup>
import { h, ref,onRenderTriggered } from "vue";
import Follow from "./Follow.vue";
let left = ref(0);
let top = ref(0);
window.onmousemove = function (event) {
    left.value = event.pageX;
    top.value = event.pageY;
};
onRenderTriggered(() => {console.log('render triggered')})
</script>

...you'll see your false render flag only once (for the gazillion-th time, because it gets cached as static slot content and never called again) and the other call to console.log (the one inside the onRenderTriggered hook) firing every single time that you move your mouse.

That's for the "serious stuff" in your Vue concepts.

---

Now for the rest of it...just check your own reference on coupling...

Good modules are loosely coupled. You should only need limited knowledge of a module’s interface in order to make good use of it

• First off, I did give you different options on how to achieve this and commented on the fact that probably the "most elegant and propper" way is Provide/Inject
• Second, "loosely coupled" is quite different to "have no idea", I really don't see why "knowing that upwards, somewhere, there's stuff I need to look for" is not "loosely coupled", although it's true that I did provide code that required exact-not-just-loose knowledge of the virtual dom, but it's also true that I did point that out myself, did point out that you should check your specific case, effectivelly implying that I wasn't going to do it for you and that there are more "generic" if not "loosely coupled" ways of achieving the same, it's up to you to find/develope what best suits your needs.

---

The "Vue has slot forwarding" thing, you got me there...sort of...because I did actually comment on this as well...

So...why does Text get re-rendered as well ?

Because you're passing down a slot that belongs to a component that is being re-rendered so it triggers reactivity on the slot and thus re-renders the child compo using that reactive (this is actually out of my head, not a proper documented answer, an excercise of imagination or an actual Vue thing wether intended or unintended?...who knows...).

If "slot forwarding" is to be understood as-is, then yes, I would agree that what we have here is either a very dodgy implementation (on the framework itself) and/or a bug.

But in all cases your insistance on how that works and using that "templates" example to prove it has already been debunked on my first point and at least you now have the same consistent (wrong?) behavior between implementations, again, "regardless of wether this or that", proper behavior or bug, intended or unintended, etc.

On the other hand, I would quote uncle Ben if you will:

With great power, comes great responsability

Scripting languages (versus programming languages) are all about dirty-tricking your way around, period.
If you want C++ your way into this, maybe you'd be better off with React or some other framework (or maybe even just write a strongly typified framework that takes away both power and responsability).

I'm saying this with respect and as a general thing (even though you're going to, potentially, take it personally XD), but a guy writing a book about the science of something has nothing to do with the actual field work of making things...well...actually work, no matter what, whenever, wherever, in whichever way even if suppossedly impossible and/or finding your around way to circumvent a framework bug (if any), but finding balance between theory and practice is up to you.

Either way, bottom line seems to be this:

Because you're passing down a slot that belongs to a component that is being re-rendered so it triggers reactivity on the slot and thus re-renders the child compo using that reactive (this is actually out of my head, not a proper documented answer, an excercise of imagination or an actual Vue thing wether intended or unintended?...who knows...).

So you can either loosely-coupled implement something that works around that and/or report a bug on vue's repo.

What you can be sure about is that templates example doesn't work as you think/expect it to work...

And I'm starting to repeat myself here, so I'll leave it at that.

[diachedelic]

You are absolutely right that App.vue rerenders. My apologies. It passes down the mouse coordinates to its child component as props, so clearly it must rerender as the mouse moves. What I meant to to say is that even though App.vue is continually rerendering, the slot content is not reevaluated. As you rightly point out, that is because the slot content is unreactive. The template compiler is using the "slot forwarding" mechanism to pass down a slot function that is not run every time App.vue is rerendered, and that is the functionality I want to harness in my render functions but can not.

The "render function" way to replicate this behavior would be passing down () => Date.now() for the slot, instead of just Date.now.

If I passed () => Date.now() as a slot argument in my render function, every time the render function is called a new function instance is created and there is no opportunity for Vue to compare by reference. Therefore Vue would have no opportunity to detect that I am trying to forward a slot. Like this:

function render() {
    return h(component, props, () => Date.now());  // fresh slot argument every time
}

That is why I passed down Date.now, which is exactly functionally equivalent to () => Date.now() yet has a stable identity.

function render() {
    return h(component, props, Date.now);  // slot argument never changes
}

So you can either loosely-coupled implement something that works around that and/or report a bug on vue's repo.

The lack of support for forwarded slots in render functions is not a bug, it's a missing feature. So I created this discussion rather than a bug report, because I thought I saw an opportunity for improving Vue.

[Namidas]

Additionally...
You could find a repo for whatever component that does anything similar to this (like that vue-forward-slots) and check the source code to see how that person resolved it.

Actually, just did that with that example and regardless of all the logic to determine which slots to pass down or not, it ends up doing something like this h(SomeChild,{},slots) as well, so I'm not so sure it's really a good example, at first sight (after all this and in the context of this discussion) it seems like it would have unnecessary re-renders as well.

Anyways...enough is enough XD~~~~~~~~~