[pull] main from facebook:main #107
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
![pull[bot]](https://avatars.githubusercontent.com/in/12910?s=60&v=4){kind=small}
…32445) Link headers are optionally supported for cases where you prefer to send resource loading hints before you're ready to send the body of a request. While many resources can be correctly preloaded from a link header responsive images are currently not supported and end up preloading the default src rather than the correctly sized image. Until responsive images are supported React will not allow these images to preload as headers and will retain them to preload as HTML. closes: #32437
…ce (#32446) ## Summary > [!NOTE] > This only modifies types, so shouldn't have an impact at runtime. Some time ago we moved some type definitions from React to React Native in #26437. This continues making progress on that so values that are created by React Native and passed to the React renderer (in this case public instances) are actually defined in React Native and not in React. This will allow us to modify the definition of some of these types without having to make changes in the React repository (in the short term, we want to refactor PublicInstance from an object to an interface, and then modify that interface to add all the new DOM methods). ## How did you test this change? Manually synced `ReactNativeTypes` on top of facebook/react-native#49602 and verified Flow passes.
wait to merge until we sync #32376, since that enables it in some testing builds that might break
Basic workspace setup for Forgive. --- [//]: # (BEGIN SAPLING FOOTER) Stack created with [Sapling](https://sapling-scm.com). Best reviewed with [ReviewStack](https://reviewstack.dev/facebook/react/pull/31917). * #31918 * #31927 * __->__ #31917
Adds basic build scripts. --- [//]: # (BEGIN SAPLING FOOTER) Stack created with [Sapling](https://sapling-scm.com). Best reviewed with [ReviewStack](https://reviewstack.dev/facebook/react/pull/31927). * #31918 * __->__ #31927
Init basic LSP. At the moment the extension doesn't do anything interesting, but it does compile successfully.
For the `useId` algorithm we used colon `:` before and after. #23360 This avoids collisions in general by using an unusual characters. It also avoids collisions when concatenated with some other ID. Unfortunately, `:` is not a valid character in `view-transition-name`. This PR swaps the format from: ``` :r123: ``` To the unicode: ``` «r123» ``` Which is valid CSS selectors. This also allows them being used for `querySelector()` which we didn't really find a legit use for but seems ok-ish. That way you can get a view-transition-name that you can manually reference. E.g. to generate styles: ```js const id = useId(); return <> <style>{` ::view-transition-group(${id}) { ... } ::view-transition-old(${id}) { ... } ::view-transition-new(${id}) { ... } `}</style> <ViewTransition name={id}>...</ViewTransition> </>; ```
This doesn't change anything. It just moves some functions. This moves the view transitions helper functions into its own file. This is similar to how I already moved ReactFiberCommitEffects and ReactFiberCommitHostEffects out of ReactFiberCommitWork. This makes it a bit easier to navigate and get an overview of ReactFiberCommitWork but another motivation is also so that I can refer to these helpers from [ReactFiberApplyGesture](https://github.com/facebook/react/pull/32451/files#diff-42297cf327dee8e01d83c85314b8965953b9674e7c4615ce6c430464dcc8550b).
Adds a first codelens provider for successfully compiled functions. A later PR will add an actual command that will fire when the codelens is clicked 
…ckages easier (#32486) It's getting unwieldy to list every single package to skip in these commands when you only want to publish one, ie eslint-plugin-react-hooks. This adds a new `onlyPackages` and `publishVersion` option to the publish commands to make that easier.
Adds a new workflow to publish runtime releases from NPM. Note that I commented out the actual publish command so I can test it out first.
Fixes up a few things in the script and workflow to make it possible to run in CI without interactive prompts.
Boolean params for dry runs are true if the param exists at all, so only add it if we're in dry run mode.
This adds a `ReactFiberApplyGesture` which is basically intended to be a fork of the phases in `ReactFiberCommitWork` except for the fake commit that `useSwipeTransition` does. So far none of the phases are actually implemented yet. This is just the scaffolding around them so I can fill them in later. The important bit is that we call `startViewTransition` (via the `startGestureTransition` Config) when a gesture starts. We add a paused animation to prevent the transition from committing (even if the ScrollTimeline goes to 100%). This also locks the documents so that we can't commit any other Transitions until it completes. When the gesture completes (scroll end) then we stop the gesture View Transition. If there's no new work scheduled we do that immediately but if there was any new work already scheduled, then we assume that this will potentially commit the new state. So we wait for that to finish. This lets us lock the animation in its state instead of snapping back and then applying the real update. Using this technique we can't actually run a View Transition from the current state to the actual committed state because it would snap back to the beginning and then run the View Transition from there. Therefore any new commit needs to skip View Transitions even if it should've technically animated to that state. We assume that the new state is the same as the optimistic state you already swiped to. An alternative to this technique could be to commit the optimistic state when we cancel and then apply any new updates o top of that. I might explore that in the future. Regardless it's important that the `action` associated with the swipe schedules some work before we cancel. Otherwise it risks reverting first. So I had to update this in the fixture.
fun times --- [//]: # (BEGIN SAPLING FOOTER) Stack created with [Sapling](https://sapling-scm.com). Best reviewed with [ReviewStack](https://reviewstack.dev/facebook/react/pull/32491). * #32492 * __->__ #32491
Uploads the releases that were published in case to help with debugging or verifying a dry run. --- [//]: # (BEGIN SAPLING FOOTER) Stack created with [Sapling](https://sapling-scm.com). Best reviewed with [ReviewStack](https://reviewstack.dev/facebook/react/pull/32492). * __->__ #32492 * #32491
In preparation for the merging of the compiler plugin into this one (#32416), this change proactively updates the plugin's `engines` declaration to require Node versions greater than or equal to 18 BREAKING CHANGE Co-authored-by: lauren <[email protected]>
…2411) Since the compiler plugin is going to be merged into the hooks plugin, and ultimately decomposed into several more rules, it would be good to start creating a more traditional folder structure for the plugin. This change just moves the rules into a `rules` folder. Co-authored-by: lauren <[email protected]>
…onfig (#32457) This change swaps which config `recommended` is aliasing. In 5.2.0, the new flat config was introduced as `recommended-latest`, while `recommended` still pointed at the legacy rc-based config, with a note that in the next major version `recommended` would be updated to point at `recommend-latest`. This change makes that swap, and make the default `recommended` experience the flat config. To continue using the legacy rc recommended config, please make the following change in your config ```diff - extends: ['plugin:react-hooks/recommended'] + extends: ['plugin:react-hooks/recommended-legacy'] ``` This change also deprecates `recommended-latest` in favor of `recommended`. `recommended-latest` will be removed in a future major version. The README has been updated to reflect the new usage, and to put the flat config sections before the legacy config sections. I also took the opportunity to change the v9 fixture to use a typescript config, serving as a demonstration for usage as well as a way to validate the types are correct. BREAKING CHANGE --------- Co-authored-by: lauren <[email protected]>
Randomly noticed this when I looked at a recent [DevTools regression test run](https://github.com/facebook/react/actions/runs/13578385011). I don't recall why we added `continue-on-error` previously, but I believe it was to keep all jobs in the matrix running even if one were to fail, in order to fully identify any failures from code changes like build or test failures. There is now a `fail-fast` option which does this. [`continue-on-error`](https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions#jobsjob_idcontinue-on-error) now means: > Prevents a workflow run from failing when a job fails. Set to true to allow a workflow run to pass when this job fails. so it's not correct to use it.
I end up rebuilding for testing the view-transition fixture a lot. It doesn't need everything that flight needs so this just adds a short hand that's a little faster to rebuild. --------- Co-authored-by: Hendrik Liebau <[email protected]>
We added support for `onScrollEnd` in #26789 but it only works in Chrome and Firefox. Safari still doesn't support `scrollend` and there's no indication that they will anytime soon so this polyfills it. While I don't particularly love our synthetic event system this tries to stay within the realm of how our other polyfills work. This implements all `onScrollEnd` events as a plugin. The basic principle is to first feature detect the `onscrollend` DOM property to see if there's native support and otherwise just use the native event. Then we listen to `scroll` events and set a timeout. If we don't get any more scroll events before the timeout we fire `onScrollEnd`. Basically debouncing it. If we're currently pressing down on touch or a mouse then we wait until it is lifted such as if you're scrolling with a finger or using the scrollbars on desktop but isn't currently moving. If we do get any native events even though we're in polyfilling mode, we use that as an indication to fire the `onScrollEnd` early. Part of the motivation is that this becomes extra useful pair for #32422. We also probably need these events to coincide with other gesture related internals so you're better off using our polyfill so they're synced.
numRequiredArgs has to be more than 0 and the pass depends on that --
Summary: Correctly supports React.useEffect when React is imported as `import * as React from 'react'` (as well as other namespaces as specified in the config).
…sions (#32498) This change adds more details about prior versions of the plugin's config, to help people as they migrate from legacy to flat configs across multiple versions of this plugin. At some point in the 6.0 or 7.0 cycle, it would probably make sense to re-consolidate this into a single version. Closes #32494
Uses `&` for Activity as opposed to `$` for Suspense. This will be used to delimitate which nodes we can skip hydrating. This isn't used on the client yet. It's just a noop on the client because it's just an unknown comment. This just adds the SSR parts.
This change adds the details for using the 6.0+ version of the flat recommended config. Co-authored-by: lauren <[email protected]>
This rule currently has a few false positives, so let's disable it for now (just in the eslint rule, it's still enabled in the compiler) while we iterate on it.
ActivityProps - Public API LegacyHiddenProps - Public Legacy API OffscreenProps - Internal implementation detail
Stacked on #32838. We don't always type the Props of built-ins. This adds typing for most of the built-ins. When we did type them, we used to put it in the `ReactFiber...Component` files but any public API like this can be implemented in other renderers too such as Fizz. So I moved them to `shared/ReactTypes` which is where we put other public API types (that are not already built-in to Flow). That way Fizz can import them and assert properly when it accesses the props.
## Summary This fixes how we map priorities between Fabric and the React reconciler. At the moment, we're only considering default and discrete priorities, when there's a larger range of priorities available. In Fabric, we'll test supporting additional priorities soon. For that test to do something useful, we need the new priorities to be mapped to reconciler priorities correctly, which is what this change is done. > [!IMPORTANT] > At the moment, this is a no-op because Fabric is only reporting default and discrete event priorities. ## How did you test this change? Will test e2e on React Native on top of facebook/react-native#50627 The changes are gated in React Native, so we'll use that feature flag to test this.
…32850) This lets us write them early in the render phase. This should be safe because even if we write them deeply, then they still can't be wrapped by a element because then they'd no longer be in the document scope anymore. They end up flat in the body and so when we search the content we'll discover them.
Assertively claim a SuspenseInstance. We already know we're hydrating. If there's no match, it throws anyway. So there's no other code path.
…phase (#32849) We use the Update flag to track if a View Transition had any mutations or relayout. Unlike the other usage of it, this is just temporary state during the commit phase. Normally the flags gets used in the render phase and we reset it when we rerender but in the case of "nested" updates, those trees didn't update. We're only looking for relayouts. So we need to manually reset it before we start using it. We probably shouldn't abuse the Update flag for this and instead use something like temporary state on ViewTransitionState.
It used to be that in `__DEV__` we wrapped this `renderWithHooks`, `checkDidRenderIdHook` pair in calls to `setIsRendering()`. However, that dev-only bookkeeping was removed in #29206 leaving this redundant check which runs identical code in dev and in prod. ## Test Plan * Manually confirm both cases are the same * GitHub CI tests
Try to upgrade our node version. --- [//]: # (BEGIN SAPLING FOOTER) Stack created with [Sapling](https://sapling-scm.com). Best reviewed with [ReviewStack](https://reviewstack.dev/facebook/react/pull/32855). * #32861 * #32860 * #32859 * __->__ #32855
Just updating the compiler workspace package. --- [//]: # (BEGIN SAPLING FOOTER) Stack created with [Sapling](https://sapling-scm.com). Best reviewed with [ReviewStack](https://reviewstack.dev/facebook/react/pull/32868). * #32859 * __->__ #32868
Just trying this out as a small hack for fun. Nothing serious is planned. Inits an MCP server that has 1 assistant prompt and two capabilities.
<!-- 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 This PR adds support for displaying the names of changed hooks directly in the Profiler tab, making it easier to identify specific updates. A `HookChangeSummary` component has been introduced to show these hook names, with a `displayMode` prop that toggles between `“compact”` for tooltips and `“detailed”` for more in-depth views. This keeps tooltip summaries concise while allowing for a full breakdown where needed. This functionality also respects the `“Always parse hook names from source”` setting from the Component inspector, as it uses the same caching mechanism already in place for the Components tab. Additionally, even without hook names parsed, the Profiler will now display hook types (like `State`, `Callback`, etc.) based on data from `inspectedElement`. To enable this across the DevTools, `InspectedElementContext` has been moved higher in the component tree, allowing it to be shared between the Profiler and Components tabs. This update allows hook name data to be reused across tabs without duplication. Additionally, a `getAlreadyLoadedHookNames` helper function was added to efficiently access cached hook names, reducing the need for repeated fetching when displaying changes. These changes improve the ability to track specific hook updates within the Profiler tab, making it clearer to see what’s changed. ### Before Previously, the Profiler tab displayed only the IDs of changed hooks, as shown below: <img width="350" alt="Screenshot 2024-11-01 at 12 02 21_cropped" src="https://github.com/user-attachments/assets/7a5f5f67-f1c8-4261-9ba3-1c76c9a88af3"> ### After (without hook names parsed) When hook names aren’t parsed, custom hooks and hook types are displayed based on the inspectedElement data: <img width="350" alt="Screenshot 2024-11-01 at 12 03 09_cropped" src="https://github.com/user-attachments/assets/ed857a6d-e6ef-4e5b-982c-bf30c2d8a7e2"> ### After (with hook names parsed) Once hook names are fully parsed, the Profiler tab provides a complete breakdown of specific hooks that have changed: <img width="350" alt="Screenshot 2024-11-01 at 12 03 14_cropped" src="https://github.com/user-attachments/assets/1ddfcc35-7474-4f4d-a084-f4e9f993a5bf"> This should resolve #21856 🎉
This change adds a background color to Toggles to make them easier to see. This is especially important when DevTools are not in focus, and it's harder to see. Test plan: 1. `yarn build:chrome:local` 2. Inspect components 3. Hover over "Select an Element in page to inspect it" 4. Observe background change
Routine update. --- [//]: # (BEGIN SAPLING FOOTER) Stack created with [Sapling](https://sapling-scm.com). Best reviewed with [ReviewStack](https://reviewstack.dev/facebook/react/pull/32917). * #32918 * __->__ #32917
There's really no need to even run the workflow for non-members or collaborators for the labeling and discord notification workflows. We can exit early.
Since `hidden` is a prop on arbitrary DOM elements it's a common mistake to think that it would also work that way on `<Activity>` but it doesn't. In fact, we even had this mistakes in our own tests. Maybe there's an argument that we should actually just support it but we also have more modes planned. So this adds a warning. It should also already be covered by TypeScript.
I found a bug even before the Activity hydration stuff. If we're hydrating an Offscreen boundary in its "hidden" state it won't have any content to hydrate so will trigger hydration errors (which are then eaten by the Offscreen boundary itself). Leaving it not prewarmed. This doesn't happen in the simple case because we'd be hydrating at a higher priority than Offscreen at the root, and those are deferred to Offscreen by not having higher priority. However, we've hydrating at the Offscreen priority, which we do inside Suspense boundaries, then it tries to hydrate against an empty set. I ended up moving this to the Activity boundary in a future PR since it's the SSR side that decided where to not render something and it only has a concept of Activity, no Offscreen. 1dc05a5#diff-d5166797ebbc5b646a49e6a06a049330ca617985d7a6edf3ad1641b43fde1ddfR1111
the joy of yml
Uses https://github.com/modelcontextprotocol/inspector to inspect and debug the mcp server. `yarn workspace react-mcp-server dev` will build the server in watch mode and launch the inspector. Default address is http://127.0.0.1:6274. --- [//]: # (BEGIN SAPLING FOOTER) Stack created with [Sapling](https://sapling-scm.com). Best reviewed with [ReviewStack](https://reviewstack.dev/facebook/react/pull/32928). * #32932 * #32931 * #32930 * #32929 * __->__ #32928
Previously the resource would return a bunch of dupes because the algolia results would return multiple hashes (headings) for the same url. --- [//]: # (BEGIN SAPLING FOOTER) Stack created with [Sapling](https://sapling-scm.com). Best reviewed with [ReviewStack](https://reviewstack.dev/facebook/react/pull/32929). * #32932 * #32931 * #32930 * __->__ #32929 * #32928
Adds some new options to request the HIR, ReactiveFunction passes --- [//]: # (BEGIN SAPLING FOOTER) Stack created with [Sapling](https://sapling-scm.com). Best reviewed with [ReviewStack](https://reviewstack.dev/facebook/react/pull/32930). * #32932 * #32931 * __->__ #32930 * #32929 * #32928
Use the correct loc line numbers and not [Object:object] --- [//]: # (BEGIN SAPLING FOOTER) Stack created with [Sapling](https://sapling-scm.com). Best reviewed with [ReviewStack](https://reviewstack.dev/facebook/react/pull/32931). * #32932 * __->__ #32931 * #32930 * #32929 * #32928
v2 --- [//]: # (BEGIN SAPLING FOOTER) Stack created with [Sapling](https://sapling-scm.com). Best reviewed with [ReviewStack](https://reviewstack.dev/facebook/react/pull/32932). * __->__ #32932 * #32931 * #32930 * #32929 * #32928
I can see the value being output and set correctly but not sure why it's skipping the 2nd job. --- [//]: # (BEGIN SAPLING FOOTER) Stack created with [Sapling](https://sapling-scm.com). Best reviewed with [ReviewStack](https://reviewstack.dev/facebook/react/pull/32935). * #32936 * __->__ #32935
No reason to label it every update, only do it once when it's first opened. --- [//]: # (BEGIN SAPLING FOOTER) Stack created with [Sapling](https://sapling-scm.com). Best reviewed with [ReviewStack](https://reviewstack.dev/facebook/react/pull/32936). * __->__ #32936 * #32935
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.
See Commits and Changes for more details.
Created by
pull[bot] (v2.0.0-alpha.1)
Can you help keep this open source service alive? 💖 Please sponsor : )