-
-
Notifications
You must be signed in to change notification settings - Fork 2.8k
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
[New] prefer-read-only-props
, prop-types
, component detection: allow components to be async functions
#3654
Conversation
…low components to be async functions
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #3654 +/- ##
==========================================
- Coverage 97.65% 97.65% -0.01%
==========================================
Files 132 132
Lines 9378 9375 -3
Branches 3433 3432 -1
==========================================
- Hits 9158 9155 -3
Misses 220 220 ☔ View full report in Codecov by Sentry. |
@ljharb One thing that comes to my mind is checking the return statement of the function, since it should return null or a JSX Element to be valid, but I have no idea how feasible this is. As you mentioned, async generator functions ( |
As long as the proper test cases are in the PR, it's ok if they're failing; I can try to bring it over the finish line. |
Note that react components as of v16 can return almost anything - including an array of renderable things - so checking the return statement is no longer a disqualifier. |
Okay, I updated the PR to allow only async generators. |
Hello @ljharb I see that 1 check is failing, if I am not mistaken due to a lower code coverage percentage. |
prefer-read-only-props
, prop-types
, component detection: allow components to be async functions
Hello @ljharb Hope you're doing well! |
@pnodet i don't have a timeline, but I'll try to do it soon. |
React introduced server components, now async functions can be components.
Closes #3653