Can't use generic schema type in traits

[tommy-mitchell]

The docs say that traits can be typed with a generic parameter:

koota/README.md

Lines 711 to 727 in 52a79cb

	Traits can have a schema type passed into its generic. This can be useful if the inferred type is not good enough.
	```ts
	type AttackerSchema = {
	continueCombo: boolean | null
	currentStageIndex: number | null
	stages: Array<AttackStage> | null
	startedAt: number | null
	}
	const Attacker = trait<AttackerSchema>({
	continueCombo: null,
	currentStageIndex: null,
	stages: null,
	startedAt: null,
	})
	```

However, this seems to be broken (v0.5.3)¹:

import { trait } from "koota";

type MySchema = {
    foo: number;
    bar: string;
    baz: [number, string];
};

const MyTrait = trait<MySchema>({
//                    ~~~~~~~~  Type 'MySchema' is not assignable to type 'Record<string, never>'
    foo: 0,
    bar: "",
    baz: () => [0, ""],
});

satisfies can't be used as a workaround in this case either, due to objects requiring initializer functions:

const MyTrait = trait({
    foo: 0,
    bar: "",
    baz: () => [0, ""],
//  ~~~  Type '() => (string | number)[]' is not assignable to type '[number, string]'
} satisfies MySchema);

Footnotes

1. TypeScript Playground ↩

[Cosmitar]

apparently there's something with arrays, here is the example from the doc

[tommy-mitchell]

@Cosmitar that Playground link has the same error:

Type 'AttackerSchema' does not satisfy the constraint 'Schema'.
  Type 'AttackerSchema' is not assignable to type 'Record<string, never>'.
    Property 'continueCombo' is incompatible with index signature.
      Type 'boolean | null' is not assignable to type 'never'.
        Type 'null' is not assignable to type 'never'.

[krispya]

You are right this is a sticking point. The problem is that the types need to infer the schema with the callback (so it knows it is not a scalar value) and then when you add your schema it breaks.

// Breaks
type MySchema = {
    foo: number;
    bar: string;
    baz: [number, string];
};

const MyTrait = trait<MySchema>({
//                    ~~~~~~~~  Type 'MySchema' is not assignable to type 'Record<string, never>'
    foo: 0,
    bar: "",
    baz: () => [0, ""],
});

However, this would work.

// Not what you intended but it works
type MySchema = {
    foo: number;
    bar: string;
    // The trait generic expects to see the callback
    baz: () => [number, string];
};

const MyTrait = trait<MySchema>({
    foo: 0,
    bar: "",
    baz: () => [0, ""],
});

Since TS does not allow for me to both infer the generic and accept a user input generic at the same time I am stuck here. One option it export a utility that does the conversion. Would this maybe work for you?

// Schema is a utility that would convert the type to what our internals expect to see
type MySchema = Schema<{
    foo: number;
    bar: string;
    baz: [number, string];
}>;

const MyTrait = trait<MySchema>({
    foo: 0,
    bar: "",
    baz: () => [0, ""],
});

[tommy-mitchell]

I think that would work for my use case!

[Cosmitar]

personally, I prefer type the schema as () => [number, string] so it matches with the initialization. That said, for me it's ok as it is now.

[krispya]

Yeah there are two concepts being merged into one here and times like this the difference becomes a friction. First there is the concept of the schema meaning the structure and type of data. We expect snapshots of the trait to return this and we expect interacting with storage in any way to also adhere to this schema.

And then there is the concept of the schema or record initializer which determines what default values there are and how we should initialize new records for that store.

I am cleverly reducing the API surface by inferring the schema from the initializer. You write this once and you are good to go. But I can understand clearly that in this case Tommy wants to define them separately, at least in types.

Sometimes being too clever gets in the way of understanding but I really like how simple it is to define a trait. I'll think on the best way to bring clarity here.

Thank you for starting this discussion.