-
Notifications
You must be signed in to change notification settings - Fork 47.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
Improve DX when combining react-dom/profiling and schedule/tracking #13605
Conversation
ddb265a
to
ecc6fea
Compare
Hmm. What is the recommendation for using profile mode? Is it to only use profiling bundle of ReactDOM? Or also to use profiling bundle of If profiling needs profiling bundle for Otherwise it's not clear what makes |
Details of bundled changes.Comparing: 7d1169b...1168d34 react-dom
react-art
react-test-renderer
react-reconciler
react-native-renderer
schedule
Generated by 🚫 dangerJS |
Yeah, I agree. First commit was just focused on fixing the runtime error. I'm adding another entry point now to the |
…filing bundle) to error
ecc6fea
to
889a8de
Compare
I was thinking that maybe in this case the error is justified? While the error itself is confusing, you can google it and discover it comes from mixing profiling and non-profiling bundles. Whereas if we don't error, you would just be unaware they're inconsistent? |
I've added a blessed entry-point for production+profiling Verified it works by ejecting a CRA app and modifying the Webpack config to add the following aliases: resolve: {
alias: {
'react-dom': 'react-dom/profiling',
'schedule/tracking': 'schedule/tracking-profiling',
},
} |
That's fair, unless we added a warning– you would only know something was wrong because of the fact that none of your interactions would be tracked. |
I don't feel strongly about this. If you have a strong intuition that one route is better, I'll defer. Reverting my initial commit would certainly be less subtle, and so maybe also less confusing. |
I think my preferred approach would be:
Seems like it would handle all cases and avoid extra code. Invalid mix would crash but it would explain how to fix it. Which you'd probably eventually want to do anyway since otherwise tracking wouldn't work. |
Except for the |
…dom (profiling bundle) to error" This reverts commit 889a8de.
That would be profiling-only, right? So wouldn't need to impact regular production bundle. I think that's acceptable. |
True! |
Okay. I've added an invariant and confirmed that it works with an ejected CRA. Would love input on the error message though. I'm not very good at writing these. |
invariant( | ||
__interactionsRef != null && __interactionsRef.current != null, | ||
"Profiling renderer (e.g. 'react-dom/profiling') cannot be used with non-profiling 'schedule/tracking'. " + | ||
"To fix, alias 'schedule/tracking' to 'schedule/tracking-profiling'.", |
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.
This would be bundler specific and I’m not sure they all use the “alias” wording.
Another thing to consider is that the person seeing this might be unaware that schedule package exists or what it is.
How about
It is not supported to run the profiling version of a renderer (for example, `react-dom/profiling`) without also replacing the `schedule/tracking` module with `schedule/tracking-profiling`. Your bundler might have a setting for aliasing both modules. Learn more at http://fb.me/react-profiling
The link points to a gist explaining how to do it in webpack. Later we change it to point to a blog post.
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 dig it. 👍 Thanks for the ideas Dan.
@@ -168,6 +168,18 @@ let didWarnSetStateChildContext; | |||
let warnAboutUpdateOnUnmounted; | |||
let warnAboutInvalidUpdates; | |||
|
|||
if (enableSchedulerTracking) { | |||
// Provide explicit error message when production+profiling bundle of e.g. react-dom | |||
// Is used with production (non-profiling) bundle of schedule/tracking |
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.
Nit: does this line need to start with capital letter? Made reading the sentence a bit confusing.
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.
No, I can change the comment 😆
…acebook#13605) * Added blessed production+profiling entry point for schedule/tracking * Add invariant when profiling renderer is used with non-profiling schedule/tracking
…acebook#13605) * Added blessed production+profiling entry point for schedule/tracking * Add invariant when profiling renderer is used with non-profiling schedule/tracking
Resolves #13601
In order to be slightly smaller and faster, the
schedule/tracking
production bundle didn't initialize its refs. I hadn't properly considered the use case ofreact-dom/profiling
importing aschedule/tracking
(production, non-profiling) bundle– which runtime errors.The "fix" for this includes:
schedule/tracking
production+profiling bundle.889a8de: Changeschedule/tracking
production bundle to also initialize the refs soreact-dom
production bundle wont' RTE. This should not impactreact-dom
production bundle because it doesn't even requireschedule/tracking
.invariant
to protect against areact-dom
profiling bundle being used with a non-profilingschedule/tracking