Generic Service/Resource types

[bennostein]

This PR adds type parameters to the SkipService and Resource types, allowing to give more precise types and stricter checking that keys/types match between initialData, SkipService#createGraph, and Resource#instantiate.

E.G. where before we had

initialData?: Record<string, Entry<Json, Json>[]>
resources?: Record<string, new (params: Record<string, string>) => Resource>;
createGraph(
  inputCollections: Record<string, EagerCollection<Json, Json>>,
  context: Context,
): Record<string, EagerCollection<Json, Json>>;

and care was required to match up the keys of the various records, as well as the more-precise-than-Json types of keys/values, now you can write something like

type Inputs = { input1 : EagerCollection<K1, V1>, input2: EagerCollection<K2, V2> }
type Outputs = { output1 : EagerCollection<K3, V3>, output2: EagerCollection<K4, V4> }

and define your service as SkipService<Inputs, Outputs> to get static checking that the various records agree and that the keys/values have the right type.

[bennostein]

The one bit I wanted to do but couldn't get to work was to give more precise type bounds than Json on the initialData's keys and values.

Given e.g.

type Inputs = { input1 : EagerCollection<K1, V1>, input2: EagerCollection<K2, V2> }

what I have here (initialData?: { [Prop in keyof Inputs]: Entry<Json, Json>[] };) ensures that initialData has the keys "input1" and "input2" but not that the values conform to K1/V1 and K2/V2.

As far as I can tell in typescript docs, there's no way to access the type arguments of a type so as to map each Inputs[Prop] (which has the form EagerCollection<K, V>) to the corresponding Entry<K, V> type.

But maybe a typescript wizard knows how to do that? @mbouaziz @skiplabsdaniel

[jberdine]

I like this, I think the more informative types improve the understandability of the api meaningfully.

Did you mean to not adapt the database example in a similar way to you did for the sum and sheet ones?

[bennostein]

I like this, I think the more informative types improve the understandability of the api meaningfully.

Did you mean to not adapt the database example in a similar way to you did for the sum and sheet ones?

I skipped it because adapting it doesn't add much in the way of clarity or brevity, and the type inference does fine without annotations. But just added equivalent annotations/type aliases there for consistency

[jberdine]

This LGTM. I have an idea to try for the dissatisfaction you noted with the type of initialData, but no need to block this on that.

[mbouaziz]

I tried with

type InitialData<Inputs extends NamedCollections> = {
  [Name in keyof Inputs]: Inputs[Name] extends EagerCollection<infer K, infer V>
    ? Entry<K, V>[]
    : Entry<Json, Json>[];
};
.
.
.
  initialData?: InitialData<Inputs>;

and it found type errors in the HN example, probably legit

[jberdine]

Yes, that is the approach I am doing right now, and yeah, those type errors look legit.

[jberdine]

I pushed the approach I tried as #503 . It is not exactly the same as Mehdi proposed, in that I tried to avoid conditional types and infer, since I haven't had great experience with them being predictable and reliable. It is more invasive though.