These are my types:
export type Mapping =
| {
type: 'ok';
data: Record<string, string>;
}
| {
type: 'error';
data: Error;
};
export type Payload<T> = Extract<Mapping, { type: T }>['data'];
export interface Callback<T> {
(data: Payload<T>): void;
}
export type Store = {
[K in Mapping['type']]: Set<Callback<K>>;
};
This is my code:
const storage: Store = {
ok: new Set(),
error: new Set(),
};
function store<T extends Mapping['type']>(
type: T,
callback: Callback<T>
): void {
storage[type].add(callback);
}
The error I get:
Argument of type 'Callback<T>' is not assignable to parameter of type 'Callback<"ok"> & Callback<"error">'.
Type 'Callback<T>' is not assignable to type 'Callback<"ok">'.
Types of parameters 'data' and 'data' are incompatible.
Type 'Record<string, string>' is not assignable to type 'Payload<T>'.
Type 'Record<string, string>' is not assignable to type 'Extract<{ type: "error"; data: Error; }, { type: T; }>["data"]'.
Type 'Record<string, string>' is missing the following properties from type 'Error': name, messagets(2345)
I want to achieve, that if a callback is stored in either storage.ok or storage.error each of them can deal with the correct parameter type. So I tried to use conditional types to add more options for the callback parameter types easily. I think the error is in 'Callback<"ok"> & Callback<"error">' because it shouldn't be an intersection. But where is the error? The storage has the correct type:
type Store = {
error: Set<Callback<"error">>;
ok: Set<Callback<"ok">>;
}
Edit: The problem comes from the .add function:
(method) Set<T>.add(value: Callback<"ok"> & Callback<"error">): Set<Callback<"ok">> | Set<Callback<"error">>
Where comes the & from?
This is a failure of the compiler to perform the higher-order type analysis necessary to verify that what you are doing inside the implementation of store() is safe.
Let's define PickStore<T>, like this:
type PickStore<T extends Mapping['type']> = { [K in T]: Set<Callback<K>> };
This is essentially the same as Pick<Store, T> and therefore a supertype of Store, but the compiler cannot do the higher-order type analysis to verify that. For any specific value of T, the compiler can see that PickStore<T> is a supertype of Store:
const sOk: PickStore<"ok"> = storage; // okay
const sError: PickStore<"error"> = storage; // okay
const sBoth: PickStore<"ok" | "error"> = storage; // okay
const sNeither: PickStore<never> = storage; // okay
But when you try to do the same for a generic T, the compiler balks:
function test<T extends Mapping['type']>() {
const sT: PickStore<T> = storage; // error!
// Type 'Store' is not assignable to type 'PickStore<T>'
}
And this is your problem. If you could widen storage to PickStore<T> inside of the store function, the compiler would be able to see that storage[type] is of type Set<Callback<T>>, and therefore you'd be able to add() the callback parameter with no issue.
Instead, the compiler only understands that storage[type] is assignable to the union Set<Callback<"ok">> | Set<Callback<"error">. This is true, but not specific enough for your purposes. The correlation between storage[type] and callback is lost. (See microsoft/TypeScript#30581 for issues surrounding the compiler's inability to keep track of the correlation in type between several values.) So the add() method is seen as the union of two function types. And, when you call a union of function types, the compiler requires the intersection of its parameters, to guarantee type safety. (If you know that you have a function that's either an X-taker or a Y-taker but you're not sure which, you'd better give it an X & Y to be safe.)
I'd recommend that, in cases like this where the compiler is unable to verify some higher-order type analysis, you use a type assertion to just tell the compiler that what you're doing is safe. This shifts the burden of guaranteeing safety from the compiler to you, so you should be careful. Anyway it could look like this:
function store<T extends Mapping['type']>(
type: T,
callback: Callback<T>
): void {
(storage as any as PickStore<T>)[type].add(callback);
}
Here we've just asserted to the compiler that storage can be treated like a PickStore<T> (and we need the intermediate assertion through unknown or any because the compiler really has trouble with the relationship). After that hurdle, the rest of the line goes through without a problem.