Open Andarist opened 1 year ago
I understand this this particular example looks complex
A less complex example for novices such as myself would be appreciated, lol đ°. Something that would make sense in a blog post, for example, tends to be pretty compelling.
How about this one:
type StateType = "parallel" | "final" | "compound" | "atomic";
type StateSchema = Record<string, { type: StateType }>;
declare function createMachine<T extends StateSchema>(
obj: {
[K in keyof T]: {
type: T[K]["type"];
} & (T[K]["type"] extends "final"
? {}
: {
on: Record<string, keyof T>;
});
}
): T;
In here, I restrict the presence of on
property within the "current" state - it shouldn't be available on a state of type 'final'
. I'd like for this reverse mapped type to be inferred as the same type that I provide explicitly here
@RyanCavanaugh I believe that this proposal has a lot of potential to simplify types of some popular libraries, like React Query, Redux Toolkit, and more.
The most recent example of problems that people struggle with can be found in this thread. At the moment, they resort to recursive conditional types but this technique fails to infer unannotated arguments within tuple elements - this is something that works just great with reverse mapped types. The problem is though that they need to infer multiple different things per tuple element and that isn't possible right now - but it could be, with this proposal implemented.
@RyanCavanaugh maybe I can provide a "real life" example of where this can be useful - from Redux Toolkit.
At the moment, it kinda works, but our types to enforce this are pretty wonky; there is not much inference, and we already had the case where a TS PR had to be rolled back until we could figure out a fix. Better support from TS would be highly appreciated! Playground Link
import { createSlice, PayloadAction } from "@reduxjs/toolkit";
interface State {
foo: string;
}
const slice = createSlice({
name: "someSlice",
initialState: {
foo: "bar",
} satisfies State as State,
reducers: {
// simple notation - this is easy for us
simpleReducer(state, action: PayloadAction<string>) {
state.foo = action.payload;
},
// notation that is "split" into a `prepare` function that creates the `action` that will be passed into `reducer`
reducerWithPrepareNotation: {
reducer(state, action: PayloadAction<string>) {
state.foo = action.payload;
},
prepare(char: string, repeats: number) {
return { payload: char.repeat(repeats) };
},
},
// another version with a different action type - but still matching between `reducer` and `prepare`
reducerWithAnotherPrepareNotation: {
reducer(state, action: PayloadAction<number>) {
state.foo = state.foo.slice(0, action.payload);
},
prepare(char: string, repeats: number) {
return { payload: repeats * char.length };
},
},
/* uncomment to see the error. This is a "wrong user code" that we want to protect against.
invalidReducerWithPrepareNotation: {
reducer(state, action: PayloadAction<string>) {
state.foo = action.payload
},
// @ts-expect-error we want this to error, because it returns { payload: number }, while the `reducer` above requires { payload: string } as second argument
prepare(char: string, repeats: number) {
return { payload: repeats * char.length }
}
},
*/
},
});
{
const _expectType: (payload: string) => PayloadAction<string> =
slice.actions.simpleReducer;
}
{
const _expectType: (char: string, repeats: number) => PayloadAction<string> =
slice.actions.reducerWithPrepareNotation;
}
{
const _expectType: (char: string, repeats: number) => PayloadAction<number> =
slice.actions.reducerWithAnotherPrepareNotation;
}
Our problem here is to get consistency within that reducerWithPrepareNotation
definition while also being consistent within reducerWithAnotherPrepareNotation
, but having different types between both of them.
I was experimenting with https://github.com/microsoft/TypeScript/pull/52062 and RTK types. While this PR doesn't implement this feature request here - it already allows me to do quite a lot for some libraries.
I managed to implement most of the requirements mentioned by @phryneas. I could have made a mistake here or there - but my experiment probably could have been refined with someone more intimate with RTK.
) => Parameters
: never
: never;
};
};
interface State {
foo: string;
}
const slice = createSlice({
name: "someSlice",
initialState: {
foo: "bar",
} satisfies State as State,
reducers: {
simpleReducer: (state, action: PayloadAction
What I've learned in the process is that this feature request here would make it easier to write such types (since we would be able to "merge" TPrepareMap
with TReducerMap
) but it wouldn't be able to replace their "validation" logic without #52062.
The main problem is that TS often doesn't infer to type params within intersected types - which I think makes sense in most cases. So to create the return type we actually need to infer separately to TFullReducers
and that can only be done using intersections and the logic from #52062.
Suggestion
đ Search Terms
inference, reverse mapped types, schema
â Viability Checklist
My suggestion meets these guidelines:
â Suggestion
It would be great if TypeScript could take into account concrete index types when inferring reverse mapped types.
Reverse mapped types are a great technique that allows us to create dependencies between properties in complex objects.
For example, in here we can validate what strings can be used as
initial
property on any given level of this object. We can also "target" sibling keys (from the parent object) within theon
property.This type of inference starts to break though once we add a constraint to
T
in order to access some of its known properties upfront. Things likeT[K]["type"]
preventsT
from being inferred because the implemented "pattern matching" isn't handling this case and without a special handling this introduces, sort of, a circularity problem. Note how this doesn't infer properly based on the given argument: hereI think there is a great potential here if we'd consider those accessed while inferring.
đ Motivating Example
Old example
I understand this this particular example looks complex. I'm merely using it as a motivating example to showcase what I'm trying to do: - limit what kind of values are possible for the `initial` property (based on the keys of the inferred object) - make this property available conditionally - it shouldn't be allowed where the `type` property of the "current" object is `'paralel'` A way simpler demo of the inference algorithm shortcomings for this kind of things has been mentioned above ([playground link](https://www.typescriptlang.org/play?ts=5.0.0-dev.20221121#code/C4TwDgpgBAysCGwIBVzQLxQERngJ3gBtCJCsoAfbAMwEsA7I8qrAYwHsBbMdgV3oAmzbIi61WWANwAoUJFgIkMVgAsIneFEwAlCBzwCAPAGdgeBgHMANFADeUORABcCxCjRQAvgD4Z0gXqE+NDU-KzAtOz0UKx4EG4AsvCqDBCGyFAQAB5IgsauSqrq8N4AFNJQUOwARgBWLrYVlVAA2gDSUAxQANYQIOzUUMgAug1NzQ5oLsjtwy1YjljDMhOeK17SAJTTfhz0plBxxryEwFoxcYnJKqmljZXU7OxjE44uWKKc4lhWTZ6-nk2fiOJ2AMgA9OCoAA9AD80iAA)) ```ts type IsNeverđť Use Cases
Schema-like APIs could leverage this a ton:
Implementation
I'm willing to work on the implementation but I could use help with figuring out the exact constraints of the algorithm.
I've created locally a promising spike by gathering potential properties on the inference info when the
objectType
has available index info in this inference round (here) and creating a type out of those when there is no other candidate for it here