[Discussion]: `ViewTypeType` - naming and using deck.gl classes?

[rubenthoms]

I find the naming of the type of the ViewportType property viewType a bit odd. Why not just calling it ViewType instead of ViewTypeType? Also, isn't it weird that it requires a deck.gl class as value? I would prefer a decoupling - make it a union of string literals. There is not even the flexibility to use any view type deck.gl provides, it is a fixed union of pre-selected class types - I only see disadvantages with this pattern. Open for discussion as the title suggests 😃

[hkfb]

I find the naming of the type of the ViewportType property viewType a bit odd. Why not just calling it ViewType instead of ViewTypeType?

Agree, ViewType would be better.

Also, isn't it weird that it requires a deck.gl class as value? I would prefer a decoupling - make it a union of string literals. There is not even the flexibility to use any view type deck.gl provides, it is a fixed union of pre-selected class types - I only see disadvantages with this pattern.

I have to take some blame for this. We have built complex view logic and state into the Map component that we struggle to understand and maintain. Each time a non-layer improvement is made it's added to the Map component.

The orthogonal nature of the Layer class is a better design. Eg. implementing a new layer does not affect any other layer or the Map component or anything else.

The idea behind exposing the View class is to allow more control over View behaviour without adding more complexity to the Map component, by keeping concerns orthogonal.

As you point out it doesn't really work - it's just a fixed union of classes at present. But I'd prefer we fix that to allow any View class, also custom ones.

[w1nklr]

Agreed on the poor name.

The good point is that there are not many usage of it.

Proposal:

• rename current ViewType to ViewClass (or ViewConstructor)
  Only 3 internal occurrences.
• rename ViewTypeType to ViewType and export a deprecated type ViewTypeType = ViewType for backward compatibility (not sure it is used by client code).
  Only 4 occurrences.

[w1nklr]

As you point out it doesn't really work - it's just a fixed union of classes at present. But I'd prefer we fix that to allow any View class, also custom ones.

Could be done using generic functions:

import type { Controller, View } from "@deck.gl/core";

function getViewType<ViewType extend View, ControllerType extends Controller>(
    viewport: ViewportType
): [
    ViewType: ViewType ,
    Controller: ControllerType ,
] {...

I don't know how to handle the interface, though:

export interface ViewportType {
  ...
  viewType?: <how to say that it extends View ?>;
}