-
Notifications
You must be signed in to change notification settings - Fork 46.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
Fix react-is memo and lazy type checks #17278
Conversation
This pull request is automatically built and testable in CodeSandbox. To see build info of the built libraries, click here or the icon next to each commit SHA. Latest deployment of this branch, based on commit 3c2b128:
|
@bvaughn have you seen the discussion in #14546? Folks from the ecosystem were unsure whether the current behavior was intentional. But it's been around for long enough that several packages now depend on it. So it might be worth calling this a breaking change regardless of the original design intention. |
Thanks for the pointer, @billyjanitsch. I had not seen that discussion. I noticed this inconsistency while looking at a DevTools display complaint. |
@@ -106,13 +108,15 @@ describe('ReactIs', () => { | |||
|
|||
it('should identify ref forwarding component', () => { | |||
const RefForwardingComponent = React.forwardRef((props, ref) => null); | |||
expect(ReactIs.isValidElementType(RefForwardingComponent)).toBe(true); | |||
expect(ReactIs.typeOf(<RefForwardingComponent />)).toBe(ReactIs.ForwardRef); |
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 noticed an inconsistency here with how typeOf works when we pass a momozied element vs when we pass a ref-forwarding element. More info here #17274 (comment)
I think this PR addresses this inconsistency between the two types, but I'm still curious, what's the intended behavior for typeOf(RefForwardingComponent)
and typeOf(<RefForwardingComponent />)
– should we expect to get back ReactIs.ForwardRef
in both cases? Same question goes for memoized elements/components.
For example:
expect(ReactIs.typeOf(<Memoized />)).toBe(ReactIs.Memo);
expect(ReactIs.typeOf(Memoized)).toBe(ReactIs.Memo);
expect(ReactIs.typeOf(<RefForwardingComponent />)).toBe(ReactIs.ForwardRef);
expect(ReactIs.typeOf(RefForwardingComponent)).toBe(ReactIs.ForwardRef);
The proposed bug fix in #17274 relies on those assertions above being valid.
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 think this PR addresses this inconsistency between the two types, but I'm still curious, what's the intended behavior for typeOf(RefForwardingComponent) and typeOf() – should we expect to get back ReactIs.ForwardRef in both cases?
No. That's the primary purpose of this PR, to not support that use case. The typeOf
methods are meant to look at React element types (e.g. <MyComponent />
or React.createElement(MyComponent)
) not component types (e.g. MyComponent
)
I've seen #17274. I have some draft comments on it but got distracted by this PR first.
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.
Thanks for the clarification @bvaughn! Exactly the answer I was looking for!
I think the
react-is
package is currently a little broken. This packagestypeOf
methods are meant to look at React element types (e.g.<MyComponent />
orReact.createElement(MyComponent)
) not component types (e.g.MyComponent
), but it's inconsistent when it comes to lazy and memo types.This inconsistency can be seen in shallow renderer as well with invariants like this:
Rather than this:
Is this change a bug fix or a breaking change? (Or both?) Let's discuss.
Put another way: