fix: recursive T for WritableDraft#1197
Conversation
Pull Request Test Coverage Report for Build 20424663455Details
💛 - Coveralls |
|
Looks great, thanks! |
|
🎉 This PR is included in version 11.1.3 🎉 The release is available on: Your semantic-release bot 📦🚀 |
|
Looks like this change is causing the following code to fail: function Test<A>() {
produce(
(draft) => {
draft.prop = undefined; // <- type error here
},
{ prop: undefined as undefined | A },
);
}Type error on indicated line:
|
I can reproduce it. It seems like the type cannot be resolved partially like this. Is there a particular use case for this? Is there a reason to declare the type like this rather than as a whole like: function Test<A extends { prop: undefined }>() {
produce(
(draft) => {
draft.prop = undefined;
},
{ prop: undefined } as A,
);
} |
|
My full code is more like this: function MultiLineChart<A extends TDatum<{}>>(props: Props<A>) {
const [state, mutate] = useImmer({
hovered: undefined as undefined | A,
});
const resetHover = React.useCallback(() => {
mutate((draft) => {
draft.hovered = undefined; // <- type error here
});
}, [mutate]);
}Interestingly, the following (which is quite close to your code) also errors: function Test<A>() {
type S = { prop: undefined | A }
produce(
(draft) => {
draft.prop = undefined; // <- type error here
},
{ prop: undefined } as S,
);
} |
|
The issue is I have a fix to defer the analysis. Let me create a PR. |
This contains a proper fix for #990
Added tests for the type check.
Included #1196 as I don't want to see the type errors in the tests.