[Tracker] View System Improvements

[ibgreen-openai]

Target Use Case

deck view system

A more sophisticated view system could be a powerful addition to deck.gl. Since it is starting to look like we have a long list of ideas around view system improvements, it is probably best to collect them and ensure that any changes we make fit into the bigger picture.

Proposal

Views

Improved declarative support

• Support for calc() expressions?
  • In Infovis, adding synchronized timelines and legend views would benefit from width: 'calc(100% - 250px)' type expressions.
  • It is not hard to implement the CSS spec and handle most of the supported units.

View override logic (declarative)

• Views: ViewState prop override support for object / array values?
  • Views can be declared with props that override viewState. But this does not handle partial overrides like zoom: [2,] or position: [,,10] well.
  • Such props are more common in the non-geospatial view states.

View filtering

• Currently deck.layerFilter has to be a "global" function.

  • Add support for a declarative version, a list or map of strings to include or exclude, a list of regexps etc.

  • Allow layer filters to be specified on views?

  • Allow view filters to be specified on layers?

  • Intuitiveness of filtering API: Filtering can gets stuck on composite layers, preventing actual layers from rendering, not super intuitive. Maybe multiple ways to address this.

    • Perhaps there is a difference in internal composite layers and primary composite layers?

Nesting Layers in Views.

• An alternative to view filtering is to allow layers to be nested in views.

views: [new OrthographicView({layers: ....})]

• LayerGroups? - a problem occurs when wanting to render a group of layers in multiple views. By defining a LayerGroup:

views: [
    new LayerGroup({id: 'group1', layers: [...], 
    new OrthographicView({id: 'view1, layers: 'group1', ....})
]

or

layers: [new LayerGroup({id: 'group1', layers: [...]}),
views: [new OrthographicView({id: 'view1, layers: 'group1', ....})]

View Override logic

• Widgets that manipulate views are really cool. Being able to create a sophisticated configurable UI by just adding a widget is a powerful feature.
• If we allow widgets to override views, should we define a system for that independently of widtets.
• Can we define a view override cycle that is predictable (e.g. Widgets apply their changes in order? can application opt in?, ...)
• Or do we want Widgets to accept views and layer props? If so ,should should we allow views to accept Widgets as children?

ViewState manipulation logic

A number of widgets are implementing hacky ways to manipulate the view state.

• Consolidate this, perhaps first on the WidgetManager, and move such logic out of the widgets.

Controllers

• Boundaries / extents
  • In infovis orhtographic views, defining a world size and preventing the user from panning away from the "world" would be usefl.
• Inertia pans behave poorly when rendering very large datasets. (Likely a bug, not a feature)
  • The timing uses to calculate the inertia seems to assume that the render cycle doesn't exceed its tick, creates a wobbly effect.