Update RDT fork to support React 19 #14
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…#28955) ## Summary I'm looking at cleaning up some unnecessary manual property flattening in React Native and wanted to verify this behaviour is working as expected, where properties from nested objects will always overwrite properties from the base object. ## How did you test this change? Unit tests
Move useMemoCache hook to react/compiler-runtime For Meta-internal purposes, we keep the export on `react` itself to reduce churn.
Enables the Reanimated flag automatically if we find reanimated in the user's list of plugins ghstack-source-id: 20e83374612362a30d6c8cc7a903d9320e8cc23a Pull Request resolved: facebook/react-forget#2915
ghstack-source-id: 79f3319d87909d05731ef821d0ffe86cb01b0432 Pull Request resolved: facebook/react-forget#2920
Show compiling status message and not just block UI. ghstack-source-id: 67761c5d32216e105c4aa6404dfa07d76ae22583 Pull Request resolved: https://github.com/facebook/react-forget/pull/2921
ghstack-source-id: f05222073be785b77346c4e8760bf4d0bb4d658e Pull Request resolved: https://github.com/facebook/react-forget/pull/2922
Add a configurable list of known incompatible libraries. Check all package.jsons for any uses of known incompatible libraries and warn if found. ghstack-source-id: 7329e3792b57458e681780cba3140a14a9b1a60d Pull Request resolved: https://github.com/facebook/react-forget/pull/2923
Makes it easier to extend later, if we want to add more checks. ghstack-source-id: 6fb3435555f1b988e1a185bfda8be9418eb622c5 Pull Request resolved: https://github.com/facebook/react-forget/pull/2924
Treat MethodCalls similar to general CallExpressions and mark them as escaping in PruneNonEscapingScopes pass. ghstack-source-id: 3c81bdb17f58fbeef8be24e7cb363172d1867217 Pull Request resolved: https://github.com/facebook/react-forget/pull/2925
…ook#2918) This uses the compiler runtime from `react/compiler-runtime` by default unless `compilerRuntime` is specifified in the Babel options which then imports the runtime from there. The `useMemoCache` hook is now named `c` in accordance with facebook@4508873 Unfortunately, I couldn't figure out how to import `react@beta` which already has that import as various react verstions were conflicting. If someone can figure this out it'd be fantastic. As a result, I had to update the default for the test runner to default the `compilerRuntime` option to `react` to preserve the previous behavior to import from `react`. Once upgraded to React 19, we should be able to remove that override.
To make a first time setup of the compiler truly config-less, default to not compiling node_modules unless a user provided `sources` (advanced option) is provided ghstack-source-id: b0798052404d772ce6ee471e577699d4b0871d56 Pull Request resolved: facebook/react-forget#2919
When a React PR is opened CI will report large size changes. But for critical packages like react-dom it reports always. In React 19 we moved the build for react-dom the client reconciler from react-dom to react-dom/client This change adds react-dom-client artifacts for stable and oss channels since that is originally what was being tracked. But since react-dom/client always imports react-dom I left the original react-dom packages as critical as well. They are small but it would be good to keep an eye on them
) ## Summary This PR introduces a faster version of the `addProperties` function. This new function is basically the `diffProperties` with `prevProps` set to `null`, propagated constants, and all the unreachable code paths collapsed. ## How did you test this change? I've tested this change with [the benchmark app](https://github.com/react-native-community/RNNewArchitectureApp/tree/new-architecture-benchmarks) and got ~4.4% improvement in the view creation time.
…ontext in React 17 (facebook#28974)
ghstack-source-id: bb66913e2d3c814696311371ed655f3da03d1199 Pull Request resolved: facebook/react-forget#2926
ghstack-source-id: cce73f26b7b3903b8d79b70dbc24cbee09693d81 Pull Request resolved: facebook/react-forget#2927
ghstack-source-id: e7f00aab61dd749dc6ba11ce7e4d14603bfeeab9 Pull Request resolved: facebook/react-forget#2928
ghstack-source-id: 9cd5fe41ae322632dfeb3d5c7468268678006d94 Pull Request resolved: facebook/react-forget#2929
ghstack-source-id: c6c825f5efdb4f9c413050b22b7713966871338c Pull Request resolved: facebook/react-forget#2931
Following facebook#28768, add a path to testing Fast JSX on www. We want to measure the impact of Fast JSX and enable a path to testing before string refs are completely removed in www (which is a work in progress). Without `disableStringRefs`, we need to copy any object with a `ref` key so we can pass it through `coerceStringRef()` and copy it into the object. This de-opt path is what is gated behind `enableFastJSXWithStringRefs`. The additional checks should have no perf impact in OSS as the flags remain true there and the build output is not changed. For www, I've benchmarked the addition of the boolean checks with values cached at module scope. There is no significant change observed from our benchmarks and any latency will apply to test and control branches evenly. This added experiment complexity is temporary. We should be able to clean it up, along with the flag checks for `enableRefAsProp` and `disableStringRefs` shortly.
…de in build output (facebook#28970) ## Summary The `react-devtools-fusebox` private package is used in the React Native DevTools (Fusebox) frontend by checking build artifacts into RN's [fork]([`facebookexperimental/rn-chrome-devtools-frontend`](https://github.com/facebookexperimental/rn-chrome-devtools-frontend)) of the Chrome DevTools (CDT) repo - see facebookexperimental/rn-chrome-devtools-frontend#22. Currently, the CDT fork also includes a [manually written TypeScript definition file](https://github.com/facebookexperimental/rn-chrome-devtools-frontend/blob/1d5f8d5209ac49de97aec16732169d47bf525474/front_end/third_party/react-devtools/package/frontend.d.ts) which describes `react-devtools-fusebox`'s API. This PR moves that file into the React repo, next to the implementation of `react-devtools-fusebox`, so we can update it atomically with changes to the package. As this is the first bit of TypeScript in this repo, the PR adds minimal support for formatting `.d.ts` files with Prettier. It also opts out `react-devtools-fusebox/dist/` from linting/formatting as a drive-by fix. For now, we'll just maintain the `.d.ts` file manually, but we could consider leveraging [`flow-api-translator`](https://www.npmjs.com/package/flow-api-translator) to auto-generate it in the future. ## How did you test this change? Build `react-devtools-fusebox`, observe that `dist/frontend.d.ts` exists.
…#28972) ## Summary Enables the inspected element context menu in React Native DevTools (Fusebox). ## How did you test this change? 1. `yarn build` in `react-devtools-fusebox` 2. Copy artifacts to rn-chrome-devtools-frontend 3. Manually test the context menu https://github.com/facebook/react/assets/2246565/b35cc20f-8d67-43b0-b863-7731e10fffac NOTE: The serialised values sometimes expose React internals (e.g. Hook data structures instead of just the values), but that seems to be a problem equally on web, so I'm going for native<->web parity here.
…k#29670) When a component suspends with `use`, we switch to the "re-render" dispatcher during the subsequent render attempt, so that we can reuse the work from the initial attempt. However, once we run out of hooks from the previous attempt, we should switch back to the regular "update" dispatcher. This is conceptually the same fix as the one introduced in facebook#26232. That fix only accounted for initial mount, but the useTransition regression test added in f829733 illustrates that we need to handle updates, too. The issue affects more than just useTransition but because most of the behavior between the "re-render" and "update" dispatchers is the same it's hard to contrive other scenarios in a test, which is probably why it took so long for someone to notice. Closes facebook#28923 and facebook#29209 --------- Co-authored-by: eps1lon <[email protected]>
Eslint rules should never throw, so if we fail to parse with Babel or Hermes, we should just ignore the error. This should fix issues such as trying to run the eslint rule on non tsx|ts|jsx|js files, Hermes parser not supporting certain JS syntax, etc. I didn't add a test for this as our eslint-rule-tester config uses hermes-eslint parser, so it wasn't possible to add a top level await as it would crash hermes-eslint before our rule was triggered. Similarly I couldn't add a test for non-JS files as it would not be parseable by hermes-eslint. Fixes facebook#29107 ghstack-source-id: 60afcdb89ab4a8d2e4697cc50c5490803e7cbeac Pull Request resolved: facebook#29631
…ce maps from (facebook#29708) This lets you click a stack frame on the client and see the Server source code inline. <img width="871" alt="Screenshot 2024-06-01 at 11 44 24 PM" src="https://github.com/facebook/react/assets/63648/581281ce-0dce-40c0-a084-4a6d53ba1682"> <img width="840" alt="Screenshot 2024-06-01 at 11 43 37 PM" src="https://github.com/facebook/react/assets/63648/00dc77af-07c1-4389-9ae0-cf1f45199efb"> We could do some logic on the server that sends a source map url for every stack frame in the RSC payload. That would make the client potentially config free. However regardless we need the config to describe what url scheme to use since that’s not built in to the bundler config. In practice you likely have a common pattern for your source maps so no need to send data over and over when we can just have a simple function configured on the client. The server must return a source map, even if the file is not actually compiled since the fake file is still compiled. The source mapping strategy can be one of two models depending on if the server’s stack traces (`new Error().stack`) are source mapped back to the original (`—enable-source-maps`) or represents the location in compiled code (like in the browser). If it represents the location in compiled code it’s actually easier. You just serve the source map generated for that file by the tooling. If it is already source mapped it has to generate a source map where everything points to the same location (as if not compiled) ideally with a segment per logical ast node.
Requires facebook#29706 The strategy here is to: - Checkout the builds/facebook-www branch - Read the current sync'd VERSION - Checkout out main and sync new build - sed/{new version string}/{old version string} - Run git status, skip sync if clean - Otherwise, sed/{old version string}/{new version string} and push commit This means that: - We're using the real version strings from the builds - We are checking the last commit on the branch for the real last version - We're skipping any commits that won't result in changes - ??? - Profit!
Host Components can exist as four semantic types 1. regular Components (Vanilla obv) 2. singleton Components 2. hoistable components 3. resources Each of these component types have their own rules related to mounting and reconciliation however they are not direclty modeled as their own unique fiber type. This is partly for code size but also because reconciling the inner type of these components would be in a very hot path in fiber creation and reconciliation and it's just not practical to do this logic check here. Right now we have three Fiber types used to implement these 4 concepts but we probably need to reconsider the model and think of Host Components as a single fiber type with an inner implementation. Once we do this we can regularize things like transitioning between a resource and a regular component or a singleton and a hoistable instance. The cases where these transitions happen today aren't particularly common but they can be observed and currently the handling of these transitions is incomplete at best and buggy at worst. The most egregious case is the link type. This can be a regular component (stylesheet without precedence) a hoistable component (non stylesheet link tags) or a resource (stylesheet with a precedence) and if you have a single jsx slot that tries to reconcile transitions between these types it just doesn't work well. This commit adds an error for when a Hoistable goes from Instance to Resource. Currently this is only possible for `<link>` elements going to and from stylesheets with precedence. Hopefully we'll be able to remove this error and implement as an inner type before we encounter new categories for the Hoistable types detecting type shifting to and from regular components is harder to do efficiently because we don't want to reevaluate the type on every update for host components which is currently not required and would add overhead to a very hot path singletons can't really type shift in their one practical implementation (DOM) so they are only a problem in theroy not practice
stylehsheet -> stylesheet
Mini-refactor of useActionState to only wrap the action in a transition context if the dispatch is called during a transition. Conceptually, the action starts as soon as the dispatch is called, even if the action is queued until earlier ones finish. We will also warn if an async action is dispatched outside of a transition, since that is almost certainly a mistake. Ideally we would automatically upgrade these to a transition, but we don't have a great way to tell if the action is async until after it's already run.
Based on - facebook#29694 --- If an action in the useActionState queue errors, we shouldn't run any subsequent actions. The contract of useActionState is that the actions run in sequence, and that one action can assume that all previous actions have completed successfully. For example, in a shopping cart UI, you might dispatch an "Add to cart" action followed by a "Checkout" action. If the "Add to cart" action errors, the "Checkout" action should not run. An implication of this change is that once useActionState falls into an error state, the only way to recover is to reset the component tree, i.e. by unmounting and remounting. The way to customize the error handling behavior is to wrap the action body in a try/catch.
RC releases are a special kind of prerelease build because unlike
canaries we shouldn't publish new RCs from any commit on `main`, only
when we intentionally bump the RC number. But they are still prerelases
— like canary and experimental releases, they should use exact version
numbers in their dependencies (no ^).
We only need to generate these builds during the RC phase, i.e. when the
canary channel label is set to "rc".
Example of resulting package.json output:
```json
{
"name": "react-dom",
"version": "19.0.0-rc.0",
"dependencies": {
"scheduler": "0.25.0-rc.0"
},
"peerDependencies": {
"react": "19.0.0-rc.0"
}
}
```
https://react-builds.vercel.app/prs/29736/files/oss-stable-rc/react-dom/package.json
facebook#29697) This information is available in the regular stack but since that's hidden behind an expando and our appended stack to logs is not hidden, it hides the most important frames like the name of the current component. This is closer to what happens to the native stack. We only include stacks if they're within a ReactFiberCallUserSpace call frame. This should be most that have a current fiber but this is critical to filtering out most React frames if the regular node_modules filter doesn't work. Most React warnings fire during the rendering phase and not inside a user space function but some do like hooks warnings and setState in render. This feature is more important if we port this to React DevTools appending stacks to all logs where it's likely to originate from inside a component and you want the line within that component to immediately part of the visible stack. One thing that kind sucks is that we don't have a reliable way to exclude React internal stack frames. We filter node_modules but it might not match. For other cases I try hard to only track the stack frame at the root of React (e.g. immediately inside createElement) until the ReactFiberCallUserSpace so we don't need the filtering to work. In this case it's hard to achieve the same thing though. This is easier in RDT because we have the start/end line and parsing of stack traces so we can use that to exclude internals but that's a lot of code/complexity for shipping within the library. For example in Safari: <img width="590" alt="Screenshot 2024-05-31 at 6 15 27 PM" src="https://github.com/facebook/react/assets/63648/2820c8c0-8a03-42e9-8678-8348f66b051a"> Ideally warnOnUseFormStateInDev and useFormState wouldn't be included since they're React internals. Before this change, the Counter.js line also wasn't included though which points to exactly where the error is within the user code. (Note Server Components have V8 formatted lines and Client Components have JSC formatted lines.)
Use some clever git diffing to ignore lines that only change the `@generated` header. We can't do this for the version string because the version string can be embedded in lines with other changes, but this header is always on one line.
ghstack-source-id: eedd024d36f66a68abe43ba0f679e2d462b77505 Pull Request resolved: facebook#29742
…ed (facebook#29720) Following the instructions in the compiler/docs/DEVELOPMENT_GUIDE.md, we are stuck on the command `yarn snap --watch` because it calls readTestFilter even though the filter option is not enabled.
www: set enableRefAsProp to true
… of react (facebook#29753) <!-- Thanks for submitting a pull request! We appreciate you spending the time to work on these changes. Please provide enough information so that others can review your pull request. The three fields below are mandatory. Before submitting a pull request, please make sure the following is done: 1. Fork [the repository](https://github.com/facebook/react) and create your branch from `main`. 2. Run `yarn` in the repository root. 3. If you've fixed a bug or added code that should be tested, add tests! 4. Ensure the test suite passes (`yarn test`). Tip: `yarn test --watch TestName` is helpful in development. 5. Run `yarn test --prod` to test in the production environment. It supports the same options as `yarn test`. 6. If you need a debugger, run `yarn test --debug --watch TestName`, open `chrome://inspect`, and press "Inspect". 7. Format your code with [prettier](https://github.com/prettier/prettier) (`yarn prettier`). 8. Make sure your code lints (`yarn lint`). Tip: `yarn linc` to only check changed files. 9. Run the [Flow](https://flowtype.org/) type checks (`yarn flow`). 10. If you haven't already, complete the CLA. Learn more about contributing: https://reactjs.org/docs/how-to-contribute.html --> ## Summary Remove `startTransition` and `useActionState` from `react-server` condition of react, as they should only stay in client bundle. This will reduce the server bundle of react itself. Found this while tracing where the `process.emit` was called. <!-- Explain the **motivation** for making this change. What existing problem does the pull request solve? --> ## How did you test this change? <!-- Demonstrate the code is solid. Example: The exact commands you ran and their output, screenshots / videos if the pull request changes the user interface. How exactly did you verify that your PR solves the issue you wanted to solve? If you leave this empty, your PR will very likely be closed. -->
## Overview We didn't have any tests that ran in persistent mode with the xplat feature flags (for either variant). As a result, invalid test gating like in facebook#29664 were not caught. This PR adds test flavors for `ReactFeatureFlag-native-fb.js` in both variants.
|
🚨 Potential security issues detected. Learn more about Socket for GitHub ↗︎ To accept the risk, merge this PR and you will not be notified again.
Next stepsWhat's wrong with native code?Contains native code which could be a vector to obscure malicious code, and generally decrease the likelihood of reproducible or reliable installs. Ensure that native code bindings are expected. Consumers may consider pure JS and functionally similar alternatives to avoid the challenges and risks associated with native code bindings. What is telemetry?This package contains telemetry which tracks how it is used. Most telemetry comes with settings to disable it. Consider disabling telemetry if you do not want to be tracked. What is an AI detected anomaly?AI has identified unusual behaviors that may pose a security risk. An AI system found a low-risk anomaly in this package. It may still be fine to use, but you should check that it is safe before proceeding. What is an install script?Install scripts are run when the package is installed. The majority of malware in npm is hidden in install scripts. Packages should not be running non-essential scripts during install and there are often solutions to problems people solve with install scripts that can be run at publish time instead. Take a deeper look at the dependencyTake a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at support [AT] socket [DOT] dev. Remove the packageIf you happen to install a dependency that Socket reports as Known Malware you should immediately remove it and select a different dependency. For other alert types, you may may wish to investigate alternative packages or consider if there are other ways to mitigate the specific risk posed by the dependency. Mark a package as acceptable riskTo ignore an alert, reply with a comment starting with
|
|
This PR can probably be closed (along with the fork) in favor of https://github.com/facebook/react/compare/main...replayio:react:replay-react-devtools?expand=1 |
|
Never merged this into the old fork branch, so doing that for completeness. |
markerikson
merged commit cc8b61c
into
feature/replay-react-devtools
15 of 16 checks passed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR: