feat (timeline-layers): example

[charlieforward9]

In need of a big-data timeline for a project that can support hundreds of thousands of datapoints. Current solution is DOM-driven and lags out with a few hundred.

A timeline solution as a deck.gl composite layer introduces a performant interactive no-low-code tool supporting direct track integration with all Deck props including projection, viewState, any layer...

Current (DOM-driven)

Prototype

Screen.Recording.2025-11-08.at.1.16.55.AM.mov

End Goal

Ref: joby-aviation/noodles.gl#50 (reply in thread)

CC: @akre54 @ibgreen

[akre54]

Hey @charlieforward9, thanks for the tag. I'm not really familiar with the context behind this PR. Can you help me understad why you would make the timeline as a layer instead of using a canvas, for example? What does making it in Deck accomplish?

Also what's the use case for hundreds of thousands of clips? Are you really looking at all of those clips at the same time?

[charlieforward9]

@akre54

Can you help me understad why you would make the timeline as a layer instead of using a canvas, for example? What does making it in Deck accomplish?

In our NoodlesGL / New Heat conversation, we basically concluded that sharing UI frameworks between apps was a non-starter — different shells, different UX.
But we can realistically share deck layers. That’s the main motivation for putting the timeline in deck instead of writing a totally custom canvas:
• NoodlesGL can host it as a alternative to theatre studio's timeline.
• New Heat Studio can also mount the same Layer type inside its deck-based editor.
• Both get the same core behavior, but each app wraps it in its own React/DOM chrome around it.

Also what's the use case for hundreds of thousands of clips?

I plan on displaying many thousands of events and view state keyframes and I'd like to support a very granular level of detail. Right now, my DOM-based solution is lagging at a few hundred.

[ibgreen]

Separately from the discussion whether this is a good fit for noodles.gl / clip timelines...

I am currently building a couple of visualizations for very big timeline data and I find that this type of layers can be quite useful.

I have even played with the idea of creating a "timeline-layers" module if we collect a sufficient amount of support for this use case.

We already have the HorizonGraphLayer and TimelineAxisLayer etc in the infovis-layers module so this would land in good company

[charlieforward9]

@ibgreen how much support for the use case are you looking for? This is something I definitely need so I am planning to move forward with it.

I'd deeply appreciate your guidance and contribution if you already have opinions / samples in the scope.

Short term it feels easiest to continue down this path and build it as an example within infovis-layers, and once the kinks get flushed, consider splitting it out?

[ibgreen]

Is the idea to add a new CompositeLayer to the infovis-module?
As it stands all the timeline layer code is in the example, not very reusable.

[charlieforward9]

Is the idea to add a new CompositeLayer to the infovis-module?

Exactly.

As it stands all the timeline layer code is in the example, not very reusable.

Needed a quick demonstration to get a conversation going.

Do you have any snippets that you've experimented with to assist with the initial build of this, or do you recommend I take what I have and package it up myself?

[ibgreen]

Do you have any snippets that you've experimented with to assist with the initial build of this, or do you recommend I take what I have and package it up myself?

yes it is all there, in module/infovis-layers/src/layers/...

[charlieforward9]

Heres where I was able to land:

Recording.2025-11-25.023418.mp4

A lot of pending work, I would appreciate a review and some support with the interaction logic. Still feels like there's too many keyboard and mouse events external to the component that I need to understand how to abstract better.

[ibgreen]

• I created a new module timeline-layers
• updated this PR to add the new layer to that module
• updated the example to import from the module.

In terms of next steps

• I feel that the important thing here is the data model you have defined, mainly in timeline-types.
• For this layer to be reasonably easy to use by others, that data model needs to be well documented (reference and usage guide).
• We could also easily have the LLM add tests for all the non-layer utility functions. No excuse not to have tests.

If those criteria is met we could land this as an experimental layer (export as _TimelineLayer). I would want to feel that there is some level of commitment to doing the work needed to get this out of experimental status.

In terms of an "API audit" for taking this out of experimental status.

• TimelineLayer is probably not the best name as this module will grow to contain a lot of timeline related layers.
• this is a layer focused around a specific data model (tracks?) and perhaps could be named accordingly (TrackLayer).
• the layer is quite specialized / omposite (axis + multiple lines of tracks) maybe composable pieces could also be offered?
• There is also some overlap with the existing time axis functionality in the timeline-layers module. I am not sure if either is better or if they could be unified, but it should be looked into.

[charlieforward9]

Superseded by #517, which rewrote this based on ib's review feedback. All work from #517 has been applied to dev/timeline-layers in #544 — authorship preserved via git format-patch | git am. Closing in favour of the cleaner implementation.