Make expo-gl and expo-assets optional

[CodyJasonBennett]

As described in #3352 and #3353, there is a need to swap the runtime under the Canvas when rendering with a WebGPU context or other alternative (e.g., Skia, ANGLE). expo-gl should be at minimum optional for those creating a custom canvas with their own runtime.

Polyfills should exit gracefully if any expo modules they depend on are not present.

[wcandillon]

just for reference, this is how we've handled optional dependencies in React Native: https://github.com/Shopify/react-native-skia/blob/main/packages/skia/src/external/reanimated/ReanimatedProxy.ts This pattern has worked well for us. This would indeed allow us to use three-fiber with WebGPU without installing expo-gl for instance.

[CodyJasonBennett]

Have you run into this issue with Metro https://github.com/facebook/metro/issues/666? Trying my hand at it in #3355 and I'm unable to find a workaround.

[wcandillon]

In its current form this approach as been working well for us and for https://github.com/mrousavy/react-native-vision-camera.

The three-fiber reconciller is so platform agnostic that I am surprised you offer different build of it for different platforms instead of offering varieties of canvases.

[CodyJasonBennett]

The reconciler isn't the one writing <canvas />, but as an aside, what do you think of R3F pulling in an HTMLCanvasElement API that can give you a 2D/WebGL/WebGPU context? The motivation is to avoid back-end-specific components and use web code where possible. This is far from the endgame my colleagues at Callstack are working on (which we're trying to include you in), including bettering WebGL support, but it's a stopgap until anything happens upstream. Still, I'll look through since I'm not 100% reproducing your workarounds so far for this issue.

[wcandillon]

What you are describing is exactly our vision. We describe it at https://www.youtube.com/watch?v=i-DGY98cTjk While working on <Canvas /> we stumbled on a generic canvas API that can spawn any context (skia, webgpu, filament, opengl, you name it).

This "generic" canvas APIs has been already used in prototypes where it spawn a Skia context and the results have yield substantial benefits.

Our focus with React Native WebGPU was to enable people to copy/past example from the web and have them work immediately: https://github.com/wcandillon/react-native-webgpu?tab=readme-ov-file#similarities-and-differences-with-the-web The only difference that can be spotted is that we use <Canvas /> instead of <canvas />.

[CodyJasonBennett]

I mean something that is actually compliant with the web and can be ingested in the three ecosystem—meaning it can spawn a 2D/bitmap/WebGL/WebGPU context and later integrate with W3C pointer events. Skia and OpenGL are implementation details, Filament is just a renderer; it is unrelated. The correctness is incredibly important, and React Native has realized that individually porting and maintaining modules is unsustainable, and it has to stop if we are to unify and build such high-level APIs. This was the main topic of the contributors' summit, and there are many other efforts to port WebGPU and WebGL besides our own, all duplicate and ununified. That's only going to slow us down if we can't get in the same room together or work in an open forum, especially with such ambitious goals to align with web. The stopgap I suggested is shimming what we can if you want something before this is done properly upstream, and all things considered, that could be measured in years.