InsightSoftwareConsortium / InsightSoftwareConsortium/ITK-Wasm
More options for itkjs file loaders
- Dominant language
- Python
- Stars
- 235
- Forks
- 61
- Avg merge
- 4d 19h
- Merged PRs (30d)
- 4
Description
The current dynamic loading of itkjs file loaders is flexible, but it is inconvenient for a variety of packaging and loading situations.
* It requires extra non-standard webpack machinery
* It prevents straightforward distribution by CDNs
* It causes extra runtime network traffic that might be undesirable in some situations
* As far as I can tell, it uses a non-standard mechanism for module loading
It would be nice to have some additional options for loading support for different file types. The most straightforward and standard is ESM dynamic imports using the `import()` statement. `import()` allows a file loader to load whatever code it needs dynamically, much like `require()` did. This mechanism is supported on most recent browsers according to `caniuse`.
An alternative is to provide a static import option for specific loaders. That would allow compile/load time initialization of support for particular formats. Other libraries do this with `import "@itk/loaders/dicom"` style imports that rely on side effects to build up a loader list. This option can be backward compatible with the existing loader: some modules would be loaded at load time, others just-in-time at run time, with the dynamic loading potentially disable-able.
In either the dynamic or static import case, modules would be treated as code, not as data. Right now, itkjs treats its dynamic modules as data that has to be put into the public source repository. By doing so, I would guess these modules are taken out of the standard webpack optimization path. Handling their code just like all the other code from the application is a more convenient and less brittle alternative to the current implementation.
Contributor guide
Assessment
This issue has not been assessed yet.