-
Notifications
You must be signed in to change notification settings - Fork 48.8k
[compiler] Expect component props annotations to be potential objects #29866
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Summary: We now expect that candidate components that have Flow or TS type annotations on their first parameters have annotations that are potentially objects--this lets us reject compiling functions that explicitly take e.g. `number` as a parameter. [ghstack-poisoned]
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
Summary: We now expect that candidate components that have Flow or TS type annotations on their first parameters have annotations that are potentially objects--this lets us reject compiling functions that explicitly take e.g. `number` as a parameter. ghstack-source-id: 03622a6 Pull Request resolved: #29866
Comparing: 270229f...2cd0122 Critical size changesIncludes critical production bundles, as well as any change greater than 2%:
Significant size changesIncludes any change greater than 0.2%: Expand to show
|
} else if (params.length === 2) { | ||
// check if second param might be a ref | ||
if (params[1].isIdentifier()) { | ||
const { name } = params[1].node; | ||
return name.includes("ref") || name.includes("Ref"); | ||
return ( | ||
isValidPropsAnnotation(params[0].node.typeAnnotation) && |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i can imagine wanting something different here over time, but given the current logic of the method it makes sense to share. maybe rename to clarify? isValidPropsOrRefAnnotation()
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The annotation check is still applying just to the props in both cases, actually--I've refactored the logic here to make that clearer.
…ial objects" Summary: We now expect that candidate components that have Flow or TS type annotations on their first parameters have annotations that are potentially objects--this lets us reject compiling functions that explicitly take e.g. `number` as a parameter. [ghstack-poisoned]
Summary: We now expect that candidate components that have Flow or TS type annotations on their first parameters have annotations that are potentially objects--this lets us reject compiling functions that explicitly take e.g. `number` as a parameter. ghstack-source-id: cdd0af4 Pull Request resolved: #29866
…ial objects" Summary: We now expect that candidate components that have Flow or TS type annotations on their first parameters have annotations that are potentially objects--this lets us reject compiling functions that explicitly take e.g. `number` as a parameter. [ghstack-poisoned]
Summary: We now expect that candidate components that have Flow or TS type annotations on their first parameters have annotations that are potentially objects--this lets us reject compiling functions that explicitly take e.g. `number` as a parameter. ghstack-source-id: e2c2334 Pull Request resolved: #29866
Summary: We now expect that candidate components that have Flow or TS type annotations on their first parameters have annotations that are potentially objects--this lets us reject compiling functions that explicitly take e.g. `number` as a parameter. ghstack-source-id: e2c2334 Pull Request resolved: #29866
Stack from ghstack (oldest at bottom):
Summary: We now expect that candidate components that have Flow or TS type annotations on their first parameters have annotations that are potentially objects--this lets us reject compiling functions that explicitly take e.g.
number
as a parameter.