mirror of
https://github.com/zebrajr/react.git
synced 2025-12-07 12:20:38 +01:00
b229f540e2
This adds a new DEV-only row type `D` for DebugInfo. If we see this in prod, that's an error. It can contain extra debug information about the Server Components (or Promises) that were compiled away during the server render. It's DEV-only since this can contain sensitive information (similar to errors) and since it'll be a lot of data, but it's worth using the same stream for simplicity rather than a side-channel. In this first pass it's just the Server Component's name but I'll keep adding more debug info to the stream, and it won't always just be a Server Component's stack frame. Each row can get more debug rows data streaming in as it resolves and renders multiple server components in a row. The data structure is just a side-channel and it would be perfectly fine to ignore the D rows and it would behave the same as prod. With this data structure though the data is associated with the row ID / chunk, so you can't have inline meta data. This means that an inline Server Component that doesn't get an ID otherwise will need to be outlined. The way I outline Server Components is using a direct reference where it's synchronous though so on the client side it behaves the same (i.e. there's no lazy wrapper in this case). In most cases the `_debugInfo` is on the Promises that we yield and we also expose this on the `React.Lazy` wrappers. In the case where it's a synchronous render it might attach this data to Elements or Arrays (fragments) too. In a future PR I'll wire this information up with Fiber to stash it in the Fiber data structures so that DevTools can pick it up. This property and the information in it is not limited to Server Components. The name of the property that we look for probably shouldn't be `_debugInfo` since it's semi-public. Should consider the name we use for that. If it's a synchronous render that returns a string or number (text node) then we don't have anywhere to attach them to. We could add a `React.Lazy` wrapper for those but I chose to prioritize keeping the data structure untouched. Can be useful if you use Server Components to render data instead of React Nodes. |
||
|---|---|---|
| .. | ||
| __tests__ | ||
| codes.json | ||
| extract-errors.js | ||
| invertObject.js | ||
| README.md | ||
| transform-error-messages.js | ||
| Types.js | ||
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.jsoncontains 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.jsis an node script that traverses our codebase and updatescodes.json. You can test it by runningyarn 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. withyarn download build). It works with partial builds, too.transform-error-messagesis a Babel pass that rewrites error messages to IDs for a production (minified) build.