current situation about tree shaking

[slash9494]

i tried to build my project and i found react-babylonjs take all import of @babylonjs/core on react-babylonjs.js even if i take import @babylon/core separately like @babylonjs/core/Meshes/abstractMesh on my component surely, it is affected to reduce babylonjs size

i has searched issue about tree-shaking it, and i understand it is not resolved yet,

So, i want to know anything method to import @babylonjs/core on react-babylonjs partially

and i wonder why react-babylonjs take more modules when i reduce @babylonjs/gui size like this

[brianzinn]

yes, I am working on a new version that registers types explicitly! it's a v4 with breaking changes! how did you reduce @babylonjs/gui size or what change made 'react-babylonjs' increase modules?

[slash9494]

I just import gui explicitely same with @babylonjs/core/Meshes/abstractMesh

So i want react babylon to take this tree shaking method

and i don’t know why react babylonjs increase when i reduce @babylon module I just assume react babylonjs import all gui module if @babylon/gui import explicitely

[brianzinn]

It does import all modules - that's how it dynamically instantiates objects, so when you do <arcRotateCamera /> that it can be newed up - same as all other objects supported by the API. The idea is to dynamically register via side-effects in v4 to allow for tree-shaking. Keep in mind that as this project uses the react-reconciler that it needs to be able to create all instances and doesn't know which instances it will need access to, so that the problem that needs to be solved for. The current way of thinking is to add a breaking change that requires loading as a side effect a registration for those classes and even, in fact, that gui would be added as an extra (same as other add-ons like procedural textures, materials, etc.).

[slash9494]

great it actually does not critical issue on my project yet, just i want to optimize my project more So, i decide to expect next v4 at last, i just wonder what process of breaking change, i don't know how to apply it

[brianzinn]

when I deploy v4 there will be a required registration. So, it may mean to register all of supported API (what is currently happening). With v4 there will be a tree-shacking opt-in mechanism where you choose which classes are supported declaratively and the rest should be tree-shaken.

The dynamic registration is already in place - right now you can, for example, register with the reconciler grid material, which allows you to write JSX like this:

<gridMaterial lineColor={Color3[selectedColor]()} />

You can see the storybook here: https://github.com/brianzinn/react-babylonjs/blob/master/storybook/stories/babylonjs/Materials/grid-material.stories.js

And the online version here: https://brianzinn.github.io/react-babylonjs/?path=/story/extensions--grid-material-example

That storybook shows how to register from @babylonjs/materials. In v4 the gui will not be part of v4, but a separate library that can be registered. It will trim down the bundled size considerably. Will be working on a JAM stack demo for it. If you have any ideas or want to help let me know. I will try to get it out this year.

[slash9494]

nice dynamic registration if possible, i hope dynamic registration guide line to use it

[brianzinn]

it will be a bit tricky, because if any registrations are missed then it will fail at runtime. it will be an opt-in mechanism purely for those trying to reduce bundle size. Also, the way the reconciler is created now will require re-registration on tear down, so there will be recipes and a guide for sure.