[RFC] New context provider for useTres state

[alvarosabu]

Summary

This proposal introduces a change in how the core manages and distributes the internal state to the ecosystem.

Refactor this:

state: shallowReactive({
      scene: THREE.Scene,
      renderer: THREE.WebGLRenderer,
      aspectRatio: 1
    }),

To something like this:

state = {
   scene: ref(THREE.Scene)
   renderer: readonly(shallowRef(THREE.WebGLRenderer))
   aspectRatio: ref(1)
}

The state needs to be able to be injected into the packages of the ecosystem via provide/inject API and the subpackage should be able to watch the effects when the state is changed.

Motivation

In v2, the core state is a shallowReactive object to ensure decent performance on the render of the 3D scene. However, packages that depend on this state like (@Tresjs/cientos or @Tresjs/postprocessing ) need to watch the whole state for changes, meaning that any of the properties could trigger a not desired callback.

Having a strongly typed store that can be injected will give more control to the maintainers, selecting what parts of the store can be modified or readonly

Drawbacks

• Potential breaking change
• Store might not be injectable. (In that case the RFC will be drop)

Adoption strategy

It's not clear yet if this change will affect the end-user or only the plugin authors. For testing purposes, the code of the core will be released on a next channel in npm for testing in the ecosystem

The following tasks will need:

• Design state
• Implementation task New and better state context provider #331
• Cientos refactor Refactor useCientos to new state context provider cientos#120
• Postprocessing refactor Refactor useCore to new state context provider post-processing#43

[alvarosabu]

Update: POC for state done here https://github.com/Tresjs/state-poc

Result: is working as expected (I simulate an async write on the state on the core package and the playground watchers react to it)

⚠️ It only works if the provide key is a fixed string, if we try to export a symbol key it doesn't work in a different context

[Tinoooo]

I like the PoC. I would call the composables differently though. The way Markus did name his here is quite good in my opinion. The equivalents in our case would be useTresContextProviderand useTresContext.

@alvarosabu What would you think about passing the things which are initially known (like the canvas and the scene for example) to useTresContextProvider like so useTresContextProvider({ canvas, scene, /*...*/})?

[alvarosabu]

@Tinoooo Agree with the naming convention, we don't really need a "store" but more a "context"

Scene I think it would be possible but the canvas and the renderer need to wait for the actual DOM element to be mounted (see https://github.com/Tresjs/tres/blob/main/src/components/TresScene.ts#L87) so they will be undefined at the beginning.

But I think we could even get rid of the need of using the TresScene component 🤔 but that is something we would need to try o the actual core package.

Check the latest commit https://github.com/Tresjs/state-poc/commit/a67665b86b5400474f7dec2095e7777d7c16bf92

[Tinoooo]

Ah you are right. Let's keep it without parameters then.

[alvarosabu]

Next step:

Design of state

We should answer following questions regarding state before continuing:
What properties do we want to have on the state (thinking on which things the ecosystem would use) One example is windowSize prop for the Scrollcontrols on cientos
Which properties need to be readonly
Which properties need to be shallow (Renderer and ...) to ensure performance
Which computed properties could be useful, should be there or outside of the context provider

We can get some inspiration from https://github.com/pmndrs/react-three-fiber/blob/master/packages/fiber/src/core/store.ts but i will like to focus on which properties we need to make the ecosystem work

[Tinoooo]

@alvarosabu @JaimeTorrealba Thank you for the great meeting yesterday. I think we found a good structure for the context. Here are our findings concerning the stuff we want to have in the context.

Name	Type	Requirement	Details
scene	readonly, shallowRef	essential
cameras	readonly, shallowRef	essential	userData.TRES_IS_ACTIVE_CAMERA = true const cameras = shallowRef([]) return { cameras: readonly(cameras)}
camera	computed, readonly	essential
pushCamera(newCamera: Camera, setActive: boolean)	function	essential	cameras should be watched and removed from the cameras array if they got removed from the scene
removeCamera(camera: Camera)	function	essential
setCamera(cameraId string)	function	essential
renderer	readonly, shallowRef	essential	setRenderer(renderer: Renderer) maybe only callable once?
setRenderer(renderer: Renderer)	function	essential
sizes (height, width, aspectRatio)	readonly	handy	sizes: {     height: Ref     width: Ref     aspectRatio: Computed }

We were not quite sure if the container around the main canvas element is required or not. We will find out though ☺️.

[alvarosabu]

Thanks @Tinoooo for sharing it here

[JaimeTorrealba]

Thanks, @Tinoooo, I will add:

Controls property will be moved to useCientos()

[alvarosabu]

Update, complete refactor for #331 is now available on https://github.com/Tresjs/tres/releases/tag/2.4.0-next.7 thanks to @Tinoooo for the amazing work.

[alvarosabu]

Well we can say this is done 💚