visgl / visgl/deck.gl

Mini RFC - Consistent API for data loaders

Open
#5,263 3 comments 2 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

feature
Dominant language
TypeScript
Stars
14.6k
Forks
2.3k
Avg merge
2d 9h
Merged PRs (30d)
42

Description

Background

deck.gl core includes two loaders: json and image

There are 4 official layers that currently require specialized loaders:

layer loader package dependency can customize? notes
MVTLayer MVTLoader @loaders.gl/mvt no
TerrainLayer TerrainLoader @loaders.gl/terrain no
ScenegraphLayer GLTFLoader none yes, with registerLoaders requires explicit import in app
Tile3DLayer Tiles3DLoader @loaders.gl/3d-tiles, @loaders.gl/gltf, @loaders.gl/draco yes, with loader prop

There are multiple design inconsistencies here:

  • ScenegraphLayer is the only layer that does not bundle the required loader nor specify a loaders.gl package as dependency. The user is required to install and import the loader themselves.
  • We've seen confusion regarding whether @loaders.gl/gltf has to be explicitly installed when using ScenegraphLayer, because it's pulled in by @loaders.gl/3d-tiles which is the dependency of a different submodule.
  • MVTLoader and TerrainLoader by default run on webworkers, but the full parser code is still bundled with the main app.
  • There is a pending feature request to make TerrainLayer support other loaders, e.g. quantized mesh terrain.
  • Tiles3DLoader has a significant bundle footprint. It also includes GLTFLoader and DracoLoader. This makes it pointless to exclude GLTFLoader from the ScenegraphLayer from bundle size optimization perspective.
  • Tile3DLayer allows the user to replace the default loader by specifying the loader prop, however the default loader will be bundled regardless.

Proposal

High-level principles
  • There should be a consistent story regarding how deck.gl supports different data formats, with its own dedicated documentation page.
  • When possible, *WorkerLoader should be used instead of the regular loader. This makes the bundle footprint negligible, without breaking the existing behavior.
  • Loaders that have big footprints may not be bundled by default, if the layer equally supports multiple data formats.
  • All layers should offer a way for the user to add to/replace the default loaders.
Roadmap
  • v8.4 (non-breaking)
    • Remove loader-specific code from Tile3DLayer. It should be handled inside loaders.gl after a loader is selected.
    • Add loaders prop to base Layer class
    • MVTLayer and TerrainLayer should use props.loaders instead of hard-coded loaders
    • Add GLTFLoader to ScenegraphLayer by default
    • Create documentation page on using deck.gl with loaders
  • v9.0 (breaking)
    • Drop Tiles3DLoader from Tile3DLayer defaults, mark loader prop deprecated for loaders
    • Switch default loader to MVTWorkerLoader and TerrainWorkerLoader

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the linked modules/geo-layers/src/tile-3d-layer/tile-3d-layer.js and review the base Layer loaders prop, MVTLayer, TerrainLayer, ScenegraphLayer, and Tile3DLayer entry points. Compare the unchecked v8.4 and v9 roadmap items with the completed items, then define the required API and documentation changes; done means the remaining proposal decisions are resolved and the roadmap is implementable.

Written by the indexing model from the issue text.

Assessment

Tech stack
javascript, typescript
Domain
data-visualization, frontend
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Needs clarification
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.