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 |
| // We expect 1 error. | ||
| await render(<App />, 1); | ||
| }, | ||
| ); |
There was a problem hiding this comment.
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.
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.
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 asContextso nothing special is handled.After: When
Context.Consumeris used the at the beginning of reconciliation, the fiber is given the_contextfield 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
Contextwe check if_contextfield 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 asContextso 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.