[ENHANCEMENT] Injecting dependencies during initialization?

[tanaydimri]

Hi all,
Wondering if the sparkjs community would be open to the possibility of injecting the third party dependencies or their subsets like threejs/threejs-addons during the SparkRenderer initialization? Something like:

import {Mesh, Material, ...} from "three";
new SparkRenderer({ THREE: { Mesh, Material, ... } }) // If somebody does want to pass a subset.

OR optionally:

import * as THREE from "three";
new SparkRenderer({ THREE: THREE }) // Should be enough in most of the cases to allow importing from CDN at runtime.

REASON

The reason I am requesting/proposing something like this is to allow users to import sparkjs from CDN without having to import the entire threejs library and it's addons on the webpage. We specifically build web components for our products and do ensure to treeshake three and other libraries as much as possible. With the latest update to 2.x.x and in-lining of the wasm modules, the build size goes up quite a bit with spark js. One options to work around this is to import sparkjs at runtime only within the session where required, but we cannot do that without importing the entire threejs library and it's addons on the webpage itself. Since the sparkjs build assume that "three" is available as a module on the page.

I have seen similar pattern in other threejs libraries. For example: https://github.com/yomotsu/camera-controls
Given that their functionality is a lot simpler than something like SparkJS but (without looking deep into the codebase) I don't see a good reason to not be able to do something like this.

I would even be more than happy to work on this and submit a PR for review if everyone agrees this is in fact possible and could a potential solution for many users.

Thank you for building an amazing library that lets us integrate Splats within threejs with ease.

[mrxz]

Given that their functionality is a lot simpler than something like SparkJS but (without looking deep into the codebase) I don't see a good reason to not be able to do something like this.

The simpler the project, the easier it is to accommodate such a pattern. I'm afraid it won't be a good fit for Spark. At the moment there is no single setup/initialization required. In part because some resources are statically initialized, while others lazily initialized. To properly inject THREE as a dependency would mean to rework these parts and introduce a mandatory setup call.

Using the SparkRenderer constructor for this won't do as some operations can be done before/without a SparkRenderer and there might be more than one SparkRenderer in an application. It would suddenly be possible for users to pass inconsistent values to the two instances, which is an error state that currently does not exist.

Not to mention that the actual elements from the THREE module needed is unlikely to remain stable between releases and can depend on runtime behaviour. Having users try and figure out the subset they need feels fragile and probably won't be recommended even if this were to be implemented.

The reason I am requesting/proposing something like this is to allow users to import sparkjs from CDN without having to import the entire threejs library and it's addons on the webpage. We specifically build web components for our products and do ensure to treeshake three and other libraries as much as possible.

It would help if you could elaborate your approach a bit more. Since you are tree-shaking three, what is preventing you from pointing the three entry in the importmap to your tree-shaken three.js build? If needed you could introduce stubs for elements Spark imports but doesn't end up using at runtime for your usage.

With the latest update to 2.x.x and in-lining of the wasm modules, the build size goes up quite a bit with spark js.

For what it's worth, the upcoming release should see a nice reduction in bundle size already (see #321). The latest main commit is sitting at ~2.5MiB (884KiB gzipped). The bundle size is likely to remain larger than 0.1.X was, simply by the fact that more features are included and parts have been moved into the Rust project (e.g. the parsers).