(v4) Move TresObject.__tres to a WeakMap?

[andretchen0]

Currently, Tres stores data directly on the THREE objects it creates, in Object.userData.__tres.

This approach means it's available to users and can be overwritten accidentally if a user does something like Object.userData = myData.

It also means that all objects that Tres manages need to have and maintain userData over their lifetimes. But not all THREE objects have userData, e.g., BufferAttribute.

Proposal

• Use a WeakMap for associating THREE.Object3D, etc., with Tres data.
• Move the WeakMap into root or elsewhere.
• Make it accessible from the outside, but only on-demand, e.g., for debugging/testing.

A goal in the design of WeakMaps is to do exactly the sort of thing we're doing with Tres, associating dynamic state with an object:

WeakMap and WeakSet are intended to provide mechanisms for dynamically associating state with an object or symbol

And WeakMap would allow us to more easily extend Tres to handle objects that don't have .userData. We could associate any object with Tres data, simply by using the object as a key in the WeakMap.

---

A WeakMap key/value is garbage collected when there are no longer references to the key. That means that, like the current setup, we won't have to manage deleting values ourselves – edit: like currently, they'll be garbage collected when the key is freed, assuming no other references exist. (Note that this won't fix memory leaks. But it should not add new leaks or new needs for avoiding leaks.)

[alvarosabu]

Hi, @andretchen0, for v4 we merged #516 which refactored the use of userData replacing it with a local state called __tres. So users would not use Object.userData = myData. but Object.__tres

But I'm highly interested in the use of WeakMap tho. Considering the refactor, could you provide some examples of how it would look in the code?

[andretchen0]

But I'm highly interested in the use of WeakMap tho. Considering the refactor, could you provide some examples of how it would look in the code?

Sure thing. I think I'm just about ready to show a POC for RendererOptions (nodeOps) plugins. The implementation currently uses WeakMap to allow plugins to get/set per-context data for Object3D etc.

[andretchen0]

The implementation currently uses WeakMap to allow plugins to get/set per-context data for Object3D etc.

Fwiw, I changed this implementation along the way, before submitting the draft POC PR.

In the PR, plugins just create whatever kind of state they need. That state remains private to them, unless they leak it.

I think a private WeakMap has some advantages over TresObject.__tres, mainly that users can't access it. So they can't overwrite it and they can't make their own code depend on it.

[alvarosabu]

Hi @andretchen0 I have been reading more about the Weakmap and I do agree it looks like the optimal solution for our use-case.

Should we create an issue for this aimed at v4?

[andretchen0]

Sounds good to me. I'll submit an issue today. 👍