egghead.io lesson 12: Immer + TypeScript
Hosted on egghead.io
The Immer package ships with type definitions inside the package, which should be picked up by TypeScript and Flow out of the box and without further configuration.
The TypeScript typings automatically remove
readonly modifiers from your draft types and return a value that matches your original type. See this practical example:
This ensures that the only place you can modify your state is in your produce callbacks. It even works recursively and with
- Always define your states as
readonlyas much as possible. This best reflects the mental model and reality, since Immer will freeze all its returned values.
- You can use the utility type
Immutableto recursively make an entire type tree read-only, e.g.:
type ReadonlyState = Immutable<State>.
- Immer won't automatically wrap all returned types in
Immutableif the original type of the input state wasn't immutable. This is to make sure it doesn't break code bases that don't use immutable types.
We try to inference as much as possible. So if a curried producer is created and directly passed to another function, we can infer the type from there. This works well with for example React:
When a curried producer isn't passed directly somewhere else, Immer can infer the state type from the draft argument. For example when doing the following:
Note that we did wrap the
Todo type of the
draft argument with
Todo is a readonly type. For non-readonly types this isn't needed.
For the returned curried function,
toggler, We will narrow the input type to
Immutable<Todo>, so that even though
Todo is a mutable type, we will still accept an immutable todo as input argument to
In contrast, Immer will widen the output type of the curried function to
Writable<Todo>, to make sure it's output state is also assignable to variables that are not explictly typed to be immutable.
This type narrowing / widening behavior might be unwelcome, maybe even for the simpe reason that it results in quite noisy types. So we recommend to specify the generic state type for curried producers instead, in cases where it cannot be inferred directly, like
toggler above. By doing so the automatic output widening / input narrowing will be skipped. However, the
draft argument itself will still be inferred to be a writable
However, in case the curried producer is defined with an initial state, Immer can infer the state type from the initial state, so in that case the generic doesn't need to be specified either:
In case the toggler has no initial state, and it has curried arguments, and you set the state generic explicitly, then type of any additional arguments should be defined explicitly as a tuple type as well:
The types inside and outside a
produce can be conceptually the same, but from a practical perspective different. For example, the
State in the examples above should be considered immutable outside
produce, but mutable inside
Sometimes this leads to practical conflicts. Take the following example:
This will generate the error:
The reason for this error is that we assign our read only, immutable array to our draft, which expects a mutable type, with methods like
.push etc etc. As far as TS is concerned, those are not exposed from our original
State. To hint TypeScript that we want to upcast the collection here to a mutable array for draft purposes, we can use the utility
draft.finishedTodos = castDraft(state.unfinishedTodos) will make the error disappear.
There is also the utility
castImmutable, in case you ever need to achieve the opposite. Note that these utilities are for all practical purposes no-ops, they will just return their original value.
Tip: You can combine
produce to type the return type of
produce as something immutable, even when the original state was mutable:
Note: Immer v5.3+ supports TypeScript v3.7+ only.
Note: Immer v3.0+ supports TypeScript v3.4+ only.
Note: Immer v1.9+ supports TypeScript v3.1+ only.
Note: Flow support might be removed in future versions and we recommend TypeScript