Feat: VisualizationSpec<MyDataType>

• Check for duplicate issues. Please file separate requests as separate issues on GitHub. Searched performed:
  • https://github.com/vega/vega/issues?q=sort%3Aupdated-desc%20type%20generic
  • https://github.com/vega/vega/issues?q=sort%3Aupdated-desc%20type%20parameter%20spec%20(state%3Aopen%20OR%20state%3Amerged)
• Clearly describe the goal of the feature request. Why is it needed?
• Describe an envisioned solution. What do you want the new behavior to be?
• If applicable, share mockup images or links to examples illustrating the desired output.
• If applicable, share JSON spec designs for how the behavior would be made available in Vega.

I would love better type safety when working with specs.

For example, I have this spec:

const donationCounts = [{source: "apoc", count: 5}, ...] 
const donationsRawBySourceChart: Spec = {
    $schema: "https://vega.github.io/schema/vega-lite/v5.json",
    data: { values: donationCounts },
    mark: "bar",
    encoding: {
      x: { field: "source", type: "nominal", title: "Source" },
      y: { field: "count", type: "quantitative", title: "Count" },
    },
  };

This only works if the passed donationCounts has the type Array<{source: string, count: number>. If I adjust my upstream data processing to rename source to src, then this will fail at runtime.

I propose an API such as

const donationCounts = [{source: "apoc", count: 5}, ...]
const donationsRawBySourceChart: Spec<typeof donationCounts>  = {
    // ...
}

Then I will get type errors when I change my upstream data source.

It could be implemented as

// The types of data that vega can accept
type VegaRecord = Record<string, string | number | boolean | null | undefined | Date>
type Spec<R extends VegaRecord = VegaRecord>

so that someone could use a plain const mySpec: Spec = {...} without the type param and they don't get any type checking, but it is backward compatible.

What do you think about this? Are there gotchas that I don't see here? Are there other type parameters that we should be thinking about parameterizing over, not just the shape of the data?

If you support it, I can try submitting a PR. I am fairly familiar with TS and typing, but I might need some help getting up to speed with the particulars of this codebase, eg if you point me to where the new tests should go and what in general they should exercise. Thanks!