-
Notifications
You must be signed in to change notification settings - Fork 48.2k
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
Show deprecated context object warnings usage in ReactDOM server #14033
Conversation
Details of bundled changes.Comparing: 8eca0ef...65cab46 react-dom
scheduler
Generated by 🚫 dangerJS |
I'm trying to follow the changes as a follow up to PR #13829 |
Looks like you need to run |
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 looks okay
// We expect 1 error. | ||
await render(<App />, 1); | ||
}, | ||
); |
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.
These tests seem a little weak since they don't assert on what the error message actually is. I guess ReactDOMServerIntegrationTestUtils
doesn't provide a mechanism to do this currently, but it seems like it would be an improvement if e.g. expectErrors
supported either a number or an error of partial messages.
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 agree, this is something I stumbled into. It can be something we do as a follow up as I know that we're planning on making some changes to the server renderer and this might flow nicely with that workload.
const consumer: ReactConsumer<any> = (nextChild: any); | ||
const nextProps: any = consumer.props; | ||
const nextValue = consumer.type._currentValue; | ||
let reactContext: ReactContext<any> = (nextChild: any).type; |
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.
Seems a little odd that we're any-casting something that explicitly might not be ReactContext
to that type for DEV mode.
…ebook#14033) * Applies context object warnings to ReactDOM server
…ebook#14033) * Applies context object warnings to ReactDOM server
This is a follow up to #13829.
This PR adds deprecated context object usage warnings that mirror the same warnings as in #13829. Specifically:
dev when using consumer:
Before: When using
Context.Consumer
, it's the same asContext
so nothing special is handled.After: When
Context.Consumer
is used the at the beginning of reconciliation, the fiber is given the_context
field from theConsumer
, that references toContext
.dev when using context:
Before: When using
Context
, it's the same as the previous case (but the wrong behaviour).After: When
Context
we check if_context
field exists on it (which we added to the new proxy object) and because it won't (only Context.Consumer does) we trigger a new warning.prod when using consumer:
Context.Consumer
, it's the same asContext
so nothing special is handled.prod when using context:
Context
, it's the same as the previous case so nothing special is handled.This behaviour is backwards compatible with previous versions of React.