This project is mirrored from https://github.com/facebook/react.git.
Pull mirroring updated .
This branch has diverged from upstream.
- Mar 05, 2025
-
-
Mofei Zhang authored
Array and argument spreads may mutate stateful iterables. Spread sites should have `ConditionallyMutate` effects (e.g. mutate if the ValueKind is mutable, otherwise read). See - [ecma spec (13.2.4.1 Runtime Semantics: ArrayAccumulation. SpreadElement : ... AssignmentExpression)](https://tc39.es/ecma262/multipage/ecmascript-language-expressions.html#sec-runtime-semantics-arrayaccumulation). - [ecma spec 13.3.8.1 Runtime Semantics: ArgumentListEvaluation](https://tc39.es/ecma262/multipage/ecmascript-language-expressions.html#sec-runtime-semantics-argumentlistevaluation) Note that - Object and JSX Attribute spreads do not evaluate iterables (srcs [mozilla](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Spread_syntax#description), [ecma](https://tc39.es/ecma262/multipage/ecmascript-language-expressions.html#sec-runtime-semantics-propertydefinitionevaluation)) - An ideal mutability inference system could model known collections (i.e. Arrays or Sets) as a "mutated collection of non-mutable objects" (see `todo-granular-iterator-semantics`), but this is not what we do today. As such, an array / argument spread will always extend the range of built-in arrays, sets, etc - Due to HIR limitations, call expressions with argument spreads may cause unnecessary bailouts and/or scope merging when we know the call itself has `freeze`, `capture`, or `read` semantics (e.g. `useHook(...mutableValue)`) We can deal with this by rewriting these call instructions to (1) create an intermediate array to consume the iterator and (2) capture and spread the array at the callsite
-
Mofei Zhang authored
See newly added test fixtures. Repros fixed in later prs of this stack
-
- Mar 04, 2025
-
-
michael faith authored
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
-
Jordan Brown authored
-
Jordan Brown authored
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).
-
Jordan Brown authored
numRequiredArgs has to be more than 0 and the pass depends on that --
-
Sebastian Markbåge authored
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 https://github.com/facebook/react/pull/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.
-
- Mar 02, 2025
-
-
Sebastian Markbåge authored
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 <mail@hendrik-liebau.de>
-
- Mar 01, 2025
-
-
lauren authored
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.
-
michael faith authored
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 <poteto@users.noreply.github.com>
-
michael faith authored
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 <poteto@users.noreply.github.com>
-
michael faith authored
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 <poteto@users.noreply.github.com>
-
- Feb 28, 2025
-
-
lauren authored
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
-
lauren authored
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
-
Sebastian Markbåge authored
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.
-
lauren authored
Boolean params for dry runs are true if the param exists at all, so only add it if we're in dry run mode.
-
lauren authored
Fixes up a few things in the script and workflow to make it possible to run in CI without interactive prompts.
-
lauren authored
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.
-
lauren authored
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.
-
- Feb 26, 2025
-
-
lauren authored
-
lauren authored
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 
-
Sebastian Markbåge authored
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).
-
Sebastian Markbåge authored
For the `useId` algorithm we used colon `:` before and after. https://github.com/facebook/react/pull/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> </>; ```
-
lauren authored
Init basic LSP. At the moment the extension doesn't do anything interesting, but it does compile successfully.
-
lauren authored
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
-
lauren authored
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
-
- Feb 25, 2025
-
-
Sebastian "Sebbie" Silbermann authored
-
- Feb 24, 2025
-
-
Rick Hanlon authored
wait to merge until we sync https://github.com/facebook/react/pull/32376, since that enables it in some testing builds that might break
-
Rubén Norte authored
## 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 https://github.com/facebook/react-native/pull/49602 and verified Flow passes.
-
Sebastian "Sebbie" Silbermann authored
-
- Feb 22, 2025
-
-
Josh Story authored
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
-
Sebastian Markbåge authored
Stacked on #32412. To effectively `useSwipeTransition` you need something to start and stop the gesture as well as triggering an Action. This adds an example Gesture Recognizer to the fixture. Instead of having this built-in to React itself, instead the idea is to leave this to various user space Component libraries. It can be done in different ways for different use cases. It could use JS driven or native ScrollTimeline or both. This example uses a native scroll with scroll snapping to two edges. If you swipe far enough to snap to the other edge, it triggers an Action at the end. This particular example uses a `position: sticky` to wrap the content of the Gesture Recognizer. This means that it's inert by itself. It doesn't scroll its content just like a plain JS recognizer using pointer events would. This is useful because it means that scrolling doesn't affect content before we start (the "scroll" event fires after scrolling has already started) so we don't have to both trying to start it earlier. It also means that scrolling doesn't affect the live content which can lead to unexpected effects on the View Transition. I find the inert recognizer the most useful pairing with `useSwipeTransition` but it's not the only way to do it. E.g. you can also have a scrollable surface that uses plain scrolling with snapping and then just progressively enhances swiping between steps.
-
Sebastian Markbåge authored
Stacked on #32379 Track the range offsets along the timeline where previous/current/next is. This can also be specified as an option. This lets you model more than three states along a timeline by clamping them and then updating the "current" as you go. It also allows specifying the "current" offset as something different than what it was when the gesture started such as if it has to start after scroll has already happened (such as what happens if you listen to the "scroll" event).
-
- Feb 21, 2025
-
-
Sebastian Markbåge authored
We can only render one direction at a time with View Transitions. When the direction changes we need to do another render in the new direction (returning previous or next). To determine direction we store the position we started at and anything moving to a lower value (left/up) is "previous" direction (`false`) and anything else is "next" (`true`) direction. For the very first render we won't know which direction you're going since you're still on the initial position. It's useful to start the render to allow the view transition to take control before anything shifts around so we start from the original position. This is not guaranteed though if the render suspends. For now we start the first render by guessing the direction such as if we know that prev/next are the same as current. With the upcoming auto start mode we can guess more accurately there before we start. We can also add explicit APIs to `startGesture` but ideally it wouldn't matter. Ideally we could just start after the first change in direction from the starting point.
-
Sam Zhou authored
-
Jack Pope authored
This reverts commit 8759c5c8 / https://github.com/facebook/react/pull/32318 We discovered that the experiment setup for this was faulty and we need to re-run as a back test.
-
mofeiZ authored
Upgrade compiler playground to use the newest nextjs release, which includes react compiler transform pipeline optimizations https://github.com/vercel/next.js/pull/75676/. Also made a drive-by fix to avoid the error `Cannot update a component ('Router') while rendering a different component ('StoreProvider'). To locate the bad setState() call inside 'StoreProvider', follow the stack trace as described in https://react.dev/link/setstate-in-render`. The bad setState came from `history.replaceState({}, '', \`#${hash}\`);`. Prior to this, playground ran side effects in a reducer (i.e. during render). These have now been moved an effect.
-
- Feb 20, 2025
-
-
mofeiZ authored
Fixes https://github.com/facebook/react/issues/32269, see comments for details. Added test fixture for repro
-
- Feb 19, 2025
-
-
lauren authored
Update eslint-plugin-react-hooks to be built targetting ES5 instead. For various reasons our internal infra relies on these files being built already downleveled.
-
mofeiZ authored
Test fixtures testing different compiler features (e.g. non-auto memoization) should live in separate directories. Remove bug-prefixed fixtures that have since been fixed Add test evaluator export to more fixtures
-