Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Forward updateTriggers to the inner TileLayer, so tiles can be refetched

Open
  • Is something wrong?
#797 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
58/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
typescript
Domain
data-visualization, frontend, testing

Research direction

Start with packages/deck.gl-raster/src/raster-tile-layer/raster-tile-layer.ts and packages/deck.gl-geotiff/src/mosaic-layer/mosaic-layer.ts, then compare their inner TileLayer props with deck.gl's TileLayer trigger behavior cited in the issue. Add tests with @deck.gl/test-utils for render, refetch, all, and opacity behavior; the issue lists each expected result. Done means the trigger mappings and documentation match those behaviors and the tests pass.

Written by the indexing model from the issue text.

Description

[!NOTE]
This issue was written by Claude (Claude Code) on behalf of @kylebarron, not by @kylebarron.

Problem

RasterTileLayer (and so COGLayer and ZarrLayer) and MosaicLayer build their inner deck.gl TileLayer themselves. They pass it only some of the caller's updateTriggers:

deck.gl's TileLayer refetches only when data changes, or when updateTriggers.getTileData or updateTriggers.all changes (tile-layer.ts#L229-L252). Any other change rebuilds the loaded tiles' sublayers from the data they already have. A new getTileData function on its own doesn't count, because deck.gl ignores changed function props (prop-types.ts#L188-L196).

That leaves three gaps.

1. No trigger can refetch tiles

COGLayer and ZarrLayer wrap whichever getTileData, and for ZarrLayer whichever selection, is current at each render (cog-layer.ts#L321-L354, zarr-layer.ts#L364-L373). When either changes, tiles loaded afterward use the new one, but cached tiles keep their old data, so the layer shows a mix.

No updateTriggers key reaches the inner TileLayer's getTileData trigger. So the only way to refetch is a new layer id, which drops the whole cache. The examples do just that: aef-mosaic uses id: `aef-zarr-layer-${yearIdx}` (App.tsx#L102), and dynamical-zarr-ecmwf uses id: `ecmwf-zarr-layer-${initTimeIdx}` (App.tsx#L222).

ZarrLayer's comment recommends updateTriggers: { renderTile: [selection] } to invalidate cached tiles when selection changes (zarr-layer.ts#L368-L373). But renderTile only rebuilds a cached tile's layers from its cached data, which was fetched for the old selection.

MosaicLayer has the same gap for getSource, which its inner getTileData calls (mosaic-layer.ts#L262-L278).

This follows from the code. I haven't reproduced it in an app.

2. MosaicLayer's renderSource trigger works by accident

A trigger change makes MosaicLayer render again. Each render defines a new MosaicTileset2DFactory (#L241-L245), so the inner TileLayer sees a changed TilesetClass and rebuilds the layers of every loaded source.

RasterTileLayer relies on the same mechanism on purpose, and says so in a comment (#734). MosaicLayer doesn't. Moving its class out of the method would silently stop renderSource triggers from reaching the sources already loaded.

3. updateTriggers.all doesn't reach the inner TileLayer

deck.gl passes all down to every sublayer built with getSubLayerProps (composite-layer.ts#L215-L217). Neither layer builds its TileLayer that way.

Proposed fix

  1. In RasterTileLayer, pass updateTriggers.getTileData and updateTriggers.all on to the inner TileLayer, beside the existing renderTile → renderSubLayers. COGLayer and ZarrLayer inherit that, and ZarrLayer's comment can then recommend getTileData: [selection].

  2. In MosaicLayer, map getSource → getTileData and renderSource → renderSubLayers, and pass all.

    • Building both inner TileLayers from this.getSubLayerProps(...), as deck.gl's TerrainLayer does (terrain-layer.ts#L364-L365), would pass all along with the base props that #784 is about.

  3. Document the triggers in one place:

    Layer Trigger Effect
    RasterTileLayer, COGLayer, ZarrLayer renderTile Rebuilds loaded tiles from their cached data, without fetching
    getTileData Refetches every tile
    MosaicLayer renderSource Rebuilds loaded sources from their cached data, without fetching
    getSource Refetches every source
    All of them all Refetches and rebuilds everything

    A change to a non-function prop already rebuilds loaded tiles (the per-render class, #734), so it needs no trigger.

  4. Add tests with @deck.gl/test-utils:

    • a renderTile or renderSource trigger rebuilds a loaded tile without fetching;
    • a getTileData or getSource trigger refetches it;
    • all does both;
    • opacity reaches a loaded tile (#784).

    These tests would also make #710's stable class safe to try later.

Related: #453 (closed by #462, which added the renderTile mapping), #710, #734, #784.

🤖 Written by Claude Code

Dominant language
TypeScript
Stars
231
Forks
34
Avg merge
1d 7h
Merged PRs (30d)
75

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

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.

More from developmentseed/deck.gl-raster

All issues in developmentseed/deck.gl-raster

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.