Should custom layers allow any data type?

[ssaornil]

When using danmarshall/deckgl-typings the Data type for a collection didn't need to be an iterable https://github.com/danmarshall/deckgl-typings/blob/0e8e37c0ce2dac5b158bd570c7aaeeff681c5942/deck.gl__core/index.d.ts#L1041

With the typed version of deck.gl that is not the case. https://github.com/visgl/deck.gl/blob/master/modules/core/src/types/layer-props.ts#L85

I am now upgrading and trying to use the deck types instead and my data for my custom composite layers are indexed collections so it is giving me some pain.

Before I invest time in transforming that input data type, would it make sense to allow the data prop to be any type for custom composite layers? One of the main reasons I have for creating a custom layer is to perform some data processing and transformation. I would prefer to do it within the layer than outside of it.

[Pessimistress]

In 8.8 the data prop is allowed to be any non-iterable as long as it contains a length: number field.

Technically CompositeLayer's data can be any. Unfortunately, the current type implementation makes it difficult to overwrite any prop type from the parent class. There are some discussions here and here. TLDR; if we allow overrides from derivative classes then we lose type check in the base layer. Ultimately TypeScript is not really designed to handle the kind of layer inheritance hierarchy that we have. This is a drawback when trying to retrofit TypeScript onto a complex code base.

We may be able to fix this by making a special case when forwarding props from CompositeLayer and Layer. My intuition is that any attempt at this will introduce more complexity to typing layer classes. :(

@zbigg

[ibgreen]

My 2 cents, without digging in to the details, is to be careful here. I am also not a fan of adding complex, parametrized types in order to handle a fairly special case.

If we add type safety for some corner cases, at the cost of a code base that is significantly harder to understand for a non-typescript-expert, I am not sure it we are making the right tradeoff.

Making efforts to maintain a readable, easy-to-understand code base has always been a priority for the deck.gl code base.

How bad is the alternative? Is it for instance a case where the writer of the subclass (who knows what they are doing) must add one // @ts-ignore-error when they call super? If so, maybe that is not so bad in comparison.