sebmarkbageandFacebook GitHub Bot
0f134fd091
Summary: Changelog: [Internal] Along with all the places using it like the `_debugSource` on Fiber. This still lets them be passed into `createElement` (and JSX dev runtime) since those can still be used in existing already compiled code and we don't want that to start spreading to DOM attributes. We used to have a DEV mode that compiles the source location of JSX into the compiled output. This was nice because we could get the actual call site of the JSX (instead of just somewhere in the component). It had a bunch of issues though: - It only works with JSX. - The way this source location is compiled is different in all the pipelines along the way. It relies on this transform being first and the source location we want to extract but it doesn't get preserved along source maps and don't have a way to be connected to the source hosted by the source maps. Ideally it should just use the mechanism other source maps use. - Since it's expensive it only works in DEV so if it's used for component stacks it would vary between dev and prod. - It only captures the callsite of the JSX and not the stack between the component and that callsite. In the happy case it's in the component but not always. Instead, we have another zero-cost trick to extract the call site of each component lazily only if it's needed. This ensures that component stacks are the same in DEV and PROD. At the cost of worse line number information. The better way to get the JSX call site would be to get it from `new Error()` or `console.createTask()` inside the JSX runtime which can capture the whole stack in a consistent way with other source mappings. We might explore that in the future. This removes source location info from React DevTools and React Native Inspector. The "jump to source code" feature or inspection can be made lazy instead by invoking the lazy component stack frame generation. That way it can be made to work in prod too. The filtering based on file path is a bit trickier. When redesigned this UI should ideally also account for more than one stack frame. With this change the DEV only Babel transforms are effectively deprecated since they're not necessary for anything. DiffTrain build for commit https://github.com/facebook/react/commit/37d901e2b81e12d40df7012c6f8681b8272d2555. Reviewed By: kassens Differential Revision: D53543159 Pulled By: tyao1 fbshipit-source-id: 8e5509a16ea8d3234881e2305149326fb31e3845
React & React Native Versions
This page describes how React and React Native versions interact each other. The version alignment between the two frameworks relies on two synchronization points:
- The versions in the
package.jsonof the new app template. For example for React Native 0.68.1 the versions are aligned as follows:
"dependencies": {
"react": "17.0.2",
"react-native": "0.68.1"
},
- The React renderers shipped with React Native inside this folder, the ./Libraries/Renderer folder, of React Native.
This practically means that you can't bump the version of React in your package.json to a later version,
as you will still be using the older renderer from the folder mentioned above. Bumping the react version in your package.json will lead to unexpected behaviors.
For the sake of React 18, the first version of React Native compatible with React 18 is 0.69.0. Users on React Native 0.68.0 and previous versions won't be able to use React 18.
If you use the react-native upgrade command or the React Native Upgrade Helper, you'll bump to the correct React version once you upgrade React Native.