Expanding the scope of store key restrictions with a flexible late-binding function

Question

Expanding the scope of store key restrictions with a flexible late-binding function

Within the code snippet below, a

StoreOp<"vanilla">

is intended to function on a Store with "vanilla" as a flag, along with other flags. Unfortunately, the current constraints are incorrect, restricting a

StoreOp<"vanilla">

to only operate on a

FlagStore<"vanilla">

instead of also allowing it to work on a

FlagStore<"vanilla", "chocolate">

.

The calls to setVanilla and setChocolate are generating errors due to this mismatch. A successful resolution would eliminate these errors, as noted in the comments against the final four lines of code.

An example of the error message displayed is...

Argument of type 'Store<{ vanilla: boolean; chocolate: boolean; raspberry: boolean; }>' is not assignable to parameter of type 'FlagStore<"vanilla">'.
  Types of property 'write' are incompatible.

I am seeking guidance on how to define constraints for the generic function type StoreOp, and the corresponding factory function createSetterOp, so that any Store containing the Operated flags AMONG its Stored flags is deemed a valid late-bound argument for the StoreOp. Presently, the constraint

S extends FlagStore<Operated>

is set in the wrong direction, and I am struggling to determine how to specify it in the opposite direction - where S includes Operated and additional flags.

A StoreOp should be able to rely on each of its Operated flags having a respective boolean value in the store, without being concerned about the availability of other flags. In defining the generic function StoreOp, Operated should be assignable to

Stored</code, rather than vice versa. I anticipate the late-bound typing of the generic function against the actual store will ensure that an edit made by a <code>StoreOp

implementation aligns with the Store's type, triggering a compiler error if it fails to copy over the other (unknown) flags when updating the store.

My broader API requires inference from both the Stored flags and the Operated flags to dictate other typings. The crux lies in expanding the StoreOp type effectively.

You can find the code below in this Typescript Playground

typescript variable-assignment typescript-generics extends

Answer 1

Answer №1

Despite the absence of direct support in TypeScript for a lower bound constraint as requested on this issue, there is a workaround using the union operator. Instead of V extends Flag super T, you can use T | U where U extends Flag. Take a look at how StoreOp should be defined:

type StoreOp<T extends Flag> =
  <U extends Flag>(store: FlagStore<T | U>) => void;

The problem arises when assigning a StoreOp<X> to a StoreOp<Y> even if X and Y are incompatible due to a compiler shortcut that assumes StoreOp<T> is bivariant in

T</code instead of <em>invariant</em>. This can be addressed with variance annotations as shown below:</p>
<pre><code>type StoreOp<in out T extends Flag> =
  <U extends Flag>(store: FlagStore<T | U>) => void;

You can modify the modifiers to achieve covariance or contravariance. The key is to guide the compiler correctly when comparing different instances of StoreOp.

Let's put it into practice:

setVanilla(manyStore); // valid
setVanilla(fewStore); // valid
setChocolate(manyStore); // valid
setChocolate(fewStore); // results in an error

// error anticipated
const shouldFail: StoreOp<"chocolate"> = setVanilla;

Looks like everything is working as expected!

Here's the link to test the code yourself.

Answer 2

Despite the absence of direct support in TypeScript for a lower bound constraint as requested on this issue, there is a workaround using the union operator. Instead of V extends Flag super T, you can use T | U where U extends Flag. Take a look at how StoreOp should be defined:

type StoreOp<T extends Flag> =
  <U extends Flag>(store: FlagStore<T | U>) => void;

The problem arises when assigning a StoreOp<X> to a StoreOp<Y> even if X and Y are incompatible due to a compiler shortcut that assumes StoreOp<T> is bivariant in

T</code instead of <em>invariant</em>. This can be addressed with variance annotations as shown below:</p>
<pre><code>type StoreOp<in out T extends Flag> =
  <U extends Flag>(store: FlagStore<T | U>) => void;

You can modify the modifiers to achieve covariance or contravariance. The key is to guide the compiler correctly when comparing different instances of StoreOp.

Let's put it into practice:

setVanilla(manyStore); // valid
setVanilla(fewStore); // valid
setChocolate(manyStore); // valid
setChocolate(fewStore); // results in an error

// error anticipated
const shouldFail: StoreOp<"chocolate"> = setVanilla;

Looks like everything is working as expected!

Here's the link to test the code yourself.

Expanding the scope of store key restrictions with a flexible late-binding function

Answer №1

Similar questions

When implementing useReducer with TypeScript, the error "Argument of type '(type, action) => { state: (...}' is not assignable to parameter of type 'ReducerWithoutAction<any>'" may occur

Error: An unexpected token < was caught in the TypeScript Express code

What benefits does redux-thunk offer?

Timestamps are no longer recognized in Highstock charts once data has been added

Refreshing functional component upon change in property of different class [MVVM]

The Challenge of Iterating Through an Array of Objects in Angular Components using TypeScript

Neglectful TypeScript null checks overlooking array.length verification

Tips for specifying which project starts the setup process in Playwright

"The Promise of Generics in Typescript: Unlocking Unique Return

Generating dynamic types based on conditions in TypeScript

Unpacking a props object results in an undefined value

What sets apart using (@Inject(Http) http: Http) from not using it?

Tips for retrieving a reactive variable from a setup() method?

What is the purpose of manually creating the vscode.d.ts file in the vscode source code?

Tips for programmatically focusing on a v-textarea using Vuetify and TypeScript

What is the process of incorporating a JavaScript node module into TypeScript?

Using Angular, a class can serve as a method within another class

What's the best way to replicate a specific effect across multiple fields using just a single eye button?

Adding conditional props to a style object in @emotion/react with Typescript is as simple as utilizing a ternary operator

What is the correct way to type this object conversion?