react
react copied to clipboard
Throw if React and React DOM versions don't match
Throw an error during module initialization if the version of the "react-dom" package does not match the version of "react".
We used to be more relaxed about this, because the "react" package changed so infrequently. However, we now have many more features that rely on an internal protocol between the two packages, including Hooks, Float, and the compiler runtime. So it's important that both packages are versioned in lockstep.
Before this change, a version mismatch would often result in a cryptic internal error with no indication of the root cause.
Instead, we will now compare the versions during module initialization and immediately throw an error to catch mistakes as early as possible and provide a clear error message.
The latest updates on your projects. Learn more about Vercel for Git ↗︎
| Name | Status | Preview | Comments | Updated (UTC) |
|---|---|---|---|---|
| react-compiler-playground | ✅ Ready (Inspect) | Visit Preview | 💬 Add feedback | May 28, 2024 5:59pm |
Comparing: 4ec6a6f71475a6f2fee39a0e604ddbbd2f124164...38bc3c5062f76039a66781ec9df93dd0ee9ab6a8
Critical size changes
Includes critical production bundles, as well as any change greater than 2%:
| Name | +/- | Base | Current | +/- gzip | Base gzip | Current gzip |
|---|---|---|---|---|---|---|
| oss-stable/react-dom/cjs/react-dom.production.js | = | 6.66 kB | 6.66 kB | +0.05% | 1.82 kB | 1.82 kB |
| oss-stable/react-dom/cjs/react-dom-client.production.js | +0.06% | 496.04 kB | 496.36 kB | +0.07% | 88.77 kB | 88.83 kB |
| oss-experimental/react-dom/cjs/react-dom.production.js | = | 6.67 kB | 6.67 kB | = | 1.83 kB | 1.83 kB |
| oss-experimental/react-dom/cjs/react-dom-client.production.js | +0.07% | 500.84 kB | 501.18 kB | +0.08% | 89.46 kB | 89.52 kB |
| facebook-www/ReactDOM-prod.classic.js | +0.05% | 593.48 kB | 593.80 kB | +0.06% | 104.38 kB | 104.44 kB |
| facebook-www/ReactDOM-prod.modern.js | +0.05% | 569.87 kB | 570.18 kB | +0.08% | 100.77 kB | 100.85 kB |
| test_utils/ReactAllWarnings.js | Deleted | 63.82 kB | 0.00 kB | Deleted | 15.95 kB | 0.00 kB |
Significant size changes
Includes any change greater than 0.2%:
Expand to show
Generated by :no_entry_sign: dangerJS against 38bc3c5062f76039a66781ec9df93dd0ee9ab6a8
react-is is another candidate for this. ReactIs.isElement will also not work if you use React 19 with an earlier react-is (like recharts did) or vice versa. The fix is usually to move react-is to peer dependencies so that the app can ensure the version matches.
Weren't we going to delete react-is entirely though? :D
Some design system libraries need at least support for isElement (can be moved to react) and isValidElementType (should be moved to renderers). You oftentimes find APIs were either element types or elements are expected in a prop and these utils help identify what you actually received. Though isElement only makes sense in the context of element introspection (e.g. element.props) or cloneElement. If we remove those APIs, I can't think of use cases for isElement apart from runtime type checking. Still leaves isValidElementType.
React has isValidElement already? https://react.dev/reference/react/isValidElement
Another prominent use case is Jest snapshot testing, as reported in https://github.com/facebook/react/pull/28813#issuecomment-2077326950. A version mismatch might break those tests because they rely on react-is.
Another prominent use case is Jest snapshot testing, as reported in https://github.com/facebook/react/pull/28813#issuecomment-2077326950. A version mismatch might break those because they rely on react-is.
I think what pretty-format needs is an API to get the display name not necessarily an API to change control flow based of the element kind. So for them it seems sufficient if we'd start implementing .displayName on every element type.