react/scripts/error-codes
Sebastian Markbåge a53da6abe1
Add useSwipeTransition Hook Behind Experimental Flag (#32373)
This Hook will be used to drive a View Transition based on a gesture.

```js
const [value, startGesture] = useSwipeTransition(prev, current, next);
```

The `enableSwipeTransition` flag will depend on `enableViewTransition`
flag but we may decide to ship them independently. This PR doesn't do
anything interesting yet. There will be a lot more PRs to build out the
actual functionality. This is just wiring up the plumbing for the new
Hook.

This first PR is mainly concerned with how the whole starts (and stops).
The core API is the `startGesture` function (although there will be
other conveniences added in the future). You can call this to start a
gesture with a source provider. You can call this multiple times in one
event to batch multiple Hooks listening to the same provider. However,
each render can only handle one source provider at a time and so it does
one render per scheduled gesture provider.

This uses a separate `GestureLane` to drive gesture renders by marking
the Hook as having an update on that lane. Then schedule a render. These
renders should be blocking and in the same microtask as the
`startGesture` to ensure it can block the paint. So it's similar to
sync.

It may not be possible to finish it synchronously e.g. if something
suspends. If so, it just tries again later when it can like any other
render. This can also happen because it also may not be possible to
drive more than one gesture at a time like if we're limited to one View
Transition per document. So right now you can only run one gesture at a
time in practice.

These renders never commit. This means that we can't clear the
`GestureLane` the normal way. Instead, we have to clear only the root's
`pendingLanes` if we don't have any new renders scheduled. Then wait
until something else updates the Fiber after all gestures on it have
stopped before it really clears.
2025-02-13 16:06:01 -05:00
..
__tests__ lint: enable reportUnusedDisableDirectives and remove unused suppressions (#28721) 2024-06-21 12:24:32 -04:00
codes.json Add useSwipeTransition Hook Behind Experimental Flag (#32373) 2025-02-13 16:06:01 -05:00
extract-errors.js Follow-up improvements to error code extraction infra (#22516) 2021-10-31 15:37:32 -07:00
invertObject.js [useFormState] Allow sync actions (#27571) 2023-10-31 23:32:31 -04:00
README.md Follow-up improvements to error code extraction infra (#22516) 2021-10-31 15:37:32 -07:00
transform-error-messages.js Track Stack of JSX Calls (#29032) 2024-05-09 12:23:05 -04:00
Types.js Upgrade prettier (#26081) 2023-01-31 08:25:05 -05:00

The error code system substitutes React's error messages with error IDs to provide a better debugging support in production. Check out the blog post here.

  • codes.json contains the mapping from IDs to error messages. This file is generated by the Gulp plugin and is used by both the Babel plugin and the error decoder page in our documentation. This file is append-only, which means an existing code in the file will never be changed/removed.
  • extract-errors.js is an node script that traverses our codebase and updates codes.json. You can test it by running yarn extract-errors. It works by crawling the build artifacts directory, so you need to have either run the build script or downloaded pre-built artifacts (e.g. with yarn download build). It works with partial builds, too.
  • transform-error-messages is a Babel pass that rewrites error messages to IDs for a production (minified) build.