💡 Yield Overrides

Suggestion

🔍 Search Terms

yield, any, generator, saga

✅ Viability Checklist

My suggestion meets these guidelines:

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
• This feature would agree with the rest of TypeScript's Design Goals.

⭐ Suggestion

A new YieldType builtin generic type would instruct TypeScript to ignore the actual generator type in a yield expression, and to instead use whatever is used as generic parameter. The following would thus be true:

declare const val: YieldType<boolean>;

function* generator() {
  const res = yield val;
  assertType<res, boolean>();
}

📃 Motivating Example

Imagine you define an API where the user provides a generator and can interact with your application by the mean of "effects". Something akin to this:

run(function* () {
  const counter = yield select(state => state.counter);
});

Under the current model, TypeScript is forced to type counter as any, because in theory the generator runner may return whatever value it wants to the yield expression. It can be somewhat improved by adding an explicit type to the generator, but then all yield expressions will return the same type - which is obviously a problem when doing multiple select calls, each returning a different value type:

run(function* (): Generator<any, any, number | string> {
  const counter = yield select(state => state.counter);
  const firstName = yield select(state => state.firstName);
});

Not only does it prevent return type inference and yield value checks, but it also unnecessarily widens the type of both counter and firstName into number | string. The alternative is to write the expressed values at callsite:

run(function* () {
  const counter: number = yield select(state => state.counter);
  const firstName: string = yield select(state => state.firstName);
});

But it then requires the user code to have an explicit requirement on the exact types, which prevents accessing various refactoring tools and generally leads to worse UX (after all that's why TS has type inference in the first place). The last option is to change the API:

run(function* () {
  const counter = yield* selectS(state => state.counter);
  const firstName = yield* selectS(state => state.firstName);
});

By using a select variant supporting yield*, library code would be able to define a return type that TS would be able to use. However, it requires all libraries to adopt a non-idiomatic runtime pattern just for the sake of TypeScript, which is especially problematic considering that it would lead to worse performances.

The main point is that in all those cases, the library code already knows what's the value returned by the yield select(...) expression. All we need is a way to transmit this information to TypeScript.

💻 Use Cases

Redux-Saga (21.5K ⭐, 6 years old)

The redux-saga library heavily use generators (there are various reasons why async/await isn't enough, you can see them here). As a result, its collection of effects are all typed as any, leaving their users mostly unprotected on segments of code that would significantly benefit from types (for instance the select utility mentioned above can return any state slice from a larger one - typing the return as any leaves the door open to refactoring mistakes, typos, etc).

Additionally, under noImplicitAny, TS will put red underline on the whole select call, hiding important errors that could arise within the selector itself. In some of my own application files, about a third of the lines have red squiggles because of this issue:

MobX (23.8K ⭐)

https://mobx.js.org/actions.html#using-flow-instead-of-async--await-

Note that the flowResult function is only needed when using TypeScript. Since decorating a method with flow, it will wrap the returned generator in a promise. However, TypeScript isn't aware of that transformation, so flowResult will make sure that TypeScript is aware of that type change.

Others

• Ember Concurrency (663 ⭐)

  Due to limitations in TypeScript's understanding of generator functions, it is not possible to express the relationship between the left and right hand side of a yield expression. As a result, the resulting type of a yield expression inside a task function must be annotated manually:

• Effection (138 ⭐)

• GenSync (29 ⭐)

💻 Try it Out

I've implemented this feature (minus tests, and I'm not a TS contributor so some adjustments may be needed):

https://github.com/microsoft/TypeScript/compare/master...arcanis:mael/yield-override

Here's a playground: Before | After ✨

cc @Andarist

Beginne mit dem YieldType-Vorschlag und dem verlinkten Vergleich der Implementierungen zur Yield-Überschreibung und prüfe anschließend die Generator-Beispiele und Playground-Links im Issue. Bestätige die beabsichtigten inferierten Typen für die gezeigten Yield-Fälle und ermittle die fehlende Testabdeckung; abgeschlossen ist die Aufgabe, wenn das vorgeschlagene Verhalten validiert ist, ohne die JavaScript-Laufzeitausgabe zu ändern.