Repository navigation
Second use of type guard produces different result #52232
Description
Bug Report
🔎 Search Terms
react child.props unknown
ts 18046 reading child prop
typescript user defined type guard fails after second time
🕗 Version & Regression Information
Upgrading project to 4.9.4 from 4.2.4.
- This changed between versions 4.7 and 4.8.2. I went through until I found where this changed.
⏯ Playground Link
Playground link with relevant code
💻 Code
import React from 'react';
const childArray = [] as any as React.ReactNode[];
childArray.forEach(child => {
const children = React.isValidElement(child) && child.props.children;
// child.props is of type "unknown" error. If we swap this line with
// the one above it, the error moves to the other line of code. Only
// the line where we read child.props does it correctly type the value.
// Multiple reads of child.props on the first line also work fine.
const propsValue = React.isValidElement(child) && child.props.value;
});
// Wrapping the reads with one call to isValidElement will type correctly
childArray.forEach(child => {
if (React.isValidElement(child)) {
// no errors here
const children = child.props.children;
const propsValue = child.props.value;
}
});
childArray.forEach(child => {
const isValid = React.isValidElement(child);
if (isValid) {
const children = child.props.children;
const propsValue = child.props.value;
// after reading the isValid value a second time, child.props is
// again unknown
} else if (isValid) {
const children = child.props.children;
const propsValue = child.props.value;
}
});🙁 Actual behavior
All examples fail after the second read of a type guard on props, whether re-running the function or just reading the variable.
🙂 Expected behavior
Should behave consistently no matter if this is the first or second read of the type guard.
Activity
RyanCavanaugh commentedon Jan 14, 2023
😱
Anyone interested in trying to produce a repro that doesn't need the entire React typings?
tjjfvi commentedon Jan 14, 2023
Here you go!
RyanCavanaugh commentedon Jan 14, 2023
Stellar, thank you!
RyanCavanaugh commentedon Jan 14, 2023
typescript-bot commentedon Jan 14, 2023
The change between origin/release-4.7 and origin/release-4.8 occurred at a4507c9.
RyanCavanaugh commentedon Jan 14, 2023
Root cause is #50044, cc Anders Hejlsberg (@ahejlsberg)
Possible fixes:
function isValidElement<T = any>to preserve the old behavior with zero candidates. Basically the generic default here and onReactElementshould really matchfunction isValidElement<T = any>(object: ReactNode<T>)so that a zero-candidate inference doesn't occurahejlsberg commentedon Jan 17, 2023
Part of this issue is an effect of #50044. With that PR we consistently favor the asserted type in a type predicate narrowing, meaning that
ReactElement<any>narrows toReactElement<unknown>, which makes a property access likeobj.props.bazan error. That is working as intended.There isn't an error on the first property access is because the
ReactNodetype includesSomeReactElementWithFooin a union type that isn't subject to subtype reduction (explicitly written union types aren't subtype reduced an thus may contain redundant constituents). Following the firstisValidElement(obj)check, the type ofobjis narrowed toReactElement<unknown> | SomeReactElementWithFoo, and the property access succeeds becauseSomeReactElementWithFoois still in the type. But control flow analysis then performs subtype reduction of the two possible control flows and we end up eliminatingSomeReactElementWithFoo. Thereafter, the property access becomes an error.So, overall this is working as intended, though I'll admit it's subtle.
ahejlsberg commentedon Jan 17, 2023
BTW, I'll second Ryan Cavanaugh (@RyanCavanaugh)'s suggested fix:
jasonaden commentedon Jan 19, 2023
Thanks for checking into this. I'll PR against React library to land a fix.
RyanCavanaugh commentedon Jan 19, 2023
I'm not quite willing to sign on to "intended" (lol) but given that the UDTG definition is extremely suspect I think we can call this "best we can do for now". Hopefully one day we can solve the any/unknown subtyping dilemma.