In nodeOps.ts, I mentioned that cloning means that setup references are lost. Below is some demonstration code that can be pasted here.

useRenderLoop().onLoop(() => {
  torus.rotateX(0.01)
  torusKnot.rotateY(0.01)
})

Both torus and torusKnot continue to exist after the clone, but they no longer point to the on-screen objects, so the on-screen objects don't update.

If the objects aren't clone()d in nodeOps, the on-screen shapes will rotate – but other errors pop up.

I don't know if there's a workaround here. Just pointing it out.

@andretchen0 This argument makes me think we should abandon the idea of trying to make :object prop reactive, swiping instances without losing the ref is getting too complicated.

Users could still use primitives with conditional rendering, I wanted primitive to work similar to component but honestly at this point I don't know how to achieve it.

@alvarosabu

I don't understand the internals of Tres well enough to have an opinion on the feasibility here.

I'll start reading the source after I finish <AnimatedSprite /> for Cientos.

I wanted primitive to work similar to component but honestly at this point I don't know how to achieve it.

I agree that this is a worthwhile goal. It'd be great if it "just works".

@andretchen0 let me know if you are up to a pair-programming call to discuss the internals when you get free let me know, we definitely can use your knowledge and your quality feedback inside of the custom renderer code. 💚

@alvarosabu

Sure thing. That could be fun!

Hey @andretchen0 I created a thread on the core team discord channel discussing this but to give a summary:

I found a way of making it work (animations), the only constraint is that the object passed through :object needs to be of the same type (mesh -> mesh) (group -> group). If we do (mesh -> group), it doesn't work anymore.

Thanks! I'll go read the Discord.

It seems like this doesn't break references in <script> per se. The :objects still exist. But they're copied. That means something like the following (probably) wouldn't have the user's desired effect in the playground example:

useRenderLoop().onLoop(({elapsed}) => {
  torus.position.y = Math.sin(elapsed)
})

Whenever the primitive object becomes torus, torus is copied, along with its attributes. But the copy doesn't move like torus moves, because it's a different Torus.

@andretchen0 we will need to explicitly mention on the docs that the user needs to animate the ref (primitiveRef) but not the object (torus) following the same DX as they were using a <TorusMesh ref="torusRef" />

There are several reasons why we need to clone the object:

• Since we soft-swipe the instances when :object changes (we maintain the reference but copy all the attributes) that would modify the original object from the setup leading to unwanted side effects.
  It is not possible to pass a ref or reactive as @JaimeTorrealba mentioned in the thread. With clone, we can ensure that swiping between models is possible.

This is what happens without the clone

It's either has this limitation of having to use the ref coming from the custom renderer to animate or :object can't be reactive and users will need to use v-if and v-else to swipe models:

<primitive v-if="showA" :object="modelA" />
<primitive v-else :object="modelB" />

I balance through the first option.

@alvarosabu

I think the PR as it currently stands is an improvement. I don't want to stand in the way of improvements.

I approved the PR.

This sort of error is an itch I can't stop scratching, so if you want to keep scratching ...

Since we soft-swipe the instances when :object changes (we maintain the reference but copy all the attributes) that would modify the original object from the setup leading to unwanted side effects.

Can you elaborate on unwanted side effects?

Technical issues aside, there's a point that isn't clear for me conceptually. To illustrate:

<script>
...
const userMesh = new Mesh(...)
userMesh.position.x = 100

const userMesh2 = new Mesh(...)
userMesh2.position.x = 200
</script>

<template>
...
<primitive ref="primitiveRef" :object="userMesh" :position-x="300" />
...
</template>

• Should userMesh's x be 300? (300 is the value in the primitive)
• And later, if the user does primitiveRef.value.object = userMesh2, does that set userMesh2's x to 300?

For R3F, the answer to both is "yes", it seems. Here's a StackBlitz. Notice that the rotation of the TorusRing increments with every frame, but resets whenever it's made the primitive.object. And the Torus would normally be placed at x = 2000, but its x is set to the primitive's value.

That seems like the right solution to me.

I understand that this will make a clone, which is required at the moment, but is there a reason why it's necessary to go through nodeOps.createElement? Is it updating something on the Vue side, maybe?

Can you elaborate on unwanted side effects?

One side-effect is that is not possible to pass a ref or reactive as @JaimeTorrealba mentioned in the thread on Discord. With clone, we can ensure that swiping between models is possible.

Should userMesh's x be 300? (300 is the value in the primitive)

Yes, the prop has priority because it will overwrite the mesh positions on the setup.

And later, if the user does primitiveRef.value.object = userMesh2, does that set userMesh2's x to 300?

Users shouldn't overwrite vue template refs, wouldn't it be kind of an antipattern? I also see the users complaining about having to do this extra step of primitiveRef.value.object = userMesh2 vs :object being reactive.

const newInstance = nodeOps.createElement('primitive', undefined, undefined, {

That was to not having to duplicate the same code of the createElement inside of the pathProp since primitives have some special treatment, like localstate flags and such.