OSSForks/react
1
0
Fork 0
mirror of https://github.com/zebrajr/react.git synced 2026-01-15 12:15:22 +00:00
Code Issues Actions 6 Packages Projects Releases Wiki Activity
Files
2b4064eb9b40f65d20a03ce93b246ad762d562e6
react/scripts/error-codes/codes.json

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

550 lines
60 KiB
JSON
Raw Normal View History

Add a gulp script for extracting error codes (#6882)
2016-06-01 11:21:26 -07:00
{
Remove method name prefix from warnings and errors (#28432) This pattern is a petpeeve of mine. I don't consider this best practice and so most don't have these prefixes. Very inconsistent. At best this is useless and noisey that you have to parse because the information is also in the stack trace. At worse these are misleading because they're highlighting something internal (like validateDOMNesting) which even suggests an internal bug. Even the ones public to React aren't necessarily what you called because you might be calling a wrapper around it. That would be properly reflected in a stack trace - which can also properly ignore list so that the first stack you see is your callsite, Which might be like `render()` in react-testing-library rather than `createRoot()` for example.
2024-02-23 15:16:54 -05:00
"0": "Encountered an invalid child; DOM elements are not valid children of React components.",
Add a gulp script for extracting error codes (#6882)
2016-06-01 11:21:26 -07:00
"1": "update(): expected target of %s to be an array; got %s.",
"2": "update(): expected spec of %s to be an array; got %s. Did you forget to wrap your parameter in an array?",
"3": "update(): You provided a key path to update() that did not contain one of %s. Did you forget to include {%s: ...}?",
"4": "Cannot have more than one key in an object with %s",
"5": "update(): %s expects a spec of type 'object'; got %s",
"6": "update(): %s expects a target of type 'object'; got %s",
"7": "Expected %s target to be an array; got %s",
"8": "update(): expected spec of %s to be an array of arrays; got %s. Did you forget to wrap your parameters in an array?",
"9": "update(): expected spec of %s to be a function; got %s.",
Remove method name prefix from warnings and errors (#28432) This pattern is a petpeeve of mine. I don't consider this best practice and so most don't have these prefixes. Very inconsistent. At best this is useless and noisey that you have to parse because the information is also in the stack trace. At worse these are misleading because they're highlighting something internal (like validateDOMNesting) which even suggests an internal bug. Even the ones public to React aren't necessarily what you called because you might be calling a wrapper around it. That would be properly reflected in a stack trace - which can also properly ignore list so that the first stack you see is your callsite, Which might be like `render()` in react-testing-library rather than `createRoot()` for example.
2024-02-23 15:16:54 -05:00
"10": "instance must be a composite component",
Add a gulp script for extracting error codes (#6882)
2016-06-01 11:21:26 -07:00
"11": "TestUtils.scryRenderedDOMComponentsWithClass expects a className as a second argument.",
"12": "ReactShallowRenderer render(): Invalid component element.%s",
"13": "ReactShallowRenderer render(): Shallow rendering works only with custom components, not primitives (%s). Instead of calling `.render(el)` and inspecting the rendered output, look at `el.props` directly instead.",
"14": "TestUtils.Simulate expects a component instance and not a ReactElement.TestUtils.Simulate will not work if you are using shallow rendering.",
Remove method name prefix from warnings and errors (#28432) This pattern is a petpeeve of mine. I don't consider this best practice and so most don't have these prefixes. Very inconsistent. At best this is useless and noisey that you have to parse because the information is also in the stack trace. At worse these are misleading because they're highlighting something internal (like validateDOMNesting) which even suggests an internal bug. Even the ones public to React aren't necessarily what you called because you might be calling a wrapper around it. That would be properly reflected in a stack trace - which can also properly ignore list so that the first stack you see is your callsite, Which might be like `render()` in react-testing-library rather than `createRoot()` for example.
2024-02-23 15:16:54 -05:00
"15": "instance must be a composite component",
Add a gulp script for extracting error codes (#6882)
2016-06-01 11:21:26 -07:00
"16": "Do not override existing functions.",
"17": "All native instances should have a tag.",
"18": "Expected a component class, got %s.%s",
"19": "Expect a native root tag, instead got %s",
"20": "RawText \"%s\" must be wrapped in an explicit <Text> component.",
Remove method name prefix from warnings and errors (#28432) This pattern is a petpeeve of mine. I don't consider this best practice and so most don't have these prefixes. Very inconsistent. At best this is useless and noisey that you have to parse because the information is also in the stack trace. At worse these are misleading because they're highlighting something internal (like validateDOMNesting) which even suggests an internal bug. Even the ones public to React aren't necessarily what you called because you might be calling a wrapper around it. That would be properly reflected in a stack trace - which can also properly ignore list so that the first stack you see is your callsite, Which might be like `render()` in react-testing-library rather than `createRoot()` for example.
2024-02-23 15:16:54 -05:00
"21": "Argument is not a component (type: %s, keys: %s)",
"22": "Unable to find node handle for unmounted component.",
Add a gulp script for extracting error codes (#6882)
2016-06-01 11:21:26 -07:00
"23": "onlyChild must be passed a children with exactly one child.",
"24": "Mismatched list of contexts in callback queue",
"25": "Trying to release an instance into a pool of a different type.",
"26": "Unexpected node: %s",
Remove method name prefix from warnings and errors (#28432) This pattern is a petpeeve of mine. I don't consider this best practice and so most don't have these prefixes. Very inconsistent. At best this is useless and noisey that you have to parse because the information is also in the stack trace. At worse these are misleading because they're highlighting something internal (like validateDOMNesting) which even suggests an internal bug. Even the ones public to React aren't necessarily what you called because you might be calling a wrapper around it. That would be properly reflected in a stack trace - which can also properly ignore list so that the first stack you see is your callsite, Which might be like `render()` in react-testing-library rather than `createRoot()` for example.
2024-02-23 15:16:54 -05:00
"27": "Cannot initialize a transaction when there is already an outstanding transaction.",
Add a gulp script for extracting error codes (#6882)
2016-06-01 11:21:26 -07:00
"28": "Transaction.closeAll(): Cannot close transaction when none are open.",
Remove method name prefix from warnings and errors (#28432) This pattern is a petpeeve of mine. I don't consider this best practice and so most don't have these prefixes. Very inconsistent. At best this is useless and noisey that you have to parse because the information is also in the stack trace. At worse these are misleading because they're highlighting something internal (like validateDOMNesting) which even suggests an internal bug. Even the ones public to React aren't necessarily what you called because you might be calling a wrapper around it. That would be properly reflected in a stack trace - which can also properly ignore list so that the first stack you see is your callsite, Which might be like `render()` in react-testing-library rather than `createRoot()` for example.
2024-02-23 15:16:54 -05:00
"29": "Accumulated items must be not be null or undefined.",
"30": "Accumulated items must not be null or undefined.",
Avoid passing custom stacks to console.error (#18685) * Detect double stacks in the new format in tests * Remove unnecessary uses of getStackByFiberInDevAndProd These all execute in the right execution context already. * Set the debug fiber around the cases that don't have an execution context * Remove stack detection in our console log overrides We never pass custom stacks as part of the args anymore. * Bonus: Don't append getStackAddendum to invariants We print component stacks for every error anyway so this is just duplicate information.
2020-04-21 09:22:46 -07:00
"31": "Objects are not valid as a React child (found: %s). If you meant to render a collection of children, use an array instead.",
Add a gulp script for extracting error codes (#6882)
2016-06-01 11:21:26 -07:00
"32": "Unable to find element with ID %s.",
"33": "getNodeFromInstance: Invalid argument.",
"34": "React DOM tree root should always have a node reference.",
"35": "isAncestor: Invalid argument.",
"36": "getParentInstance: Invalid argument.",
Remove method name prefix from warnings and errors (#28432) This pattern is a petpeeve of mine. I don't consider this best practice and so most don't have these prefixes. Very inconsistent. At best this is useless and noisey that you have to parse because the information is also in the stack trace. At worse these are misleading because they're highlighting something internal (like validateDOMNesting) which even suggests an internal bug. Even the ones public to React aren't necessarily what you called because you might be calling a wrapper around it. That would be properly reflected in a stack trace - which can also properly ignore list so that the first stack you see is your callsite, Which might be like `render()` in react-testing-library rather than `createRoot()` for example.
2024-02-23 15:16:54 -05:00
"37": "_Target container is not a DOM element.",
Add a gulp script for extracting error codes (#6882)
2016-06-01 11:21:26 -07:00
"38": "parentComponent must be a valid React Component",
"39": "ReactDOM.render(): Invalid component element.%s",
Remove method name prefix from warnings and errors (#28432) This pattern is a petpeeve of mine. I don't consider this best practice and so most don't have these prefixes. Very inconsistent. At best this is useless and noisey that you have to parse because the information is also in the stack trace. At worse these are misleading because they're highlighting something internal (like validateDOMNesting) which even suggests an internal bug. Even the ones public to React aren't necessarily what you called because you might be calling a wrapper around it. That would be properly reflected in a stack trace - which can also properly ignore list so that the first stack you see is your callsite, Which might be like `render()` in react-testing-library rather than `createRoot()` for example.
2024-02-23 15:16:54 -05:00
"40": "Target container is not a DOM element.",
"41": "Target container is not valid.",
Add a gulp script for extracting error codes (#6882)
2016-06-01 11:21:26 -07:00
"42": "You're trying to render a component to the document using server rendering but the checksum was invalid. This usually means you rendered a different component type or props on the client from the one on the server, or your render() methods are impure. React cannot handle this case due to cross-browser quirks by rendering at the document root. You should look for environment dependent code in your components and ensure the props are the same client and server side:\n%s",
"43": "You're trying to render a component to the document but you didn't use server rendering. We can't do this without using server rendering due to cross-browser quirks. See ReactDOMServer.renderToString() for server rendering.",
"44": "findDOMNode was called on an unmounted component.",
"45": "Element appears to be neither ReactComponent nor DOMNode (keys: %s)",
"46": "renderToString(): You must pass a valid ReactElement.",
"47": "renderToStaticMarkup(): You must pass a valid ReactElement.",
Remove method name prefix from warnings and errors (#28432) This pattern is a petpeeve of mine. I don't consider this best practice and so most don't have these prefixes. Very inconsistent. At best this is useless and noisey that you have to parse because the information is also in the stack trace. At worse these are misleading because they're highlighting something internal (like validateDOMNesting) which even suggests an internal bug. Even the ones public to React aren't necessarily what you called because you might be calling a wrapper around it. That would be properly reflected in a stack trace - which can also properly ignore list so that the first stack you see is your callsite, Which might be like `render()` in react-testing-library rather than `createRoot()` for example.
2024-02-23 15:16:54 -05:00
"48": "You're trying to inject DOM property '%s' which has already been injected. You may be accidentally injecting the same DOM property config twice, or you may be injecting two configs that have conflicting property names.",
Add a gulp script for extracting error codes (#6882)
2016-06-01 11:21:26 -07:00
"49": "DOMProperty: Properties that have side effects must use property: %s",
"50": "DOMProperty: Value can be one of boolean, overloaded boolean, or numeric value, but not a combination: %s",
Remove method name prefix from warnings and errors (#28432) This pattern is a petpeeve of mine. I don't consider this best practice and so most don't have these prefixes. Very inconsistent. At best this is useless and noisey that you have to parse because the information is also in the stack trace. At worse these are misleading because they're highlighting something internal (like validateDOMNesting) which even suggests an internal bug. Even the ones public to React aren't necessarily what you called because you might be calling a wrapper around it. That would be properly reflected in a stack trace - which can also properly ignore list so that the first stack you see is your callsite, Which might be like `render()` in react-testing-library rather than `createRoot()` for example.
2024-02-23 15:16:54 -05:00
"51": "Cannot render markup in a worker thread. Make sure `window` and `document` are available globally before requiring React when unit testing or use ReactDOMServer.renderToString for server rendering.",
"52": "Missing markup.",
Add a gulp script for extracting error codes (#6882)
2016-06-01 11:21:26 -07:00
"53": "Danger: Assigning to an already-occupied result index.",
"54": "Danger: Did not assign to every index of resultList.",
"55": "Danger: Expected markup to render %s nodes, but rendered %s.",
Remove method name prefix from warnings and errors (#28432) This pattern is a petpeeve of mine. I don't consider this best practice and so most don't have these prefixes. Very inconsistent. At best this is useless and noisey that you have to parse because the information is also in the stack trace. At worse these are misleading because they're highlighting something internal (like validateDOMNesting) which even suggests an internal bug. Even the ones public to React aren't necessarily what you called because you might be calling a wrapper around it. That would be properly reflected in a stack trace - which can also properly ignore list so that the first stack you see is your callsite, Which might be like `render()` in react-testing-library rather than `createRoot()` for example.
2024-02-23 15:16:54 -05:00
"56": "Cannot render markup in a worker thread. Make sure `window` and `document` are available globally before requiring React when unit testing or use ReactDOMServer.renderToString() for server rendering.",
"57": "Missing markup.",
"58": "Cannot replace markup of the <html> node. This is because browser quirks make this unreliable and/or slow. If you want to render to the root you must use server rendering. See ReactDOMServer.renderToString().",
Avoid passing custom stacks to console.error (#18685) * Detect double stacks in the new format in tests * Remove unnecessary uses of getStackByFiberInDevAndProd These all execute in the right execution context already. * Set the debug fiber around the cases that don't have an execution context * Remove stack detection in our console log overrides We never pass custom stacks as part of the args anymore. * Bonus: Don't append getStackAddendum to invariants We print component stacks for every error anyway so this is just duplicate information.
2020-04-21 09:22:46 -07:00
"59": "%s is a void element tag and must not have `children` or use `props.dangerouslySetInnerHTML`.",
Add a gulp script for extracting error codes (#6882)
2016-06-01 11:21:26 -07:00
"60": "Can only set one of `children` or `props.dangerouslySetInnerHTML`.",
Update /link URLs to react.dev (#28477) Depends on https://github.com/reactjs/react.dev/pull/6670 [merged]
2024-03-03 17:34:33 -05:00
"61": "`props.dangerouslySetInnerHTML` must be in the form `{__html: ...}`. Please visit https://react.dev/link/dangerously-set-inner-html for more information.",
Avoid passing custom stacks to console.error (#18685) * Detect double stacks in the new format in tests * Remove unnecessary uses of getStackByFiberInDevAndProd These all execute in the right execution context already. * Set the debug fiber around the cases that don't have an execution context * Remove stack detection in our console log overrides We never pass custom stacks as part of the args anymore. * Bonus: Don't append getStackAddendum to invariants We print component stacks for every error anyway so this is just duplicate information.
2020-04-21 09:22:46 -07:00
"62": "The `style` prop expects a mapping from style properties to values, not a string. For example, style={{marginRight: spacing + 'em'}} when using JSX.",
Add a gulp script for extracting error codes (#6882)
2016-06-01 11:21:26 -07:00
"63": "Must be mounted to trap events",
Remove method name prefix from warnings and errors (#28432) This pattern is a petpeeve of mine. I don't consider this best practice and so most don't have these prefixes. Very inconsistent. At best this is useless and noisey that you have to parse because the information is also in the stack trace. At worse these are misleading because they're highlighting something internal (like validateDOMNesting) which even suggests an internal bug. Even the ones public to React aren't necessarily what you called because you might be calling a wrapper around it. That would be properly reflected in a stack trace - which can also properly ignore list so that the first stack you see is your callsite, Which might be like `render()` in react-testing-library rather than `createRoot()` for example.
2024-02-23 15:16:54 -05:00
"64": "Requires node to be rendered.",
Add a gulp script for extracting error codes (#6882)
2016-06-01 11:21:26 -07:00
"65": "Invalid tag: %s",
"66": "<%s> tried to unmount. Because of cross-browser quirks it is impossible to unmount some top-level components (eg <html>, <head>, and <body>) reliably and efficiently. To fix this, have a single top-level component that never unmounts render these elements.",
"67": "Missing closing comment for text component %s",
"68": "Expected devtool events to fire for the child before its parent includes it in onSetChildren().",
"69": "Expected onSetDisplayName() to fire for the child before its parent includes it in onSetChildren().",
"70": "Expected onSetChildren() or onSetText() to fire for the child before its parent includes it in onSetChildren().",
"71": "Expected onMountComponent() to fire for the child before its parent includes it in onSetChildren().",
"72": "Expected onSetParent() and onSetChildren() to be consistent (%s has parents %s and %s).",
"73": "ReactClassInterface: You are attempting to override `%s` from your class specification. Ensure that your method names do not overlap with React methods.",
"74": "ReactClassInterface: You are attempting to define `%s` on your component more than once. This conflict may be due to a mixin.",
"75": "ReactClass: You're attempting to use a component class or function as a mixin. Instead, just use a regular object.",
"76": "ReactClass: You're attempting to use a component as a mixin. Instead, just use a regular object.",
"77": "ReactClass: Unexpected spec policy %s for key %s when mixing in component specs.",
"78": "ReactClass: You are attempting to define a reserved property, `%s`, that shouldn't be on the \"statics\" key. Define it as an instance property instead; it will still be accessible on the constructor.",
"79": "ReactClass: You are attempting to define `%s` on your component more than once. This conflict may be due to a mixin.",
"80": "mergeIntoWithNoDuplicateKeys(): Cannot merge non-objects.",
"81": "mergeIntoWithNoDuplicateKeys(): Tried to merge two objects with the same key: `%s`. This conflict may be due to a mixin; in particular, this may be caused by two getInitialState() or getDefaultProps() methods returning objects with clashing keys.",
"82": "%s.getInitialState(): must return an object or null",
Remove method name prefix from warnings and errors (#28432) This pattern is a petpeeve of mine. I don't consider this best practice and so most don't have these prefixes. Very inconsistent. At best this is useless and noisey that you have to parse because the information is also in the stack trace. At worse these are misleading because they're highlighting something internal (like validateDOMNesting) which even suggests an internal bug. Even the ones public to React aren't necessarily what you called because you might be calling a wrapper around it. That would be properly reflected in a stack trace - which can also properly ignore list so that the first stack you see is your callsite, Which might be like `render()` in react-testing-library rather than `createRoot()` for example.
2024-02-23 15:16:54 -05:00
"83": "Class specification must implement a `render` method.",
Add a gulp script for extracting error codes (#6882)
2016-06-01 11:21:26 -07:00
"84": "%s: %s type `%s` is invalid; it must be a function, usually from React.PropTypes.",
Remove method name prefix from warnings and errors (#28432) This pattern is a petpeeve of mine. I don't consider this best practice and so most don't have these prefixes. Very inconsistent. At best this is useless and noisey that you have to parse because the information is also in the stack trace. At worse these are misleading because they're highlighting something internal (like validateDOMNesting) which even suggests an internal bug. Even the ones public to React aren't necessarily what you called because you might be calling a wrapper around it. That would be properly reflected in a stack trace - which can also properly ignore list so that the first stack you see is your callsite, Which might be like `render()` in react-testing-library rather than `createRoot()` for example.
2024-02-23 15:16:54 -05:00
"85": "takes an object of state variables to update or a function which returns an object of state variables.",
Add a gulp script for extracting error codes (#6882)
2016-06-01 11:21:26 -07:00
"86": "SimpleEventPlugin: Unhandled event type, `%s`.",
"87": "Cannot provide a checkedLink and a valueLink. If you want to use checkedLink, you probably don't want to use valueLink and vice versa.",
"88": "Cannot provide a valueLink and a value or onChange event. If you want to use value or onChange, you probably don't want to use valueLink.",
"89": "Cannot provide a checkedLink and a checked property or onChange event. If you want to use checked or onChange, you probably don't want to use checkedLink",
"90": "ReactDOMInput: Mixing React and non-React radio inputs with the same `name` is not supported.",
"91": "`dangerouslySetInnerHTML` does not make sense on <textarea>.",
"92": "If you supply `defaultValue` on a <textarea>, do not pass children.",
"93": "<textarea> can only have at most one child.",
"94": "Expected %s listener to be a function, instead got type %s",
"95": "processEventQueue(): Additional events were enqueued while processing an event queue. Support for this has not yet been implemented.",
"96": "EventPluginRegistry: Cannot inject event plugins that do not exist in the plugin ordering, `%s`.",
"97": "EventPluginRegistry: Event plugins must implement an `extractEvents` method, but `%s` does not.",
"98": "EventPluginRegistry: Failed to publish event `%s` for plugin `%s`.",
Refactor DOM plugin system to single module (#18025)
2020-02-14 08:10:42 +00:00
"99": "EventPluginRegistry: More than one plugin attempted to publish the same event name, `%s`.",
"100": "EventPluginRegistry: More than one plugin attempted to publish the same registration name, `%s`.",
Add a gulp script for extracting error codes (#6882)
2016-06-01 11:21:26 -07:00
"101": "EventPluginRegistry: Cannot inject event plugin ordering more than once. You are likely trying to load more than one copy of React.",
"102": "EventPluginRegistry: Cannot inject two different event plugins using the same name, `%s`.",
Remove method name prefix from warnings and errors (#28432) This pattern is a petpeeve of mine. I don't consider this best practice and so most don't have these prefixes. Very inconsistent. At best this is useless and noisey that you have to parse because the information is also in the stack trace. At worse these are misleading because they're highlighting something internal (like validateDOMNesting) which even suggests an internal bug. Even the ones public to React aren't necessarily what you called because you might be calling a wrapper around it. That would be properly reflected in a stack trace - which can also properly ignore list so that the first stack you see is your callsite, Which might be like `render()` in react-testing-library rather than `createRoot()` for example.
2024-02-23 15:16:54 -05:00
"103": "Invalid `event`.",
Add a gulp script for extracting error codes (#6882)
2016-06-01 11:21:26 -07:00
"104": "ReactCompositeComponent: injectEnvironment() can only be called once.",
Remove method name prefix from warnings and errors (#28432) This pattern is a petpeeve of mine. I don't consider this best practice and so most don't have these prefixes. Very inconsistent. At best this is useless and noisey that you have to parse because the information is also in the stack trace. At worse these are misleading because they're highlighting something internal (like validateDOMNesting) which even suggests an internal bug. Even the ones public to React aren't necessarily what you called because you might be calling a wrapper around it. That would be properly reflected in a stack trace - which can also properly ignore list so that the first stack you see is your callsite, Which might be like `render()` in react-testing-library rather than `createRoot()` for example.
2024-02-23 15:16:54 -05:00
"105": "A valid React element (or null) must be returned. You may have returned undefined, an array or some other invalid object.",
Add a gulp script for extracting error codes (#6882)
2016-06-01 11:21:26 -07:00
"106": "%s.state: must be set to an object or null",
"107": "%s.getChildContext(): childContextTypes must be defined in order to use getChildContext().",
"108": "%s.getChildContext(): key \"%s\" is not defined in childContextTypes.",
"109": "%s.render(): A valid React element (or null) must be returned. You may have returned undefined, an array or some other invalid object.",
"110": "Stateless function components cannot have refs.",
"111": "There is no registered component for the tag %s",
"112": "getNextDescendantID(%s, %s): Received an invalid React DOM ID.",
Remove method name prefix from warnings and errors (#28432) This pattern is a petpeeve of mine. I don't consider this best practice and so most don't have these prefixes. Very inconsistent. At best this is useless and noisey that you have to parse because the information is also in the stack trace. At worse these are misleading because they're highlighting something internal (like validateDOMNesting) which even suggests an internal bug. Even the ones public to React aren't necessarily what you called because you might be calling a wrapper around it. That would be properly reflected in a stack trace - which can also properly ignore list so that the first stack you see is your callsite, Which might be like `render()` in react-testing-library rather than `createRoot()` for example.
2024-02-23 15:16:54 -05:00
"113": "React has made an invalid assumption about the DOM hierarchy. Expected `%s` to be an ancestor of `%s`.",
Add a gulp script for extracting error codes (#6882)
2016-06-01 11:21:26 -07:00
"114": "getFirstCommonAncestorID(%s, %s): Expected a valid React DOM ID: %s",
Remove method name prefix from warnings and errors (#28432) This pattern is a petpeeve of mine. I don't consider this best practice and so most don't have these prefixes. Very inconsistent. At best this is useless and noisey that you have to parse because the information is also in the stack trace. At worse these are misleading because they're highlighting something internal (like validateDOMNesting) which even suggests an internal bug. Even the ones public to React aren't necessarily what you called because you might be calling a wrapper around it. That would be properly reflected in a stack trace - which can also properly ignore list so that the first stack you see is your callsite, Which might be like `render()` in react-testing-library rather than `createRoot()` for example.
2024-02-23 15:16:54 -05:00
"115": "Cannot traverse from and to the same ID, `%s`.",
Add a gulp script for extracting error codes (#6882)
2016-06-01 11:21:26 -07:00
"116": "traverseParentPath(%s, %s, ...): Cannot traverse from two IDs that do not have a parent path.",
"117": "traverseParentPath(%s, %s, ...): Detected an infinite loop while traversing the React DOM ID tree. This may be due to malformed IDs: %s",
"118": "updateTextContent called on non-empty component.",
Update /link URLs to react.dev (#28477) Depends on https://github.com/reactjs/react.dev/pull/6670 [merged]
2024-03-03 17:34:33 -05:00
"119": "Only a ReactOwner can have refs. You might be adding a ref to a component that was not created inside a component's `render` method, or you have multiple copies of React loaded (details: https://react.dev/link/refs-must-have-owner).",
"120": "Only a ReactOwner can have refs. You might be removing a ref to a component that was not created inside a component's `render` method, or you have multiple copies of React loaded (details: https://react.dev/link/refs-must-have-owner).",
Add a gulp script for extracting error codes (#6882)
2016-06-01 11:21:26 -07:00
"121": "performUpdateIfNecessary: Unexpected batch number (current %s, pending %s)",
"122": "%s(...): Expected the last optional `callback` argument to be a function. Instead received: %s.",
"123": "ReactUpdates: must inject a reconcile transaction class and batching strategy",
"124": "Expected flush transaction's stored dirty-components length (%s) to match dirty-components array length (%s).",
Revert "Revert "Missing a space for error 125"" (#8995)
2017-02-13 17:15:08 -06:00
"125": "ReactUpdates.asap: Can't enqueue an asap callback in a context where updates are not being batched.",
Add a gulp script for extracting error codes (#6882)
2016-06-01 11:21:26 -07:00
"126": "ReactUpdates: must provide a reconcile transaction class",
"127": "ReactUpdates: must provide a batching strategy",
"128": "ReactUpdates: must provide a batchedUpdates() function",
"129": "ReactUpdates: must provide an isBatchingUpdates boolean attribute",
"130": "Element type is invalid: expected a string (for built-in components) or a class/function (for composite components) but got: %s.%s",
"131": "Encountered invalid React node of type %s",
"132": "Ended a touch event which was not counted in trackedTouchCount.",
"133": "Touch object is missing identifier",
"134": "Touch data should have been recorded on start",
Fix error codes (#7999) * took codes.json from the 15-dev branch * fixed react:extract-errors task in gulpfile * generated error codes * Revert "generated error codes" This reverts commit b8f3aeed9d8f0d469edd5f6623fa6090930594d8. * Added a README for the error code system
2016-11-08 15:20:46 -05:00
"135": "Cannot find single active touch",
"136": "Attempted to update component `%s` that has already been unmounted (or failed to mount).",
Avoid passing custom stacks to console.error (#18685) * Detect double stacks in the new format in tests * Remove unnecessary uses of getStackByFiberInDevAndProd These all execute in the right execution context already. * Set the debug fiber around the cases that don't have an execution context * Remove stack detection in our console log overrides We never pass custom stacks as part of the args anymore. * Bonus: Don't append getStackAddendum to invariants We print component stacks for every error anyway so this is just duplicate information.
2020-04-21 09:22:46 -07:00
"137": "%s is a void element tag and must neither have `children` nor use `dangerouslySetInnerHTML`.",
Fix error codes (#7999) * took codes.json from the 15-dev branch * fixed react:extract-errors task in gulpfile * generated error codes * Revert "generated error codes" This reverts commit b8f3aeed9d8f0d469edd5f6623fa6090930594d8. * Added a README for the error code system
2016-11-08 15:20:46 -05:00
"138": "Touch object is missing identifier.",
"139": "ReactTestRenderer: .update() can't be called after unmount.",
"140": "Expected hook events to fire for the child before its parent includes it in onSetChildren().",
"141": "Expected onSetChildren() to fire for a container child before its parent includes it in onSetChildren().",
"142": "Expected onBeforeMountComponent() parent and onSetChildren() to be consistent (%s has parents %s and %s).",
Fix PropTypes production test so it works with error code system
2017-03-02 16:12:50 -08:00
"143": "React.Children.only expected to receive a single React element child.",
Updated error codes (after merging in missing code from 15 stable) (#10290)
2017-07-26 12:18:02 -07:00
"144": "Item must have been set",
"145": "hostContainerInfo should be populated before getPublicInstance is called.",
"146": "React Component in warnForMissingKey should have a _store. This error is likely caused by a bug in React. Please file an issue.",
"147": "Missing owner for string ref %s. This error is likely caused by a bug in React. Please file an issue.",
"148": "Expected ref to be a function or a string.",
Update /link URLs to react.dev (#28477) Depends on https://github.com/reactjs/react.dev/pull/6670 [merged]
2024-03-03 17:34:33 -05:00
"149": "Element ref was specified as a string (%s) but no owner was set. You may have multiple copies of React loaded. (details: https://react.dev/link/refs-must-have-owner).",
Updated error codes (after merging in missing code from 15 stable) (#10290)
2017-07-26 12:18:02 -07:00
"150": "An object is not an iterable. This error is likely caused by a bug in React. Please file an issue.",
"151": "An iterable object provided no iterator.",
Remove method name prefix from warnings and errors (#28432) This pattern is a petpeeve of mine. I don't consider this best practice and so most don't have these prefixes. Very inconsistent. At best this is useless and noisey that you have to parse because the information is also in the stack trace. At worse these are misleading because they're highlighting something internal (like validateDOMNesting) which even suggests an internal bug. Even the ones public to React aren't necessarily what you called because you might be calling a wrapper around it. That would be properly reflected in a stack trace - which can also properly ignore list so that the first stack you see is your callsite, Which might be like `render()` in react-testing-library rather than `createRoot()` for example.
2024-02-23 15:16:54 -05:00
"152": "Nothing was returned from render. This usually means a return statement is missing. Or, to render nothing, return null.",
Updated error codes (after merging in missing code from 15 stable) (#10290)
2017-07-26 12:18:02 -07:00
"153": "Resuming work not yet implemented.",
"154": "We should always have pending or current props. This error is likely caused by a bug in React. Please file an issue.",
"155": "An indeterminate component should never have mounted. This error is likely caused by a bug in React. Please file an issue.",
Include tag in begin/complete invariant (#16881)
2019-09-25 08:10:35 -07:00
"156": "Unknown unit of work tag (%s). This error is likely caused by a bug in React. Please file an issue.",
Updated error codes (after merging in missing code from 15 stable) (#10290)
2017-07-26 12:18:02 -07:00
"157": "Invalid type of work. This error is likely caused by a bug in React. Please file an issue.",
"158": "There must be pending props for an initial mount. This error is likely caused by a bug in React. Please file an issue.",
"159": "There should always be pending or memoized props. This error is likely caused by a bug in React. Please file an issue.",
"160": "Expected to find a host parent. This error is likely caused by a bug in React. Please file an issue.",
"161": "Invalid host parent fiber. This error is likely caused by a bug in React. Please file an issue.",
"162": "This should have a text node initialized. This error is likely caused by a bug in React. Please file an issue.",
"163": "This unit of work tag should not have side-effects. This error is likely caused by a bug in React. Please file an issue.",
"164": "A coroutine cannot have host component children.",
"165": "Should be resolved by now. This error is likely caused by a bug in React. Please file an issue.",
"166": "We must have new props for new mounts. This error is likely caused by a bug in React. Please file an issue.",
"167": "An indeterminate component should have become determinate before completing. This error is likely caused by a bug in React. Please file an issue.",
"168": "Unexpected context found on stack. This error is likely caused by a bug in React. Please file an issue.",
"169": "Expected to have an instance by this point. This error is likely caused by a bug in React. Please file an issue.",
"170": "Expected subtree parent to be a mounted class component. This error is likely caused by a bug in React. Please file an issue.",
"171": "Found unexpected detached subtree parent. This error is likely caused by a bug in React. Please file an issue.",
"172": "The custom dialog was already injected.",
"173": "Injected showDialog() must be a function.",
"174": "Expected host context to exist. This error is likely caused by a bug in React. Please file an issue.",
"175": "Expected prepareToHydrateHostInstance() to never be called. This error is likely caused by a bug in React. Please file an issue.",
"176": "Expected prepareToHydrateHostTextInstance() to never be called. This error is likely caused by a bug in React. Please file an issue.",
Invariant that throws when committing wrong tree (#15517) If React finishes rendering a tree, delays committing it (e.g. Suspense), then subsequently starts over or renders a new tree, the pending tree is no longer valid. That's because rendering a new work-in progress mutates the old one in place. The current structure of the work loop makes this hard to reason about because, although `renderRoot` and `commitRoot` are separate functions, they can't be interleaved. If they are interleaved by accident, it either results in inconsistent render output or invariant violations that are hard to debug. This commit adds an invariant that throws if the new tree is the same as the old one. This won't prevent all bugs of this class, but it should catch the most common kind. To implement the invariant, I store the finished tree on a field on the root. We already had a field for this, but it was only being used for the unstable `createBatch` feature. A more rigorous way to address this type of problem could be to unify `renderRoot` and `commitRoot` into a single function, so that it's harder to accidentally interleave the two phases. I plan to do something like this in a follow-up.
2019-05-13 16:15:50 -07:00
"177": "Cannot commit the same tree as before. This error is likely caused by a bug in React. Please file an issue.",
Updated error codes (after merging in missing code from 15 stable) (#10290)
2017-07-26 12:18:02 -07:00
"178": "Should have next effect. This error is likely caused by a bug in React. Please file an issue.",
"179": "Should have a pending commit. This error is likely caused by a bug in React. Please file an issue.",
"180": "Commit phase errors should be scheduled to recover with task priority. This error is likely caused by a bug in React. Please file an issue.",
Fix spelling errors and typos (#19138)
2020-06-15 19:59:44 -04:00
"181": "Switch statement should be exhaustive. This error is likely caused by a bug in React. Please file an issue.",
Updated error codes (after merging in missing code from 15 stable) (#10290)
2017-07-26 12:18:02 -07:00
"182": "performWork was called recursively. This error is likely caused by a bug in React. Please file an issue.",
"183": "Should have found an error boundary. This error is likely caused by a bug in React. Please file an issue.",
"184": "No error for given unit of work. This error is likely caused by a bug in React. Please file an issue.",
"185": "Maximum update depth exceeded. This can happen when a component repeatedly calls setState inside componentWillUpdate or componentDidUpdate. React limits the number of nested updates to prevent infinite loops.",
"186": "Task updates can only be scheduled as a nested update or inside batchedUpdates.",
"187": "flushSync was called from inside a lifecycle method. It cannot be called when React is already rendering.",
"188": "Unable to find node on an unmounted component.",
"189": "Child was not found in either parent set. This indicates a bug in React related to the return pointer. Please file an issue.",
"190": "Return fibers should always be each others' alternates. This error is likely caused by a bug in React. Please file an issue.",
"191": "Invalid argument passed as callback. Expected a function. Instead received: %s",
"192": "React depends on requestAnimationFrame. Make sure that you load a polyfill in older browsers.",
"193": "The server renderer does not implement support for array children yet.",
"194": "Fiber needs to be injected to handle a fiber target for controlled events. This error is likely caused by a bug in React. Please file an issue.",
"195": "The internal instance must be a React host component. This error is likely caused by a bug in React. Please file an issue.",
"196": "Missing injection for fiber getContextForSubtree",
"197": "Injected invokeGuardedCallback() must be a function.",
Built 16.0.0 beta 3. Updated versions, results.json, and error codes
2017-08-03 16:05:28 -07:00
"198": "clearCaughtError was called but no error was captured. This error is likely caused by a bug in React. Please file an issue.",
"199": "Fiber owners should not show up in Stack stack traces.",
"200": "Target container is not a DOM element.",
"201": "ReactDOM.render(): Invalid component element. Instead of passing a string like 'div', pass React.createElement('div') or <div />.",
"202": "ReactDOM.render(): Invalid component element. Instead of passing a class like Foo, pass React.createElement(Foo) or <Foo />.",
"203": "ReactDOM.render(): Invalid component element. This may be caused by unintentionally loading two independent copies of React.",
"204": "ReactDOM.render(): Invalid component element.",
Fix for #10388. Renames renderToStream to renderToNodeStream. (#10425)
2017-08-10 12:23:00 -07:00
"205": "renderToNodeStream(): Invalid component element.",
"206": "renderToStaticNodeStream(): Invalid component element.",
"207": "ReactDOMServer.renderToNodeStream(): The streaming API is not available in the browser. Use ReactDOMServer.renderToString() instead.",
"208": "ReactDOMServer.renderToStaticNodeStream(): The streaming API is not available in the browser. Use ReactDOMServer.renderToStaticMarkup() instead.",
Built 16.0.0 beta 3. Updated versions, results.json, and error codes
2017-08-03 16:05:28 -07:00
"209": "renderToString(): Invalid component element.",
"210": "renderToStaticMarkup(): Invalid component element.",
"211": "Missing injection for fiber findDOMNode",
"212": "Missing injection for stack findDOMNode",
"213": "Element appears to be neither ReactComponent nor DOMNode. Keys: %s",
"214": "toTree() does not yet know how to handle nodes with tag=%s",
"215": "something went wrong",
"216": "Text children should already be flattened.",
"217": "ReactART does not support the type \"%s\"",
"218": "ReactART: Can not insert node before itself",
"219": "getInspectorDataForViewTag() is not available in production",
"220": "Container does not support insertBefore operation",
"221": "Tried to register two views with the same name %s",
16 beta 5 version bump and results JSON
2017-08-08 10:25:25 -07:00
"222": "View config not found for name %s",
"224": "Can't read from currently-mounting component. This error is likely caused by a bug in React. Please file an issue.",
"225": "Unexpected object passed to ReactTestInstance constructor (tag: %s). This is probably a bug in React.",
Update error codes and results.json (#10619) * Update results.json **what is the change?:** Ran the build after updating Yarn lockfile and recorded latest build size results. **why make this change?:** Let's get an idea of bundle size at this point, when we are preparing the 16.0 RC. **test plan:** NA **issue:** https://github.com/facebook/react/issues/8854 * Update error codes https://github.com/facebook/react/tree/master/scripts/release-manager#update-the-error-codes
2017-09-06 11:11:19 -07:00
"226": "Unsupported component type %s in test renderer. This is probably a bug in React.",
"227": "ReactDOM was loaded before React. Make sure you load the React package before loading ReactDOM.",
"228": "TestUtils.Simulate expected a DOM node as the first argument but received a React element. Pass the DOM node you wish to simulate the event on instead. Note that TestUtils.Simulate will not work if you are using shallow rendering.",
"229": "TestUtils.Simulate expected a DOM node as the first argument but received a component instance. Pass the DOM node you wish to simulate the event on instead.",
"230": "_processChildContext is not available in React 16+. This likely means you have multiple copies of React and are attempting to nest a React 15 tree inside a React 16 tree using unstable_renderSubtreeIntoContainer, which isn't supported. Try to make sure you have only one copy of React (and ideally, switch to ReactDOM.unstable_createPortal).",
Update error codes
2017-09-14 13:37:26 +01:00
"231": "Expected `%s` listener to be a function, instead got a value of `%s` type.",
"232": "_processChildContext is not available in React 16+. This likely means you have multiple copies of React and are attempting to nest a React 15 tree inside a React 16 tree using unstable_renderSubtreeIntoContainer, which isn't supported. Try to make sure you have only one copy of React (and ideally, switch to ReactDOM.createPortal).",
Update error codes
2017-09-26 08:44:21 -07:00
"233": "Unsupported top level event type \"%s\" dispatched",
[CS] Persistent Updates (#11260) * Update build size * [CS] Clone container instead of new root concept The extra "root" concept is kind of unnecessary. Instead of having a mutable container even in the persistent mode, I'll instead make the container be immutable too and be cloned. Then the "commit" just becomes swapping the previous container for the new one. * Change the signature or persistence again We may need to clone without any updates, e.g. when the children are changed. Passing in the previous node is not enough to recycle since it won't have the up-to-date props and children. It's really only useful to for allocation pooling. * Implement persistent updates This forks the update path for host fibers. For mutation mode we mark them as having an effect. For persistence mode, we clone the stateNode with new props/children. Next I'll do HostRoot and HostPortal. * Refine protocol into a complete and commit phase finalizeContainerChildren will get called at the complete phase. replaceContainer will get called at commit. Also, drop the keepChildren flag. We'll never keep children as we'll never update a container if none of the children has changed. * Implement persistent updates of roots and portals These are both "containers". Normally we rely on placement/deletion effects to deal with insertions into the containers. In the persistent mode we need to clone the container and append all the changed children to it. I needed somewhere to store these new containers before they're committed so I added another field. * Commit persistent work at the end by swapping out the container * Unify cloneOrRecycle Originally I tried to make the recyclable instance nullable but Flow didn't like that and it's kind of sketchy since the instance type might not be nullable. However, the real difference which one we call is depending on whether they are equal. We can just offload that to the renderer. Most of them won't need to know about this at all since they'll always clone or just create new. The ones that do know now have to be careful to compare them so they don't reuse an existing instance but that's probably fine to simplify the implementation and API. * Add persistent noop renderer for testing * Add basic persistent tree test * Test bail out This adds a test for bailouts. This revealed a subtle bug. We don't set the return pointer when stepping into newly created fibers because there can only be one. However, since I'm reusing this mechanism for persistent updates, I'll need to set the return pointer because a bailed out tree won't have the right return pointer. * Test persistent text nodes Found another bug. * Add persistent portal test This creates a bit of an unfortunate feature testing in the unmount branch. That's because we want to trigger nested host deletions in portals in the mutation mode. * Don't consider container when determining portal identity Basically, we can't use the container to determine if we should keep identity and update an existing portal instead of recreate it. Because for persistent containers, there is no permanent identity. This makes it kind of strange to even use portals in this mode. It's probably more ideal to have another concept that has permanent identity rather than trying to swap out containers. * Clear portals when the portal is deleted When a portal gets deleted we need to create a new empty container and replace the current one with the empty one. * Add renderer mode flags for dead code elimination * Simplify ReactNoop fix * Add new type to the host config for persistent configs We need container to stay as the persistent identity of the root atom. So that we can refer to portals over time. Instead, I'll introduce a new type just to temporarily hold the children of a container until they're ready to be committed into the permanent container. Essentially, this is just a fancy array that is not an array so that the host can choose data structure/allocation for it. * Implement new hooks Now containers are singletons and instead their children swap. That way portals can use the container as part of their identity again. * Update build size and error codes * Address comment * Move new files to new location
2017-10-18 18:28:23 -07:00
"234": "Event cannot be both direct and bubbling: %s",
"235": "Persistent reconciler is disabled.",
"236": "Noop reconciler is disabled.",
"237": "Mutating reconciler is disabled.",
"238": "Task updates can only be scheduled as a nested update or inside batchedUpdates. This error is likely caused by a bug in React. Please file an issue.",
"239": "Measure not implemented yet",
"240": "Text components are not supported for now.",
Update error codes for 16.1.0-beta release
2017-11-02 15:34:31 -07:00
"241": "Text components are not yet supported.",
"242": "%s: %s type `%s` is invalid; it must be a function, usually from the `prop-types` package, but received `%s`.",
"243": "renderRoot was called recursively. This error is likely caused by a bug in React. Please file an issue.",
"244": "Should have a previous and last root. This error is likely caused by a bug in React. Please file an issue.",
"245": "performWorkOnRoot was called recursively. This error is likely caused by a bug in React. Please file an issue.",
"246": "Should be working on a root. This error is likely caused by a bug in React. Please file an issue.",
Update error codes for 16.1.0-beta.1 release
2017-11-07 14:53:31 +00:00
"247": "A call cannot have host component children.",
"248": "Not implemented.",
Update error codes for 16.3.0-alpha.0 release
2018-02-02 13:01:33 -08:00
"249": "ReactShallowRenderer render(): Shallow rendering works only with custom components, but the provided element type was `%s`.",
"250": "batch.render: Cannot render a batch that already committed.",
"251": "batch.commit: Cannot commit a batch multiple times.",
"252": "The `document` global was defined when React was initialized, but is not defined anymore. This can happen in a test environment if a component schedules an update from an asynchronous callback, but the test has already finished running. To solve this, you can either unmount the component at the end of your test (and ensure that any asynchronous operations get canceled in `componentWillUnmount`), or you can change the test itself to be asynchronous.",
"253": "work.commit(): Cannot commit while already rendering. This likely means you attempted to commit from inside a lifecycle method.",
Update /link URLs to react.dev (#28477) Depends on https://github.com/reactjs/react.dev/pull/6670 [merged]
2024-03-03 17:34:33 -05:00
"254": "Element ref was specified as a string (%s) but no owner was set. This could happen for one of the following reasons:\n1. You may be adding a ref to a functional component\n2. You may be adding a ref to a component that was not created inside a component's render method\n3. You have multiple copies of React loaded\nSee https://react.dev/link/refs-must-have-owner for more information.",
Update error codes for 16.3.0-alpha.0 release
2018-02-02 13:01:33 -08:00
"255": "Expected ReactFbErrorUtils.invokeGuardedCallback to be a function.",
"257": "Portals are not currently supported by the server renderer. Render them conditionally so that they only appear on the client render.",
"258": "Unknown element-like object type: %s. This is likely a bug in React. Please file an issue.",
"259": "The experimental Call and Return types are not currently supported by the server renderer.",
Update error codes for 16.3.0-alpha.2 release
2018-03-14 13:26:40 -07:00
"260": "Element type is invalid: expected a string (for built-in components) or a class/function (for composite components) but got: %s.",
"261": "Cannot commit an incomplete root. This error is likely caused by a bug in React. Please file an issue.",
"262": "Expired work should have completed. This error is likely caused by a bug in React. Please file an issue.",
"263": "dispatch: Cannot dispatch during the render phase.",
"264": "An error logging effect should not have been scheduled if no errors were captured. This error is likely caused by a bug in React. Please file an issue.",
Fix double spaces. (#15641)
2019-05-28 11:34:18 -06:00
"265": "This unit of work tag cannot capture errors. This error is likely caused by a bug in React. Please file an issue.",
Update error codes for 16.3.2 release
2018-04-16 16:23:12 +01:00
"266": "A subscription must return an unsubscribe function.",
Remove method name prefix from warnings and errors (#28432) This pattern is a petpeeve of mine. I don't consider this best practice and so most don't have these prefixes. Very inconsistent. At best this is useless and noisey that you have to parse because the information is also in the stack trace. At worse these are misleading because they're highlighting something internal (like validateDOMNesting) which even suggests an internal bug. Even the ones public to React aren't necessarily what you called because you might be calling a wrapper around it. That would be properly reflected in a stack trace - which can also properly ignore list so that the first stack you see is your callsite, Which might be like `render()` in react-testing-library rather than `createRoot()` for example.
2024-02-23 15:16:54 -05:00
"267": "The argument must be a React element, but you passed %s.",
Record sizes
2018-05-13 21:12:25 +01:00
"268": "Argument appears to not be a ReactComponent. Keys: %s",
Update error codes for 16.4.0 release
2018-05-23 17:35:31 -07:00
"269": "Profiler must specify an \"id\" string and \"onRender\" function as props",
"270": "The current renderer does not support persistence. This error is likely caused by a bug in React. Please file an issue.",
"271": "Failed to replay rendering after an error. This is likely caused by a bug in React. Please file an issue with a reproducing case to help us find it.",
"273": "Nesting of <View> within <Text> is not currently supported.",
"274": "Text strings must be rendered within a <Text> component.",
Update error codes for 16.4.1 release
2018-06-13 17:20:35 +01:00
"275": "The current renderer does not support mutation. This error is likely caused by a bug in React. Please file an issue.",
Update /link URLs to react.dev (#28477) Depends on https://github.com/reactjs/react.dev/pull/6670 [merged]
2024-03-03 17:34:33 -05:00
"276": "React depends on requestAnimationFrame. Make sure that you load a polyfill in older browsers. https://react.dev/link/react-polyfills",
Update error codes for 16.5.0 release
2018-09-06 09:34:27 -07:00
"277": "Context.unstable_read(): Context can only be read while React is rendering, e.g. inside the render method or getDerivedStateFromProps.",
"278": "unstable_createRoot(...): Target container is not a DOM element.",
"279": "Trying to release an event instance into a pool of a different type.",
"280": "setRestoreImplementation() needs to be called to handle a target for controlled events. This error is likely caused by a bug in React. Please file an issue.",
"281": "Finished root should have a work-in-progress. This error is likely caused by a bug in React. Please file an issue.",
"282": "If the root does not have an updateQueue, we should have already bailed out. This error is likely caused by a bug in React. Please file an issue.",
"283": "Element type is invalid. Received a promise that resolves to: %s. Promise elements must resolve to a class or function.",
Move ref type check to receiver (#28464) The runtime contains a type check to determine if a user-provided ref is a valid type — a function or object (or a string, when `disableStringRefs` is off). This currently happens during child reconciliation. This changes it to happen only when the ref is passed to the component that the ref is being attached to. This is a continuation of the "ref as prop" change — until you actually pass a ref to a HostComponent, class, etc, ref is a normal prop that has no special behavior.
2024-02-29 21:26:36 -05:00
"284": "Expected ref to be a function, an object returned by React.createRef(), or undefined/null.",
Update error codes for 16.5.0 release
2018-09-06 09:34:27 -07:00
"285": "The root failed to unmount after an error. This is likely a bug in React. Please file an issue.",
Update error codes for 16.5.1 release
2018-09-13 19:11:31 +01:00
"286": "%s(...): the first argument must be a React class instance. Instead received: %s.",
Update /link URLs to react.dev (#28477) Depends on https://github.com/reactjs/react.dev/pull/6670 [merged]
2024-03-03 17:34:33 -05:00
"287": "It is not supported to run the profiling version of a renderer (for example, `react-dom/profiling`) without also replacing the `schedule/tracking` module with `schedule/tracking-profiling`. Your bundler might have a setting for aliasing both modules. Learn more at https://react.dev/link/profiling",
"288": "It is not supported to run the profiling version of a renderer (for example, `react-dom/profiling`) without also replacing the `schedule/tracing` module with `schedule/tracing-profiling`. Your bundler might have a setting for aliasing both modules. Learn more at https://react.dev/link/profiling",
Update error codes for 16.6.0-alpha.8af6728 release
2018-10-10 17:18:59 +01:00
"289": "Function components cannot have refs.",
Update /link URLs to react.dev (#28477) Depends on https://github.com/reactjs/react.dev/pull/6670 [merged]
2024-03-03 17:34:33 -05:00
"290": "Element ref was specified as a string (%s) but no owner was set. This could happen for one of the following reasons:\n1. You may be adding a ref to a function component\n2. You may be adding a ref to a component that was not created inside a component's render method\n3. You have multiple copies of React loaded\nSee https://react.dev/link/refs-must-have-owner for more information.",
Swap expect(ReactNoop) for expect(Scheduler) (#14971) * Swap expect(ReactNoop) for expect(Scheduler) In the previous commits, I upgraded our custom Jest matchers for the noop and test renderers to use Scheduler under the hood. Now that all these matchers are using Scheduler, we can drop support for passing ReactNoop and test roots and always pass Scheduler directly. * Externalize Scheduler in noop and test bundles I also noticed we don't need to regenerator runtime in noop anymore.
2019-02-28 12:54:47 -08:00
"292": "The matcher `toHaveYielded` expects an instance of React Test Renderer.\n\nTry: expect(Scheduler).toHaveYielded(expectedYields)",
Update error codes for 16.6.0 release
2018-10-23 16:29:35 -07:00
"293": "Context can only be read while React is rendering, e.g. inside the render method or getDerivedStateFromProps.",
"294": "ReactDOMServer does not yet support Suspense.",
"295": "ReactDOMServer does not yet support lazy-loaded components.",
Update error codes for 16.6.1 release
2018-11-06 18:28:50 -08:00
"297": "The matcher `unstable_toHaveYielded` expects an instance of React Test Renderer.\n\nTry: expect(ReactTestRenderer).unstable_toHaveYielded(expectedYields)",
"298": "Hooks can only be called inside the body of a function component.",
Remove method name prefix from warnings and errors (#28432) This pattern is a petpeeve of mine. I don't consider this best practice and so most don't have these prefixes. Very inconsistent. At best this is useless and noisey that you have to parse because the information is also in the stack trace. At worse these are misleading because they're highlighting something internal (like validateDOMNesting) which even suggests an internal bug. Even the ones public to React aren't necessarily what you called because you might be calling a wrapper around it. That would be properly reflected in a stack trace - which can also properly ignore list so that the first stack you see is your callsite, Which might be like `render()` in react-testing-library rather than `createRoot()` for example.
2024-02-23 15:16:54 -05:00
"299": "Target container is not a DOM element.",
Update error codes for 16.6.1 release
2018-11-06 18:28:50 -08:00
"300": "Rendered fewer hooks than expected. This may be caused by an accidental early return statement.",
Update error codes
2018-11-12 17:59:06 -08:00
"301": "Too many re-renders. React limits the number of renders to prevent an infinite loop.",
Update /link URLs to react.dev (#28477) Depends on https://github.com/reactjs/react.dev/pull/6670 [merged]
2024-03-03 17:34:33 -05:00
"302": "It is not supported to run the profiling version of a renderer (for example, `react-dom/profiling`) without also replacing the `scheduler/tracing` module with `scheduler/tracing-profiling`. Your bundler might have a setting for aliasing both modules. Learn more at https://react.dev/link/profiling",
Throw on unhandled SSR suspending (#16460) * Throw on unhandled SSR suspending * Add a nicer message when the flag is off * Tweak internal refinement error message
2019-08-19 19:53:02 +01:00
"303": "ReactDOMServer did not find an internal fallback frame for Suspense. This is a bug in React. Please file an issue.",
Update error codes
2018-11-12 17:59:06 -08:00
"304": "Maximum number of concurrent React renderers exceeded. This can happen if you are not properly destroying the Readable provided by React. Ensure that you call .destroy() on it if you no longer want to read from it, and did not read to the end. If you use .pipe() this should be automatic.",
React v16.7.0
2018-12-19 17:23:14 -08:00
"305": "The current renderer does not support hydration. This error is likely caused by a bug in React. Please file an issue.",
16.8.0
2019-02-06 08:04:00 +00:00
"306": "Element type is invalid. Received a promise that resolves to: %s. Lazy element type must resolve to a class or function.%s",
Update /link URLs to react.dev (#28477) Depends on https://github.com/reactjs/react.dev/pull/6670 [merged]
2024-03-03 17:34:33 -05:00
"307": "Hooks can only be called inside the body of a function component. (https://react.dev/link/invalid-hook-call)",
16.8.0
2019-02-06 08:04:00 +00:00
"308": "Context can only be read while React is rendering. In classes, you can read it in the render method or getDerivedStateFromProps. In function components, you can read it directly in the function body, but not inside Hooks like useReducer() or useMemo().",
Update /link URLs to react.dev (#28477) Depends on https://github.com/reactjs/react.dev/pull/6670 [merged]
2024-03-03 17:34:33 -05:00
"309": "Function components cannot have string refs. We recommend using useRef() instead. Learn more about using refs safely here: https://react.dev/link/strict-mode-string-ref",
16.8.0
2019-02-06 08:04:00 +00:00
"310": "Rendered more hooks than during the previous render.",
Tweak error message for "Should have a queue" (#29626)
2024-05-29 08:41:10 -07:00
"311": "Should have a queue. You are likely calling Hooks conditionally, which is not allowed. (https://react.dev/link/invalid-hook-call)",
Release 16.8.2
2019-02-14 19:12:42 +00:00
"312": "Rendered more hooks than during the previous render",
"313": "Unknown priority level. This error is likely caused by a bug in React. Please file an issue.",
"314": "Pinged unknown suspense boundary type. This is probably a bug in React.",
"315": "Suspense boundaries are never on the root. This is probably a bug in React.",
"316": "Expected skipPastDehydratedSuspenseInstance() to never be called. This error is likely caused by a bug in React. Please file an issue.",
"317": "Expected to have a hydrated suspense instance. This error is likely caused by a bug in React. Please file an issue.",
"318": "A dehydrated suspense component was completed without a hydrated node. This is probably a bug in React.",
"319": "A dehydrated suspense boundary must commit before trying to render. This is probably a bug in React.",
Release 16.8.5
2019-03-22 16:41:58 +00:00
"320": "Expected ReactFiberErrorDialog.showErrorDialog to be a function.",
Update /link URLs to react.dev (#28477) Depends on https://github.com/reactjs/react.dev/pull/6670 [merged]
2024-03-03 17:34:33 -05:00
"321": "Invalid hook call. Hooks can only be called inside of the body of a function component. This could happen for one of the following reasons:\n1. You might have mismatching versions of React and the renderer (such as React DOM)\n2. You might be breaking the Rules of Hooks\n3. You might have more than one copy of React in the same app\nSee https://react.dev/link/invalid-hook-call for tips about how to debug and fix this problem.",
Lint rule for unminified errors (#15757) * Lint rule for unminified errors Add a lint rule that fails if an invariant message is not part of the error code map. The goal is to be more disciplined about adding and modifiying production error codes. Error codes should be consistent across releases even if their wording changes, for continuity in logs. Currently, error codes are added to the error code map via an automated script that runs right before release. The problem with this approach is that if someone modifies an error message in the source, but neglects to modify the corresponding message in the error code map, then the message will be assigned a new error code, instead of reusing the existing one. Because the error extraction script only runs before a release, people rarely modify the error code map in practice. By moving the extraction step to the PR stage, it forces the author to consider whether the message should be assigned a new error code. It also allows the reviewer to review the changes. The trade off is that it requires more effort and context to land new error messages, or to modify existing ones, particular for new contributors who are not familiar with our processes. Since we already expect users to lint their code, I would argue the additional burden is marginal. Even if they forget to run the lint command locally, they will get quick feedback from the CI lint job, which typically finishes within 2-3 minutes. * Add unreleased error messages to map
2019-05-29 11:29:04 -07:00
"322": "forwardRef requires a render function but was given %s.",
Avoid passing custom stacks to console.error (#18685) * Detect double stacks in the new format in tests * Remove unnecessary uses of getStackByFiberInDevAndProd These all execute in the right execution context already. * Set the debug fiber around the cases that don't have an execution context * Remove stack detection in our console log overrides We never pass custom stacks as part of the args anymore. * Bonus: Don't append getStackAddendum to invariants We print component stacks for every error anyway so this is just duplicate information.
2020-04-21 09:22:46 -07:00
"323": "React has blocked a javascript: URL as a security precaution.",
Lint rule for unminified errors (#15757) * Lint rule for unminified errors Add a lint rule that fails if an invariant message is not part of the error code map. The goal is to be more disciplined about adding and modifiying production error codes. Error codes should be consistent across releases even if their wording changes, for continuity in logs. Currently, error codes are added to the error code map via an automated script that runs right before release. The problem with this approach is that if someone modifies an error message in the source, but neglects to modify the corresponding message in the error code map, then the message will be assigned a new error code, instead of reusing the existing one. Because the error extraction script only runs before a release, people rarely modify the error code map in practice. By moving the extraction step to the PR stage, it forces the author to consider whether the message should be assigned a new error code. It also allows the reviewer to review the changes. The trade off is that it requires more effort and context to land new error messages, or to modify existing ones, particular for new contributors who are not familiar with our processes. Since we already expect users to lint their code, I would argue the additional burden is marginal. Even if they forget to run the lint command locally, they will get quick feedback from the CI lint job, which typically finishes within 2-3 minutes. * Add unreleased error messages to map
2019-05-29 11:29:04 -07:00
"326": "Expected a valid priority level",
"327": "Should not already be working.",
"328": "Should have a work-in-progress.",
"329": "Unknown root exit status.",
"330": "Should be working on an effect.",
"331": "Cannot flush passive effects while already rendering.",
"332": "Unknown priority level.",
"333": "This should have a parent host component initialized. This error is likely caused by a bug in React. Please file an issue.",
Remove method name prefix from warnings and errors (#28432) This pattern is a petpeeve of mine. I don't consider this best practice and so most don't have these prefixes. Very inconsistent. At best this is useless and noisey that you have to parse because the information is also in the stack trace. At worse these are misleading because they're highlighting something internal (like validateDOMNesting) which even suggests an internal bug. Even the ones public to React aren't necessarily what you called because you might be calling a wrapper around it. That would be properly reflected in a stack trace - which can also properly ignore list so that the first stack you see is your callsite, Which might be like `render()` in react-testing-library rather than `createRoot()` for example.
2024-02-23 15:16:54 -05:00
"334": "Accumulated items must not be null or undefined.",
[Flare] Add useEvent hook implementation (#15927) * [Flare] Add useEvent hook implementation Validate hooks have decendent event components Few fixes and displayName changes Fix more responder bugs Update error codes * Add another test * Address feedback
2019-06-21 03:12:40 +01:00
"335": "ReactDOMServer does not yet support the event API.",
[Flare] Redesign core event system (#16163)
2019-07-23 23:46:44 +01:00
"338": "ReactDOMServer does not yet support the fundamental API.",
Refactor Partial Hydration (#16346) * Move dehydrated to be child of regular SuspenseComponent We now store the comment node on SuspenseState instead and that indicates that this SuspenseComponent is still dehydrated. We also store a child but that is only used to represent the DOM node for deletions and getNextHostSibling. * Move logic from DehydratedSuspenseComponent to SuspenseComponent Forked based on SuspenseState.dehydrated instead. * Retry logic for dehydrated boundary We can now simplify the logic for retrying dehydrated boundaries without hydrating. This is becomes simply a reconciliation against the dehydrated fragment which gets deleted, and the new children gets inserted. * Remove dehydrated from throw Instead we use the regular Suspense path. To save code, we attach retry listeners in the commit phase even though technically we don't have to. * Pop to nearest Suspense I think this is right...? * Popping hydration state should skip past the dehydrated instance * Split mount from update and special case suspended second pass The DidCapture flag isn't used consistently in the same way. We need further refactor for this. * Reorganize update path If we remove the dehydration status in the first pass and then do a second pass because we suspended, then we need to continue as if it didn't previously suspend. Since there is no fragment child etc. However, we must readd the deletion. * Schedule context work on the boundary and not the child * Warn for Suspense hydration in legacy mode It does a two pass render that client renders the content. * Rename DehydratedSuspenseComponent -> DehydratedFragment This now doesn't represent a suspense boundary itself. Its parent does. This Fiber represents the fragment around the dehydrated content. * Refactor returns Avoids the temporary mutable variables. I kept losing track of them. * Add a comment explaining the type. Placing it in the type since that's the central point as opposed to spread out.
2019-08-12 15:58:38 -07:00
"340": "Threw in newly mounted dehydrated component. This is likely a bug in React. Please file an issue.",
Throw on unhandled SSR suspending (#16460) * Throw on unhandled SSR suspending * Add a nicer message when the flag is off * Tweak internal refinement error message
2019-08-19 19:53:02 +01:00
"341": "We just came from a parent so we must have had a parent. This is a bug in React.",
[react-core] Add more support for experimental React Scope API (#16621)
2019-08-30 18:27:14 +01:00
"342": "A React component suspended while rendering, but no fallback UI was specified.\n\nAdd a <Suspense fallback=...> component higher in the tree to provide a loading indicator or placeholder to display.",
[Partial Hydration] Don't invoke listeners on parent of dehydrated event target (#16591) * Don't invoke listeners on parent of dehydrated event target * Move Suspense boundary check to getClosestInstanceFromNode Now getClosestInstanceFromNode can return either a host component, host text component or suspense component when the suspense component is dehydrated. We then use that to ignore events on a suspense component. * Attach the HostRoot fiber to the DOM container This lets us detect if an event happens on this root's subtree before it has rendered something. * Add todo The approach of checking isFiberMounted answers if we might be in an in-progress hydration but it doesn't answer which root or boundary might be in-progress so we don't know what to wait for. This needs some refactoring. * Refactor isFiberMountedImpl to getNearestMountedFiber We'll need the nearest boundary for event replaying so this prepares for that. This surfaced an issue that we attach Hydrating tag on the root but normally this (and Placement) is attached on the child. This surfaced an issue that this can lead to both Placement and Hydrating effects which is not supported so we need to ensure that we only ever use one or the other. * Add todo for bug I spotted * Cache tags * Check the ContainerInstanceKey before the InstanceKey The container is inside the instance, so we must find it before the instance, since otherwise we'll miss it.
2019-09-05 08:51:31 -07:00
"343": "ReactDOMServer does not yet support scope components.",
[suspense][error handling] Inline renderRoot and fix error handling bug (#16801) * Outline push/pop logic in `renderRoot` I want to get rid of the the `isSync` argument to `renderRoot`, and instead use separate functions for concurrent and synchronous render. As a first step, this extracts the push/pop logic that happens before and after the render phase into helper functions. * Extract `catch` block into helper function Similar to previous commit. Extract error handling logic into a separate function so it can be reused. * Fork `renderRoot` for sync and concurrent Removes `isSync` argument in favor of separate functions. * Extra "root completion" logic to separate function Moving this out to avoid an accidental early return, which would bypass the call to `ensureRootIsScheduled` and freeze the UI. * Inline `renderRoot` Inlines `renderRoot` into `performConcurrentWorkOnRoot` and `performSyncWorkOnRoot`. This lets me remove the `isSync` argument and also get rid of a redundant try-catch wrapper. * [suspense][error handling] Add failing unit test Covers an edge case where an error is thrown inside the complete phase of a component that is in the return path of a component that suspends. The second error should also be handled (i.e. able to be captured by an error boundary. The test is currently failing because there's a call to `completeUnitOfWork` inside the main render phase `catch` block. That call is not itself wrapped in try-catch, so anything that throws is treated as a fatal/unhandled error. I believe this bug is only observable if something in the host config throws; and, only in legacy mode, because in concurrent/batched mode, `completeUnitOfWork` on fiber that throws follows the "unwind" path only, not the "complete" path, and the "unwind" path does not call any host config methods. * [scheduler][profiler] Start time of delayed tasks Fixes a bug in the Scheduler profiler where the start time of a delayed tasks is always 0. * Remove ad hoc `throw` Fatal errors (errors that are not captured by an error boundary) are currently rethrown from directly inside the render phase's `catch` block. This is a refactor hazard because the code in this branch has to mirror the code that happens at the end of the function, when exiting the render phase in the normal case. This commit moves the throw to the end, using a new root exit status. * Handle errors that occur on unwind
2019-09-23 11:23:28 -07:00
"344": "Expected prepareToHydrateHostSuspenseInstance() to never be called. This error is likely caused by a bug in React. Please file an issue.",
[react-interactions] Remove context.setTimeout & context.clearTimeout (#17000)
2019-10-03 13:37:37 +02:00
"345": "Root did not complete. This is a bug in React.",
useMutableSource hook (#18000) useMutableSource hook useMutableSource() enables React components to safely and efficiently read from a mutable external source in Concurrent Mode. The API will detect mutations that occur during a render to avoid tearing and it will automatically schedule updates when the source is mutated. RFC: reactjs/rfcs#147
2020-03-11 12:34:39 -07:00
"348": "ensureListeningTo(): received a container that was not an element node. This is likely a bug in React.",
"349": "Expected a work-in-progress root. This is a bug in React. Please file an issue.",
useMutableSource: Use StrictMode double render to detect render phase mutation (#20698) * Concurrent Mode test for uMS render mutation Same test as the one added in #20665, but for Concurrent Mode. * Use double render to detect render phase mutation PR #20665 added a mechanism to detect when a `useMutableSource` source is mutated during the render phase. It relies on the fact that we double invoke components that error during development using `invokeGuardedCallback`. If the version in the double render doesn't match the first, that indicates there must have been a mutation during render. At first I thought it worked by detecting inside the *other* double render, the one we do for Strict Mode. It turns out that while it does warn then, the warning is suppressed, because we suppress all console methods that occur during the Strict Mode double render. So it's really the `invokeGuardedCallback` one that makes it work. Anyway, let's set that aside that issue for a second. I realized during review that errors that occur during the Strict Mode double render reveal a useful property: A pure component will never throw during the double render, because if it were pure, it would have also thrown during the first render... in which case it wouldn't have double rendered! This is true of all such errors, not just the one thrown by `useMutableSource`. Given this, we can simplify the `useMutableSource` mutation detection mechanism. Instead of tracking and comparing the source's version, we can instead check if we're inside a double render when the error is thrown. To get around the console suppression issue, I changed the warning to an error. It errors regardless, in both dev and prod, so it doesn't have semantic implications. However, because of the paradox I described above, we arguably _shouldn't_ throw an error in development, since we know that error won't happen in production, because prod doesn't double render. (It's still a tearing bug, but that doesn't mean the component will actually throw.) I considered that, but that requires a larger conversation about how to handle errors that we know are only possible in development. I think we should probably be suppressing *all* errors (with a warning) that occur during a double render.
2021-02-01 14:11:51 -06:00
"350": "Cannot read from mutable source during the current render without tearing. This may be a bug in React. Please file an issue.",
[Flight] Improve Error Messages when Invalid Object is Passed to Client/Host Components (#25492) * Print built-in specific error message for toJSON This is a better message for Date. Also, format the message to highlight the affected prop. * Describe error messages using JSX elements in DEV We don't have access to the grand parent objects on the stack so we stash them on weakmaps so we can access them while printing error messages. Might be a bit slow. * Capitalize Server/Client Component * Special case errror messages for children of host components These are likely meant to be text content if they're not a supported object. * Update error messages
2022-10-16 21:49:17 -04:00
"351": "Unsupported Server Component type: %s",
Remove Blocks (#20138) * Remove Blocks * Remove Flight Server Runtime There's no need for this now that the JSResource is part of the bundler protocol. Might need something for Webpack plugin specifically later. * Devtools
2020-10-31 02:03:45 -04:00
"352": "React Lazy Components are not yet supported on the server.",
Add getInspectorDataForViewAtPoint (take two) (#18388) * Add getInspectorDataForViewAtPoint (take two) * Updates from review * Add DEV to dev-only variable * Missed this rename
2020-03-30 15:42:41 -04:00
"353": "A server block should never encode any other slots. This is a bug in React.",
Add useOpaqueIdentifier Hook (#17322) * Add useOpaqueIdentifier Hook We currently use unique IDs in a lot of places. Examples are: * `<label for="ID">` * `aria-labelledby` This can cause some issues: 1. If we server side render and then hydrate, this could cause an hydration ID mismatch 2. If we server side render one part of the page and client side render another part of the page, the ID for one part could be different than the ID for another part even though they are supposed to be the same 3. If we conditionally render something with an ID , this might also cause an ID mismatch because the ID will be different on other parts of the page This PR creates a new hook `useUniqueId` that generates a different unique ID based on whether the hook was called on the server or client. If the hook is called during hydration, it generates an opaque object that will rerender the hook so that the IDs match. Co-authored-by: Andrew Clark <git@andrewclark.io>
2020-04-06 17:17:27 -07:00
"354": "getInspectorDataForViewAtPoint() is not available in production.",
Remove experimental useOpaqueIdentifier API (#22672) useId is the updated version of this API.
2021-11-01 18:02:39 -04:00
"355": "The object passed back from useOpaqueIdentifier is meant to be passed through to attributes only. Do not read the value directly. (TODO: This feature was never released so we should be able to remove this error from the map.)",
Refine experimental Scopes API (#18778) * Refine experimental Scopes API
2020-05-01 19:01:43 +01:00
"356": "Could not read the cache.",
Initial Lanes implementation (#18796) See PR #18796 for more information. All of the changes I've made in this commit are behind the `enableNewReconciler` flag. Merging this to master will not affect the open source builds or the build that we ship to Facebook. The only build that is affected is the `ReactDOMForked` build, which is deployed to Facebook **behind an experimental flag (currently disabled for all users)**. We will use this flag to gradually roll out the new reconciler, and quickly roll it back if we find any problems. Because we have those protections in place, what I'm aiming for with this initial PR is the **smallest possible atomic change that lands cleanly and doesn't rely on too many hacks**. The goal has not been to get every single test or feature passing, and it definitely is not to implement all the features that we intend to build on top of the new model. When possible, I have chosen to preserve existing semantics and defer changes to follow-up steps. (Listed in the section below.) (I did not end up having to disable any tests, although if I had, that should not have necessarily been a merge blocker.) For example, even though one of the primary goals of this project is to improve our model for parallel Suspense transitions, in this initial implementation, I have chosen to keep the same core heuristics for sequencing and flushing that existed in the ExpirationTimes model: low priority updates cannot finish without also finishing high priority ones. Despite all these precautions, **because the scope of this refactor is inherently large, I do expect we will find regressions.** The flip side is that I also expect the new model to improve the stability of the codebase and make it easier to fix bugs when they arise.
2020-05-02 17:09:31 -07:00
"357": "The current renderer does not support React Scopes. This error is likely caused by a bug in React. Please file an issue.",
"358": "Invalid update priority: %s. This is a bug in React.",
Experimental test selector API (#18607) Adds several new experimental APIs to aid with automated testing. Each of the methods below accepts an array of "selectors" that identifies a path (or paths) through a React tree. There are four basic selector types: * Component: Matches Fibers with the specified React component type * Role: Matches Host Instances matching the (explicit or implicit) accessibility role. * Test name: Matches Host Instances with a data-testname attribute. * Text: Matches Host Instances that directly contain the specified text. * There is also a special lookahead selector type that enables further matching within a path (without actually including the path in the result). This selector type was inspired by the :has() CSS pseudo-class. It enables e.g. matching a <section> that contained a specific header text, then finding a like button within that <section>. API * findAllNodes(): Finds all Host Instances (e.g. HTMLElement) within a host subtree that match the specified selector criteria. * getFindAllNodesFailureDescription(): Returns an error string describing the matched and unmatched portions of the selector query. * findBoundingRects(): For all React components within a host subtree that match the specified selector criteria, return a set of bounding boxes that covers the bounds of the nearest (shallowed) Host Instances within those trees. * observeVisibleRects(): For all React components within a host subtree that match the specified selector criteria, observe if it’s bounding rect is visible in the viewport and is not occluded. * focusWithin(): For all React components within a host subtree that match the specified selector criteria, set focus within the first focusable Host Instance (as if you started before this component in the tree and moved focus forwards one step).
2020-05-05 10:37:46 -07:00
"360": "Invalid lane: %s. This is a bug in React.",
"361": "The current renderer does not support test selectors. This error is likely caused by a bug in React. Please file an issue.",
"362": "Could not find React container within specified host subtree.",
"363": "Test selector API is not supported by this renderer.",
"364": "Invalid host root specified. Should be either a React container or a node with a testname attribute.",
[RFC] Codemod invariant -> throw new Error (#22435) * Hoist error codes import to module scope When this code was written, the error codes map (`codes.json`) was created on-the-fly, so we had to lazily require from inside the visitor. Because `codes.json` is now checked into source, we can import it a single time in module scope. * Minify error constructors in production We use a script to minify our error messages in production. Each message is assigned an error code, defined in `scripts/error-codes/codes.json`. Then our build script replaces the messages with a link to our error decoder page, e.g. https://reactjs.org/docs/error-decoder.html/?invariant=92 This enables us to write helpful error messages without increasing the bundle size. Right now, the script only works for `invariant` calls. It does not work if you throw an Error object. This is an old Facebookism that we don't really need, other than the fact that our error minification script relies on it. So, I've updated the script to minify error constructors, too: Input: Error(`A ${adj} message that contains ${noun}`); Output: Error(formatProdErrorMessage(ERR_CODE, adj, noun)); It only works for constructors that are literally named Error, though we could add support for other names, too. As a next step, I will add a lint rule to enforce that errors written this way must have a corresponding error code. * Minify "no fallback UI specified" error in prod This error message wasn't being minified because it doesn't use invariant. The reason it didn't use invariant is because this particular error is created without begin thrown — it doesn't need to be thrown because it's located inside the error handling part of the runtime. Now that the error minification script supports Error constructors, we can minify it by assigning it a production error code in `scripts/error-codes/codes.json`. To support the use of Error constructors more generally, I will add a lint rule that enforces each message has a corresponding error code. * Lint rule to detect unminified errors Adds a lint rule that detects when an Error constructor is used without a corresponding production error code. We already have this for `invariant`, but not for regular errors, i.e. `throw new Error(msg)`. There's also nothing that enforces the use of `invariant` besides convention. There are some packages where we don't care to minify errors. These are packages that run in environments where bundle size is not a concern, like react-pg. I added an override in the ESLint config to ignore these. * Temporarily add invariant codemod script I'm adding this codemod to the repo temporarily, but I'll revert it in the same PR. That way we don't have to check it in but it's still accessible (via the PR) if we need it later. * [Automated] Codemod invariant -> Error This commit contains only automated changes: npx jscodeshift -t scripts/codemod-invariant.js packages --ignore-pattern="node_modules/**/*" yarn linc --fix yarn prettier I will do any manual touch ups in separate commits so they're easier to review. * Remove temporary codemod script This reverts the codemod script and ESLint config I added temporarily in order to perform the invariant codemod. * Manual touch ups A few manual changes I made after the codemod ran. * Enable error code transform per package Currently we're not consistent about which packages should have their errors minified in production and which ones should. This adds a field to the bundle configuration to control whether to apply the transform. We should decide what the criteria is going forward. I think it's probably a good idea to minify any package that gets sent over the network. So yes to modules that run in the browser, and no to modules that run on the server and during development only.
2021-09-30 15:01:28 -04:00
"365": "Invalid selector type specified.",
Add experimental ReactDOM.createEventHandle (#18756)
2020-05-12 20:24:25 +01:00
"366": "ReactDOM.createEventHandle: setListener called on an target that did not have a corresponding root. This is likely a bug in React.",
"367": "ReactDOM.createEventHandle: setListener called on an element target that is not managed by React. Ensure React rendered the DOM element.",
Refactor createEventHandle signature (#19174)
2020-07-07 13:05:06 +01:00
"368": "ReactDOM.createEventHandle: setListener called on an invalid target. Provide a valid EventTarget or an element managed by React.",
"369": "ReactDOM.createEventHandle: setter called on an invalid target. Provide a valid EventTarget or an element managed by React.",
Append text string to <Text> error message (#19581) * Append text string to <Text> error message * Truncate text in <Text> error message * Regenerate `codes.json`
2020-08-17 10:47:49 -07:00
"370": "ReactDOM.createEventHandle: setter called with an invalid callback. The callback must be a function.",
Attach Listeners Eagerly to Roots and Portal Containers (#19659) * Failing test for #19608 * Attach Listeners Eagerly to Roots and Portal Containers * Forbid createEventHandle with custom events We can't support this without adding more complexity. It's not clear that this is even desirable, as none of our existing use cases need custom events. This API primarily exists as a deprecation strategy for Flare, so I don't think it is important to expand its support beyond what Flare replacement code currently needs. We can later revisit it with a better understanding of the eager/lazy tradeoff but for now let's remove the inconsistency. * Reduce risk by changing condition only under the flag Co-authored-by: koba04 <koba0004@gmail.com>
2020-08-24 16:50:20 +01:00
"371": "Text string must be rendered within a <Text> component.\n\nText: %s",
[Flight] Support more element types and Hooks for Server and Hybrid Components (#19711) * Shim support for more element types * Shim commonly used Hooks that are safe * Flow * Oopsie
2020-08-27 20:19:13 +01:00
"372": "Cannot call unstable_createEventHandle with \"%s\", as it is not an event known to React.",
[Flight] Add Runtime Errors for Non-serializable Values (#19980) * Error on encoding non-serializable props * Add DEV time warnings to enforce that values are plain objects
2020-10-08 14:11:15 -04:00
"373": "This Hook is not supported in Server Components.",
[Flight] Improve Error Messages when Invalid Object is Passed to Client/Host Components (#25492) * Print built-in specific error message for toJSON This is a better message for Date. Also, format the message to highlight the affected prop. * Describe error messages using JSX elements in DEV We don't have access to the grand parent objects on the stack so we stash them on weakmaps so we can access them while printing error messages. Might be a bit slow. * Capitalize Server/Client Component * Special case errror messages for children of host components These are likely meant to be text content if they're not a supported object. * Update error messages
2022-10-16 21:49:17 -04:00
"374": "Event handlers cannot be passed to Client Component props.%s\nIf you need interactivity, consider converting part of this to a Client Component.",
[Flight] Better error message if you pass a function as a child to a client component (#28367) Similar to #28362 but if you pass it to a client component.
2024-02-19 12:36:16 -05:00
"375": "Functions cannot be passed directly to Client Components unless you explicitly expose it by marking it with \"use server\". Or maybe you meant to call this function rather than return it.%s",
[Flight] Improve Error Messages when Invalid Object is Passed to Client/Host Components (#25492) * Print built-in specific error message for toJSON This is a better message for Date. Also, format the message to highlight the affected prop. * Describe error messages using JSX elements in DEV We don't have access to the grand parent objects on the stack so we stash them on weakmaps so we can access them while printing error messages. Might be a bit slow. * Capitalize Server/Client Component * Special case errror messages for children of host components These are likely meant to be text content if they're not a supported object. * Update error messages
2022-10-16 21:49:17 -04:00
"376": "Only global symbols received from Symbol.for(...) can be passed to Client Components. The symbol Symbol.for(%s) cannot be found among global symbols.%s",
"377": "BigInt (%s) is not yet supported in Client Component props.%s",
"378": "Type %s is not supported in Client Component props.%s",
"379": "Refs cannot be used in Server Components, nor passed to Client Components.",
[Flight] Add getCacheForType() to the dispatcher (#20315) * Remove react/unstable_cache We're probably going to make it available via the dispatcher. Let's remove this for now. * Add readContext() to the dispatcher On the server, it will be per-request. On the client, there will be some way to shadow it. For now, I provide it on the server, and throw on the client. * Use readContext() from react-fetch This makes it work on the server (but not on the client until we implement it there.) Updated the test to use Server Components. Now it passes. * Fixture: Add fetch from a Server Component * readCache -> getCacheForType<T> * Add React.unstable_getCacheForType * Add a feature flag * Fix Flow * Add react-suspense-test-utils and port tests * Remove extra Map lookup * Unroll async/await because build system * Add some error coverage and retry * Add unstable_getCacheForType to Flight entry
2020-12-03 03:44:56 +00:00
"380": "Reading the cache is only supported while rendering.",
Error when the number of parameters to a query changes (#20379)
2020-12-04 20:11:00 +00:00
"381": "This feature is not supported by ReactSuspenseTestUtils.",
"382": "This query has received more parameters than the last time the same query was used. Always pass the exact number of parameters that the query needs.",
Add built-in Suspense cache with support for invalidation (refreshing) (#20456)
2020-12-18 12:57:24 -06:00
"383": "This query has received fewer parameters than the last time the same query was used. Always pass the exact number of parameters that the query needs.",
Improve React error message when mutable sources are mutated during render (#20665) Changed previous error message from: > Cannot read from mutable source during the current render without tearing. This is a bug in React. Please file an issue. To: > Cannot read from mutable source during the current render without tearing. This may be a bug in React. Please file an issue. Also added a DEV only warning about the unsafe side effect: > A mutable source was mutated while the %s component was rendering. This is not supported. Move any mutations into event handlers or effects. I think this is the best we can do without adding production overhead that we'd probably prefer to avoid.
2021-01-29 10:22:55 -05:00
"384": "Refreshing the cache is not supported in Server Components.",
Add `supportsMicrotasks` to the host config (#20809) * Add `supportsMicrotasks` to the host config Only certain renderers support scheduling a microtask, so we need a renderer specific flag that we can toggle. That way it's off for some renderers and on for others. I copied the approach we use for the other optional parts of the host config, like persistent mode and test selectors. Why isn't the feature flag sufficient? The feature flag modules, confusingly, are not renderer-specific, at least when running the our tests against the source files. They are meant to correspond to a release channel, not a renderer, but we got confused at some point and haven't cleaned it up. For example, when we run `yarn test`, Jest loads the flags from the default `ReactFeatureFlags.js` module, even when we import the React Native renderer — but in the actual builds, we load a different feature flag module, `ReactFeatureFlags.native-oss.js.` There's no way in our current Jest load a different host config for each renderer, because they all just import the same module. We should solve this by creating separate Jest project for each renderer, so that the flags loaded when running against source are the same ones that we use in the compiled bundles. The feature flag (`enableDiscreteMicrotasks`) still exists — it's used to set the React DOM host config's `supportsMicrotasks` flag to `true`. (Same for React Noop) The important part is that turning on the feature flag does *not* affect the other renderers, like React Native. The host config will likely outlive the feature flag, too, since the feature flag only exists so we can gradually roll it out and measure the impact in production; once we do, we'll remove it. Whereas the host config flag may continue to be used to disable the discrete microtask behavior for RN, because RN will likely use a native (non-JavaScript) API to schedule its tasks. * Add `supportsMicrotask` to react-reconciler README
2021-02-12 15:13:49 -06:00
"385": "A mutable source was mutated while the %s component was rendering. This is not supported. Move any mutations into event handlers or effects.",
[Experiment] Lazily propagate context changes (#20890) * Move context comparison to consumer In the lazy context implementation, not all context changes are propagated from the provider, so we can't rely on the propagation alone to mark the consumer as dirty. The consumer needs to compare to the previous value, like we do for state and context. I added a `memoizedValue` field to the context dependency type. Then in the consumer, we iterate over the current dependencies to see if something changed. We only do this iteration after props and state has already bailed out, so it's a relatively uncommon path, except at the root of a changed subtree. Alternatively, we could move these comparisons into `readContext`, but that's a much hotter path, so I think this is an appropriate trade off. * [Experiment] Lazily propagate context changes When a context provider changes, we scan the tree for matching consumers and mark them as dirty so that we know they have pending work. This prevents us from bailing out if, say, an intermediate wrapper is memoized. Currently, we propagate these changes eagerly, at the provider. However, in many cases, we would have ended up visiting the consumer nodes anyway, as part of the normal render traversal, because there's no memoized node in between that bails out. We can save CPU cycles by propagating changes only when we hit a memoized component — so, instead of propagating eagerly at the provider, we propagate lazily if or when something bails out. Most of our bailout logic is centralized in `bailoutOnAlreadyFinishedWork`, so this ended up being not that difficult to implement correctly. There are some exceptions: Suspense and Offscreen. Those are special because they sometimes defer the rendering of their children to a completely separate render cycle. In those cases, we must take extra care to propagate *all* the context changes, not just the first one. I'm pleasantly surprised at how little I needed to change in this initial implementation. I was worried I'd have to use the reconciler fork, but I ended up being able to wrap all my changes in a regular feature flag. So, we could run an experiment in parallel to our other ones. I do consider this a risky rollout overall because of the potential for subtle semantic deviations. However, the model is simple enough that I don't expect us to have trouble fixing regressions if or when they arise during internal dogfooding. --- This is largely based on [RFC#118](https://github.com/reactjs/rfcs/pull/118), by @gnoff. I did deviate in some of the implementation details, though. The main one is how I chose to track context changes. Instead of storing a dirty flag on the stack, I added a `memoizedValue` field to the context dependency object. Then, to check if something has changed, the consumer compares the new context value to the old (memoized) one. This is necessary because of Suspense and Offscreen — those components defer work from one render into a later one. When the subtree continues rendering, the stack from the previous render is no longer available. But the memoized values on the dependencies list are. This requires a bit more work when a consumer bails out, but nothing considerable, and there are ways we could optimize it even further. Conceptually, this model is really appealing, since it matches how our other features "reactively" detect changes — `useMemo`, `useEffect`, `getDerivedStateFromProps`, the built-in cache, and so on. I also intentionally dropped support for `unstable_calculateChangedBits`. We're planning to remove this API anyway before the next major release, in favor of context selectors. It's an unstable feature that we never advertised; I don't think it's seen much adoption. Co-Authored-By: Josh Story <jcs.gnoff@gmail.com> * Propagate all contexts in single pass Instead of propagating the tree once per changed context, we can check all the contexts in a single propagation. This inverts the two loops so that the faster loop (O(numberOfContexts)) is inside the more expensive loop (O(numberOfFibers * avgContextDepsPerFiber)). This adds a bit of overhead to the case where only a single context changes because you have to unwrap the context from the array. I'm also unsure if this will hurt cache locality. Co-Authored-By: Josh Story <jcs.gnoff@gmail.com> * Stop propagating at nearest dependency match Because we now propagate all context providers in a single traversal, we can defer context propagation to a subtree without losing information about which context providers we're deferring — it's all of them. Theoretically, this is a big optimization because it means we'll never propagate to any tree that has work scheduled on it, nor will we ever propagate the same tree twice. There's an awkward case related to bailing out of the siblings of a context consumer. Because those siblings don't bail out until after they've already entered the begin phase, we have to do extra work to make sure they don't unecessarily propagate context again. We could avoid this by adding an earlier bailout for sibling nodes, something we've discussed in the past. We should consider this during the next refactor of the fiber tree structure. Co-Authored-By: Josh Story <jcs.gnoff@gmail.com> * Mark trees that need propagation in readContext Instead of storing matched context consumers in a Set, we can mark when a consumer receives an update inside `readContext`. I hesistated to put anything in this function because it's such a hot path, but so are bail outs. Fortunately, we only need to set this flag once, the first time a context is read. So I think it's a reasonable trade off. In exchange, propagation is faster because we no longer need to accumulate a Set of matched consumers, and fiber bailouts are faster because we don't need to consult that Set. And the code is simpler. Co-authored-by: Josh Story <jcs.gnoff@gmail.com>
2021-03-07 00:56:53 -06:00
"386": "The current renderer does not support microtasks. This error is likely caused by a bug in React. Please file an issue.",
"387": "Should have a current fiber. This is a bug in React.",
Basic Fizz Architecture (#20970) * Copy some infra structure patterns from Flight * Basic data structures * Move structural nodes and instruction commands to host config * Move instruction command to host config In the DOM this is implemented as script tags. The first time it's emitted it includes the function. Future calls invoke the same function. The side of the complete boundary function in particular is unfortunately large. * Implement Fizz Noop host configs This is implemented not as a serialized protocol but by-passing the serialization when possible and instead it's like a live tree being built. * Implement React Native host config This is not wired up. I just need something for the flow types since Flight and Fizz are both handled by the isServerSupported flag. Might as well add something though. The principle of this format is the same structure as for HTML but a simpler binary format. Each entry is a tag followed by some data and terminated by null. * Check in error codes * Comment
2021-03-11 15:01:41 -05:00
"388": "Expected to find a bailed out fiber. This is a bug in React.",
"389": "There can only be one root segment. This is a bug in React.",
[Fizz] Don't add aborted segments to the completedSegments list (#21976) * Don't add aborted segments to the completedSegments list * Update error message to include aborted status
2021-07-27 21:53:37 -04:00
"390": "Aborted, errored or already flushed boundaries should not be flushed again. This is a bug in React.",
Basic Fizz Architecture (#20970) * Copy some infra structure patterns from Flight * Basic data structures * Move structural nodes and instruction commands to host config * Move instruction command to host config In the DOM this is implemented as script tags. The first time it's emitted it includes the function. Future calls invoke the same function. The side of the complete boundary function in particular is unfortunately large. * Implement Fizz Noop host configs This is implemented not as a serialized protocol but by-passing the serialization when possible and instead it's like a live tree being built. * Implement React Native host config This is not wired up. I just need something for the flow types since Flight and Fizz are both handled by the isServerSupported flag. Might as well add something though. The principle of this format is the same structure as for HTML but a simpler binary format. Each entry is a tag followed by some data and terminated by null. * Check in error codes * Comment
2021-03-11 15:01:41 -05:00
"391": "A previously unvisited boundary must have exactly one root segment. This is a bug in React.",
"392": "A root segment ID must have been assigned by now. This is a bug in React.",
"393": "Cache cannot be refreshed during server rendering.",
"394": "startTransition cannot be called during server rendering.",
"395": "An ID must have been assigned before we can complete the boundary.",
[Fizz] Support special HTML/SVG/MathML tags to suspend (#21113) * Encode tables as a special insertion mode The table modes are special in that its children can't be created outside a table context so we need the segment container to be wrapped in a table. * Move formatContext from Task to Segment It works the same otherwise. It's just that this context needs to outlive the task so that I can use it when writing the segment. * Use template tag for placeholders and inserted dummy nodes with IDs These can be used in any parent. At least outside IE11. Not sure yet what happens in IE11 to these. Not sure if these are bad for perf since they're special nodes. * Add special wrappers around inserted segments depending on their insertion mode * Allow the root namespace to be configured This allows us to insert the correct wrappers when streaming into an existing non-HTML tree. * Add comment
2021-03-27 13:50:38 -04:00
"396": "More boundaries or placeholders than we expected to ever emit.",
[Fizz] Implement all the DOM attributes and special cases (#21153) * Implement DOM format config structure * Styles * Input warnings * Textarea special cases * Select special cases * Option special cases We read the currently selected value from the FormatContext. * Warning for non-lower case HTML We don't change to lower case at runtime anymore but keep the warning. * Pre tags innerHTML needs to be prefixed This is because if you do the equivalent on the client using innerHTML, this is the effect you'd get. * Extract errors
2021-03-31 20:39:38 -04:00
"397": "Unknown insertion mode. This is a bug in React.",
"398": "`dangerouslySetInnerHTML` does not work on <option>.",
"399": "%s is a self-closing tag and must neither have `children` nor use `dangerouslySetInnerHTML`.",
[Fizz] Implement New Context (#21255) * Add NewContext module This implements a reverse linked list tree containing the previous contexts. * Implement recursive algorithm This algorithm pops the contexts back to a shared ancestor on the way down the stack and then pushes new contexts in reverse order up the stack. * Move isPrimaryRenderer to ServerFormatConfig This is primarily intended to be used to support renderToString with a separate build than the main one. This allows them to be nested. * Wire up more element type matchers * Wire up Context Provider type * Wire up Context Consumer * Test * Implement reader in class * Update error codez
2021-04-14 14:45:42 -04:00
"400": "menuitems cannot have `children` nor `dangerouslySetInnerHTML`.",
"401": "The stacks must reach the root at the same time. This is a bug in React.",
"402": "The depth must equal at least at zero before reaching the root. This is a bug in React.",
Implement useOpaqueIdentifier (#21260) The format of this ID is specific to the format.
2021-04-14 17:25:42 -04:00
"403": "Tried to pop a Context at the root of the app. This is a bug in React.",
createRoot(..., {hydrate:true}) -> hydrateRoot(...) (#21687) This adds a new top level API for hydrating a root. It takes the initial children as part of its constructor. These are unlike other render calls in that they have to represent what the server sent and they can't be batched with other updates. I also changed the options to move the hydrationOptions to the top level since now these options are all hydration options. I kept the createRoot one just temporarily to make it easier to codemod internally but I'm doing a follow up to delete. As part of this I un-dried a couple of paths. ReactDOMLegacy was intended to be built on top of the new API but it didn't actually use those root APIs because there are special paths. It also doesn't actually use most of the commmon paths since all the options are ignored. It also made it hard to add only warnings for legacy only or new only code paths. I also forked the create/hydrate paths because they're subtly different since now the options are different. The containers are also different because I now error for comment nodes during hydration which just doesn't work at all but eventually we'll error for all createRoot calls. After some iteration it might make sense to break out some common paths but for now it's easier to iterate on the duplicates.
2021-06-15 16:37:53 -04:00
"404": "Invalid hook call. Hooks can only be called inside of the body of a function component.",
Throw when `act` is used in production (#21686) Upgrades the deprecation warning to a runtime error. I did it this way instead of removing the export so the type is the same in both builds. It will get dead code eliminated regardless.
2021-06-16 16:29:51 -04:00
"405": "hydrateRoot(...): Target container is not a DOM element.",
Implement useSyncExternalStore on server (#22347) Adds a third argument called `getServerSnapshot`. On the server, React calls this one instead of the normal `getSnapshot`. We also call it during hydration. So it represents the snapshot that is used to generate the initial, server-rendered HTML. The purpose is to avoid server-client mismatches. What we render during hydration needs to match up exactly with what we render on the server. The pattern is for the server to send down a serialized copy of the store that was used to generate the initial HTML. On the client, React will call either `getSnapshot` or `getServerSnapshot` on the client as appropriate, depending on whether it's currently hydrating. The argument is optional for fully client rendered use cases. If the user does attempt to omit `getServerSnapshot`, and the hook is called on the server, React will abort that subtree on the server and revert to client rendering, up to the nearest Suspense boundary. For the userspace shim, we will need to use a heuristic (canUseDOM) to determine whether we are in a server environment. I'll do that in a follow up.
2021-09-20 11:31:02 -04:00
"406": "act(...) is not supported in production builds of React.",
Implement getServerSnapshot in userspace shim (#22359) * Convert useSES shim tests to use React DOM Idea is that eventually we'll run these tests against an actual build of React DOM 17 to test backwards compatibility. * Implement getServerSnapshot in userspace shim If the DOM is not present, we assume that we are running in a server environment and return the result of `getServerSnapshot`. This heuristic doesn't work in React Native, so we'll need to provide a separate native build (using the `.native` extension). I've left this for a follow-up. We can't call `getServerSnapshot` on the client, because in versions of React before 18, there's no built-in mechanism to detect whether we're hydrating. To avoid a server mismatch warning, users must account for this themselves and return the correct value inside `getSnapshot`. Note that none of this is relevant to the built-in API that is being added in 18. This only affects the userspace shim that is provided for backwards compatibility with versions 16 and 17.
2021-09-20 11:32:13 -04:00
"407": "Missing getServerSnapshot, which is required for server-rendered content. Will revert to client rendering.",
Make root.unmount() synchronous (#22444) * Move flushSync warning to React DOM When you call in `flushSync` from an effect, React fires a warning. I've moved the implementation of this warning out of the reconciler and into React DOM. `flushSync` is a renderer API, not an isomorphic API, because it has behavior that was designed specifically for the constraints of React DOM. The equivalent API in a different renderer may not be the same. For example, React Native has a different threading model than the browser, so it might not make sense to expose a `flushSync` API to the JavaScript thread. * Make root.unmount() synchronous When you unmount a root, the internal state that React stores on the DOM node is immediately cleared. So, we should also synchronously delete the React tree. You should be able to create a new root using the same container.
2021-09-27 17:04:39 -04:00
"408": "Missing getServerSnapshot, which is required for server-rendered content.",
[RFC] Codemod invariant -> throw new Error (#22435) * Hoist error codes import to module scope When this code was written, the error codes map (`codes.json`) was created on-the-fly, so we had to lazily require from inside the visitor. Because `codes.json` is now checked into source, we can import it a single time in module scope. * Minify error constructors in production We use a script to minify our error messages in production. Each message is assigned an error code, defined in `scripts/error-codes/codes.json`. Then our build script replaces the messages with a link to our error decoder page, e.g. https://reactjs.org/docs/error-decoder.html/?invariant=92 This enables us to write helpful error messages without increasing the bundle size. Right now, the script only works for `invariant` calls. It does not work if you throw an Error object. This is an old Facebookism that we don't really need, other than the fact that our error minification script relies on it. So, I've updated the script to minify error constructors, too: Input: Error(`A ${adj} message that contains ${noun}`); Output: Error(formatProdErrorMessage(ERR_CODE, adj, noun)); It only works for constructors that are literally named Error, though we could add support for other names, too. As a next step, I will add a lint rule to enforce that errors written this way must have a corresponding error code. * Minify "no fallback UI specified" error in prod This error message wasn't being minified because it doesn't use invariant. The reason it didn't use invariant is because this particular error is created without begin thrown — it doesn't need to be thrown because it's located inside the error handling part of the runtime. Now that the error minification script supports Error constructors, we can minify it by assigning it a production error code in `scripts/error-codes/codes.json`. To support the use of Error constructors more generally, I will add a lint rule that enforces each message has a corresponding error code. * Lint rule to detect unminified errors Adds a lint rule that detects when an Error constructor is used without a corresponding production error code. We already have this for `invariant`, but not for regular errors, i.e. `throw new Error(msg)`. There's also nothing that enforces the use of `invariant` besides convention. There are some packages where we don't care to minify errors. These are packages that run in environments where bundle size is not a concern, like react-pg. I added an override in the ESLint config to ignore these. * Temporarily add invariant codemod script I'm adding this codemod to the repo temporarily, but I'll revert it in the same PR. That way we don't have to check it in but it's still accessible (via the PR) if we need it later. * [Automated] Codemod invariant -> Error This commit contains only automated changes: npx jscodeshift -t scripts/codemod-invariant.js packages --ignore-pattern="node_modules/**/*" yarn linc --fix yarn prettier I will do any manual touch ups in separate commits so they're easier to review. * Remove temporary codemod script This reverts the codemod script and ESLint config I added temporarily in order to perform the invariant codemod. * Manual touch ups A few manual changes I made after the codemod ran. * Enable error code transform per package Currently we're not consistent about which packages should have their errors minified in production and which ones should. This adds a field to the bundle configuration to control whether to apply the transform. We should decide what the criteria is going forward. I think it's probably a good idea to minify any package that gets sent over the network. So yes to modules that run in the browser, and no to modules that run on the server and during development only.
2021-09-30 15:01:28 -04:00
"409": "Cannot update an unmounted root.",
"411": "%s suspended while rendering, but no fallback UI was specified.\n\nAdd a <Suspense fallback=...> component higher in the tree to provide a loading indicator or placeholder to display.",
"412": "Connection closed.",
"413": "Expected finished root and lanes to be set. This is a bug in React.",
"414": "Did not expect this call in production. This is a bug in React. Please file an issue.",
"415": "Error parsing the data. It's probably an error code or network corruption.",
[Fizz/Flight] pipeToNodeWritable(..., writable).startWriting() -> renderToPipeableStream(...).pipe(writable) (#22450) * Rename pipeToNodeWritable to renderToNodePipe * Add startWriting API to Flight We don't really need it in this case because there's way less reason to delay the stream in Flight. * Pass the destination to startWriting instead of renderToNode * Rename startWriting to pipe This mirrors the ReadableStream API in Node * Error codes * Rename to renderToPipeableStream This mimics the renderToReadableStream API for the browser.
2021-10-06 00:31:06 -04:00
"416": "This environment don't support binary chunks.",
Throw on hydration mismatch and force client rendering if boundary hasn't suspended within concurrent root (#22629) * Throw on hydration mismatch * remove debugger * update error message * update error message part2... * fix test? * test? :( * tests 4real * remove useRefAccessWarning gating * split markSuspenseBoundary and getNearestBoundary * also assert html is correct * replace-fork * also remove client render flag on suspend * replace-fork * fix mismerge????
2021-11-09 13:40:50 -05:00
"417": "React currently only supports piping to one writable stream.",
s/HTML/text for text hydration mismatches (#32763)
2025-03-26 17:39:52 -04:00
"418": "Hydration failed because the server rendered %s didn't match the client. As a result this tree will be regenerated on the client. This can happen if a SSR-ed Client Component used:\n\n- A server/client branch `if (typeof window !== 'undefined')`.\n- Variable input such as `Date.now()` or `Math.random()` which changes each time it's called.\n- Date formatting in a user's locale which doesn't match the server.\n- External changing data without sending a snapshot of it along with the HTML.\n- Invalid HTML tag nesting.\n\nIt can also happen if the client has a browser extension installed which messes with the HTML before React loaded.\n\nhttps://react.dev/link/hydration-mismatch%s",
Log a recoverable error whenever hydration fails (#23319) There are several cases where hydration fails, server-rendered HTML is discarded, and we fall back to client rendering. Whenever this happens, we will now log an error with onRecoverableError, with a message explaining why. In some of these scenarios, this is not the only recoverable error that is logged. For example, an error during hydration will cause hydration to fail, which is itself an error. So we end up logging two separate errors: the original error, and one that explains why hydration failed. I've made sure that the original error always gets logged first, to preserve the causal sequence. Another thing we could do is aggregate the errors with the Error "cause" feature and AggregateError. Since these are new-ish features in JavaScript, we'd need a fallback behavior. I'll leave this for a follow up.
2022-02-17 15:16:17 -05:00
"419": "The server could not finish this Suspense boundary, likely due to an error during server rendering. Switched to client rendering.",
[ServerContext] Flight support for ServerContext (#23244) * Flight side of server context * 1 more test * rm unused function * flow+prettier * flow again =) * duplicate ReactServerContext across packages * store default value when lazily initializing server context * . * better comment * derp... missing import * rm optional chaining * missed feature flag * React.__SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED ?? * add warning if non ServerContext passed into useServerContext * pass context in as array of arrays * make importServerContext nott pollute the global context state * merge main * remove useServerContext * dont rely on object getters in ReactServerContext and disallow JSX * add symbols to devtools + rename globalServerContextRegistry to just ContextRegistry * gate test case as experimental * feedback * remove unions * Lint * fix oopsies (tests/lint/mismatching arguments/signatures * lint again * replace-fork * remove extraneous change * rebase * 1 more test * rm unused function * flow+prettier * flow again =) * duplicate ReactServerContext across packages * store default value when lazily initializing server context * . * better comment * derp... missing import * rm optional chaining * missed feature flag * React.__SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED ?? * add warning if non ServerContext passed into useServerContext * pass context in as array of arrays * make importServerContext nott pollute the global context state * merge main * remove useServerContext * dont rely on object getters in ReactServerContext and disallow JSX * add symbols to devtools + rename globalServerContextRegistry to just ContextRegistry * gate test case as experimental * feedback * remove unions * Lint * fix oopsies (tests/lint/mismatching arguments/signatures * lint again * replace-fork * remove extraneous change * rebase * reinline * rebase * add back changes lost due to rebase being hard * emit chunk for provider * remove case for React provider type * update type for SomeChunk * enable flag with experimental * add missing types * fix flow type * missing type * t: any * revert extraneous type change * better type * better type * feedback * change import to type import * test? * test? * remove react-dom * remove react-native-renderer from react-server-native-relay/package.json * gate change in FiberNewContext, getComponentNameFromType, use switch statement in FlightServer * getComponentNameFromTpe: server context type gated and use displayName if available * fallthrough * lint.... * POP * lint
2022-03-08 07:55:32 -05:00
"420": "ServerContext: %s already defined",
"421": "This Suspense boundary received an update before it finished hydrating. This caused the boundary to switch to client rendering. The usual way to fix this is to wrap the original update in startTransition.",
Use a Wrapper Error for onRecoverableError with a "cause" Field for the real Error (#28736) We basically have four kinds of recoverable errors: - Hydration mismatches. - Server errored but client didn't. - Hydration render errored but client render didn't (in Root or Suspense boundary). - Concurrent render errored but synchronous render didn't. For the first three we log an additional error that the root or Suspense boundary didn't error. This provides some context about what happened. However, the problem is that for hydration mismatches that's unnecessary extra context that is confusing. We also don't log any additional context for concurrent render errors that could recover. This used to be the only recoverable error so it didn't need extra context but now we need to distinguish them. When we log these to `reportError` it's confusing to just see the error because you didn't see anything error on the page. It's also hard to group them together as one. In this PR, I remove the unnecessary context for hydration mismatches. For hydration and concurrent errors, I now wrap them in an error that describes that what happened but then use the new `cause` field to link the original error so we can keep that as the cause. The error that happened was that hydration client rendered or you deopted to sync render, the cause of that error is some other error. For server errors, we control the Error object so I already had added some context to that error object's message. Since we hide the message in prod, it's nice not to have the raw message in DEV neither. We could potentially split these into two errors for parity though.
2024-04-03 21:53:07 -04:00
"422": "There was an error while hydrating but React was able to recover by instead client rendering from the nearest Suspense boundary.",
"423": "There was an error while hydrating but React was able to recover by instead client rendering the entire root.",
[ServerContext] Flight support for ServerContext (#23244) * Flight side of server context * 1 more test * rm unused function * flow+prettier * flow again =) * duplicate ReactServerContext across packages * store default value when lazily initializing server context * . * better comment * derp... missing import * rm optional chaining * missed feature flag * React.__SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED ?? * add warning if non ServerContext passed into useServerContext * pass context in as array of arrays * make importServerContext nott pollute the global context state * merge main * remove useServerContext * dont rely on object getters in ReactServerContext and disallow JSX * add symbols to devtools + rename globalServerContextRegistry to just ContextRegistry * gate test case as experimental * feedback * remove unions * Lint * fix oopsies (tests/lint/mismatching arguments/signatures * lint again * replace-fork * remove extraneous change * rebase * 1 more test * rm unused function * flow+prettier * flow again =) * duplicate ReactServerContext across packages * store default value when lazily initializing server context * . * better comment * derp... missing import * rm optional chaining * missed feature flag * React.__SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED ?? * add warning if non ServerContext passed into useServerContext * pass context in as array of arrays * make importServerContext nott pollute the global context state * merge main * remove useServerContext * dont rely on object getters in ReactServerContext and disallow JSX * add symbols to devtools + rename globalServerContextRegistry to just ContextRegistry * gate test case as experimental * feedback * remove unions * Lint * fix oopsies (tests/lint/mismatching arguments/signatures * lint again * replace-fork * remove extraneous change * rebase * reinline * rebase * add back changes lost due to rebase being hard * emit chunk for provider * remove case for React provider type * update type for SomeChunk * enable flag with experimental * add missing types * fix flow type * missing type * t: any * revert extraneous type change * better type * better type * feedback * change import to type import * test? * test? * remove react-dom * remove react-native-renderer from react-server-native-relay/package.json * gate change in FiberNewContext, getComponentNameFromType, use switch statement in FlightServer * getComponentNameFromTpe: server context type gated and use displayName if available * fallthrough * lint.... * POP * lint
2022-03-08 07:55:32 -05:00
"424": "This root received an early update, before anything was able hydrate. Switched the entire root to client rendering.",
"425": "Text content does not match server-rendered HTML.",
"426": "A component suspended while responding to synchronous input. This will cause the UI to be replaced with a loading indicator. To fix, updates that suspend should be wrapped with startTransition.",
"427": "useServerContext expects a context created with React.createServerContext",
"428": "useServerContext is only supported while rendering.",
"429": "ServerContext: %s already defined",
"430": "ServerContext can only have a value prop and children. Found: %s",
[Fizz] Send errors down to client (#24551) * use return from onError * export getSuspenseInstanceFallbackError * stringToChunk * return string from onError in downstream type signatures * 1 more type * support encoding errors in html stream and escape user input This commit adds another way to get errors to the suspense instance by encoding them as dataset properties of a template element at the head of the boundary. Previously if there was an error before the boundary flushed there was no way to stream the error to the client because there would never be a client render instruction. Additionally the error is sent in 3 parts 1) error hash - this is always sent (dev or prod) if one is provided 2) error message - Dev only 3) error component stack - Dev only, this now captures the stack at the point of error Another item addressed in this commit is the escaping of potentially unsafe data. all error components are escaped as test for browers when written into the html and as javascript strings when written into a client render instruction. * nits Co-authored-by: Marco Salazar <salazarm@fb.com>
2022-05-29 23:07:10 -07:00
"431": "React elements are not allowed in ServerContext",
[Fizz] Support abort reasons (#24680) * [Fizz] Support abort reasons Fizz supports aborting the render but does not currently accept a reason. The various render functions that use Fizz have some automatic and some user-controlled abort semantics that can be useful to communicate with the running program and users about why an Abort happened. This change implements abort reasons for renderToReadableStream and renderToPipeable stream as well as legacy renderers such as renderToString and related implementations. For AbortController implementations the reason passed to the abort method is forwarded to Fizz and sent to the onError handler. If no reason is provided the AbortController should construct an AbortError DOMException and as a fallback Fizz will generate a similar error in the absence of a reason For pipeable streams, an abort function is returned alongside pipe which already accepted a reason. That reason is now forwarded to Fizz and the implementation described above. For legacy renderers there is no exposed abort functionality but it is used internally and the reasons provided give useful context to, for instance to the fact that Suspense is not supported in renderToString-like renderers
2022-06-07 22:36:09 -07:00
"432": "The render was aborted by the server without a reason.",
[Fizz] Disallow complex children in <title> elements (#24679) * [Fizz] Disallow complex children in <title> elements <title> Elements in the DOM can only have Text content. In Fizz if more than one text node is emitted an HTML comment node is used as a text separator. Unfortunately because of the content restriction of the DOM representation of the title element this separator is displayed as escaped text which is not what the component author intended. This commit special cases title handling, primarily to issue warnings if you pass complex children to <title>. At the moment title expects to receive a single child or an array of length 1. In both cases the type of that child must be string or number. If anything more complex is provided a warning will be logged to the console explaining why this is problematic. There is no runtime behavior change so broken things are still broken (e.g. returning two text nodes which will cause a separator or using Suspense inside title children) but they should at least be accompanied by warnings that are useful. One edge case that will now warn but won't technically break an application is if you use a Component that returns a single string as a child of title. This is a form of indirection that works but becasue we cannot discriminate between a Component that will follow the rules and one that violates them the warning is issued regardless. * fixup dev warning conditional logic * lints * fix bugs
2022-06-07 03:33:36 -04:00
"433": "useId can only be used while React is rendering",
Suspending inside a hidden tree should not cause fallbacks to appear (#24699) * [FORKED] Hidden trees should capture Suspense If something suspends inside a hidden tree, it should not affect anything in the visible part of the UI. This means that Offscreen acts like a Suspense boundary whenever it's in its hidden state. * Add previous commit to forked revisions
2022-07-05 17:51:27 -04:00
"434": "`dangerouslySetInnerHTML` does not make sense on <title>.",
Implement basic stylesheet Resources for react-dom (#25060) Implement basic support for "Resources". In the context of this commit, the only thing that is currently a Resource are <link rel="stylesheet" precedence="some-value" ...> Resources can be rendered anywhere in the react tree, even outside of normal parenting rules, for instance you can render a resource before you have rendered the <html><head> tags for your application. In the stream we reorder this so the browser always receives valid HTML and resources are emitted either in place (normal circumstances) or at the top of the <head> (when you render them above or before the <head> in your react tree) On the client, resources opt into an entirely different hydration path. Instead of matching the location within the Document these resources are queried for in the entire document. It is an error to have more than one resource with the same href attribute. The use of precedence here as an opt-in signal for resourcifying the link is in preparation for a more complete Resource implementation which will dedupe resource references (multiple will be valid), hoist to the appropriate container (body, head, or elsewhere), order (according to precedence) and Suspend boundaries that depend on them. More details will come in the coming weeks on this plan. This feature is gated by an experimental flag and will only be made available in experimental builds until some future time.
2022-08-12 13:27:53 -07:00
"435": "Unexpected Suspense handler tag (%s). This is a bug in React.",
"436": "Stylesheet resources need a unique representation in the DOM while hydrating and more than one matching DOM Node was found. To fix, ensure you are only rendering one stylesheet link with an href attribute of \"%s\".",
experimental_use(promise) (#25084) * Internal `act`: Unwrapping resolved promises This update our internal implementation of `act` to support React's new behavior for unwrapping promises. Like we did with Scheduler, when something suspends, it will yield to the main thread so the microtasks can run, then continue in a new task. I need to implement the same behavior in the public version of `act`, but there are some additional considerations so I'll do that in a separate commit. * Move throwException to after work loop resumes throwException is the function that finds the nearest boundary and schedules it for a second render pass. We should only call it right before we unwind the stack — not if we receive an immediate ping and render the fiber again. This was an oversight in 8ef3a7c that I didn't notice because it happens to mostly work, anyway. What made me notice the mistake is that throwException also marks the entire render phase as suspended (RootDidSuspend or RootDidSuspendWithDelay), which is only supposed to be happen if we show a fallback. One consequence was that, in the RootDidSuspendWithDelay case, the entire commit phase was blocked, because that's the exit status we use to block a bad fallback from appearing. * Use expando to check whether promise has resolved Add a `status` expando to a thrown thenable to track when its value has resolved. In a later step, we'll also use `value` and `reason` expandos to track the resolved value. This is not part of the official JavaScript spec — think of it as an extension of the Promise API, or a custom interface that is a superset of Thenable. However, it's inspired by the terminology used by `Promise.allSettled`. The intent is that this will be a public API — Suspense implementations can set these expandos to allow React to unwrap the value synchronously without waiting a microtask. * Scaffolding for `experimental_use` hook Sets up a new experimental hook behind a feature flag, but does not implement it yet. * use(promise) Adds experimental support to Fiber for unwrapping the value of a promise inside a component. It is not yet implemented for Server Components, but that is planned. If promise has already resolved, the value can be unwrapped "immediately" without showing a fallback. The trick we use to implement this is to yield to the main thread (literally suspending the work loop), wait for the microtask queue to drain, then check if the promise resolved in the meantime. If so, we can resume the last attempted fiber without unwinding the stack. This functionality was implemented in previous commits. Another feature is that the promises do not need to be cached between attempts. Because we assume idempotent execution of components, React will track the promises that were used during the previous attempt and reuse the result. You shouldn't rely on this property, but during initial render it mostly just works. Updates are trickier, though, because if you used an uncached promise, we have no way of knowing whether the underlying data has changed, so we have to unwrap the promise every time. It will still work, but it's inefficient and can lead to unnecessary fallbacks if it happens during a discrete update. When we implement this for Server Components, this will be less of an issue because there are no updates in that environment. However, it's still better for performance to cache data requests, so the same principles largely apply. The intention is that this will eventually be the only supported way to suspend on arbitrary promises. Throwing a promise directly will be deprecated.
2022-08-25 14:12:07 -04:00
"437": "the \"precedence\" prop for links to stylesheets expects to receive a string but received something of type \"%s\" instead.",
[Flight] Minor error handling fixes (#25151) * Fix error handling when the Flight client itself errors * Serialize references to errors in the error priority queue It doesn't make sense to emit references to future values at higher pri than the value that they're referencing. This ensures that we don't emit hard forward references to values that don't yet exist.
2022-08-31 18:40:17 -04:00
"438": "An unsupported type was passed to use(): %s",
experimental_useEvent (#25229) This commit adds a new hook `useEvent` per the RFC [here](https://github.com/reactjs/rfcs/pull/220), gated as experimental. Co-authored-by: Rick Hanlon <rickhanlonii@gmail.com> Co-authored-by: Rick Hanlon <rickhanlonii@fb.com> Co-authored-by: Lauren Tan <poteto@users.noreply.github.com>
2022-09-14 14:39:06 -04:00
"439": "We didn't expect to see a forward reference. This is a bug in the React Server.",
Rename experimental useEvent to useEffectEvent (#25881) We originally had grand plans for using this Event concept for more but now it's only meant to be used in combination with effects. It's an Event in the FRP terms, that is triggered from an Effect. Technically it can also be from another function that itself is triggered from an existing side-effect but that's kind of an advanced case. The canonical case is an effect that triggers an event: ```js const onHappened = useEffectEvent(() => ...); useEffect(() => { onHappened(); }, []); ```
2022-12-14 15:08:29 -05:00
"440": "A function wrapped in useEffectEvent can't be called during rendering.",
[Fizz/Float] Float for stylesheet resources (#25243) * [Fizz/Float] Float for stylesheet resources This commit implements Float in Fizz and on the Client. The initial set of supported APIs is roughly 1. Convert certain stylesheets into style Resources when opting in with precedence prop 2. Emit preloads for stylesheets and explicit preload tags 3. Dedupe all Resources by href 4. Implement ReactDOM.preload() to allow for imperative preloading 5. Implement ReactDOM.preinit() to allow for imperative preinitialization Currently supports 1. style Resources (link rel "stylesheet") 2. font Resources (preload as "font") later updates will include support for scripts and modules
2022-09-30 16:14:04 -07:00
"441": "An error occurred in the Server Components render. The specific message is omitted in production builds to avoid leaking sensitive details. A digest property is included on this error instance which may provide additional details about the nature of the error.",
"442": "The current renderer does not support Resources. This error is likely caused by a bug in React. Please file an issue.",
"443": "acquireResource encountered a resource type it did not expect: \"%s\". this is a bug in React.",
Model Float on Hoistables semantics (#26106) ## Hoistables In the original implementation of Float, all hoisted elements were treated like Resources. They had deduplication semantics and hydrated based on a key. This made certain kinds of hoists very challenging such as sequences of meta tags for `og:image:...` metadata. The reason is each tag along is not dedupable based on only it's intrinsic properties. two identical tags may need to be included and hoisted together with preceding meta tags that describe a semantic object with a linear set of html nodes. It was clear that the concept of Browser Resources (stylesheets / scripts / preloads) did not extend universally to all hositable tags (title, meta, other links, etc...) Additionally while Resources benefit from deduping they suffer an inability to update because while we may have multiple rendered elements that refer to a single Resource it isn't unambiguous which element owns the props on the underlying resource. We could try merging props, but that is still really hard to reason about for authors. Instead we restrict Resource semantics to freezing the props at the time the Resource is first constructed and warn if you attempt to render the same Resource with different props via another rendered element or by updating an existing element for that Resource. This lack of updating restriction is however way more extreme than necessary for instances that get hoisted but otherwise do not dedupe; where there is a well defined DOM instance for each rendered element. We should be able to update props on these instances. Hoistable is a generalization of what Float tries to model for hoisting. Instead of assuming every hoistable element is a Resource we now have two distinct categories, hoistable elements and hoistable resources. As one might guess the former has semantics that match regular Host Components except the placement of the node is usually in the <head>. The latter continues to behave how the original implementation of HostResource behaved with the first iteration of Float ### Hoistable Element On the server hoistable elements render just like regular tags except the output is stored in special queues that can be emitted in the stream earlier than they otherwise would be if rendered in place. This also allow for instance the ability to render a hoistable before even rendering the <html> tag because the queues for hoistable elements won't flush until after we have flushed the preamble (`<DOCTYPE html><html><head>`). On the client, hoistable elements largely operate like HostComponents. The most notable difference is in the hydration strategy. If we are hydrating and encounter a hoistable element we will look for all tags in the document that could potentially be a match and we check whether the attributes match the props for this particular instance. We also do this in the commit phase rather than the render phase. The reason hydration can be done for HostComponents in render is the instance will be removed from the document if hydration fails so mutating it in render is safe. For hoistables the nodes are not in a hydration boundary (Root or SuspenseBoundary at time of writing) and thus if hydration fails and we may have an instance marked as bound to some Fiber when that Fiber never commits. Moving the hydration matching to commit ensures we will always succeed in pairing the hoisted DOM instance with a Fiber that has committed. ### Hoistable Resource On the server and client the semantics of Resources are largely the same they just don't apply to title, meta, and most link tags anymore. Resources hoist and dedupe via an `href` key and are ref counted. In a future update we will add a garbage collector so we can clean up Resources that no longer have any references ## `<style>` support In earlier implementations there was no support for <style> tags. This PR adds support for treating `<style href="..." precedence="...">...</style>` as a Resource analagous to `<link rel="stylesheet" href="..." precedence="..." />` It may seem odd at first to require an href to get Resource semantics for a style tag. The rationale is that these are for inlining of actual external stylesheets as an optimization and for URI like scoping of inline styles for css-in-js libraries. The href indicates that the key space for `<style>` and `<link rel="stylesheet" />` Resources is shared. and the precedence is there to allow for interleaving of both kinds of Style resources. This is an advanced feature that we do not expect most app developers to use directly but will be quite handy for various styling libraries and for folks who want to inline as much as possible once Fizz supports this feature. ## refactor notes * HostResource Fiber type is renamed HostHoistable to reflect the generalization of the concept * The Resource object representation is modified to reduce hidden class checks and to use less memory overall * The thing that distinguishes a resource from an element is whether the Fiber has a memoizedState. If it does, it will use resource semantics, otherwise element semantics * The time complexity of matching hositable elements for hydration should be improved
2023-02-09 22:59:29 -08:00
"444": "getResource encountered a type it did not expect: \"%s\". this is a bug in React.",
[Fizz/Float] Float for stylesheet resources (#25243) * [Fizz/Float] Float for stylesheet resources This commit implements Float in Fizz and on the Client. The initial set of supported APIs is roughly 1. Convert certain stylesheets into style Resources when opting in with precedence prop 2. Emit preloads for stylesheets and explicit preload tags 3. Dedupe all Resources by href 4. Implement ReactDOM.preload() to allow for imperative preloading 5. Implement ReactDOM.preinit() to allow for imperative preinitialization Currently supports 1. style Resources (link rel "stylesheet") 2. font Resources (preload as "font") later updates will include support for scripts and modules
2022-09-30 16:14:04 -07:00
"445": "\"currentResources\" was expected to exist. This is a bug in React.",
track resources in different roots separately (#25388) * track resources in different roots separately * flow types * add test demonstrating portals deep into shadowRoots * revert hostcontext changes * lints * funge style cache key a la ReactDOMComponentTree * hide hacks in componentTree
2022-10-04 16:11:15 -07:00
"446": "\"resourceRoot\" was expected to exist. This is a bug in React.",
Server render fork for react-dom (#25436) Publish an aliasable entry for `react-dom` top level package exports for use in server environments. This is a stub containing only the exports that we expect to retain in the top level once 19 is released
2022-10-10 11:06:22 -07:00
"447": "While attempting to insert a Resource, React expected the Document to contain a head element but it was not found.",
"448": "createPortal was called on the server. Portals are not currently supported on the server. Update your program to conditionally call createPortal on the client only.",
Implement HostSingleton Fiber type (#25426)
2022-10-11 08:42:42 -07:00
"449": "flushSync was called on the server. This is likely caused by a function being called during render or in module scope that was intended to be called from an effect or event handler. Update your to not call flushSync no the server.",
"450": "The current renderer does not support Singletons. This error is likely caused by a bug in React. Please file an issue.",
"451": "resolveSingletonInstance was called with an element type that is not supported. This is a bug in React.",
"452": "React expected an <html> element (document.documentElement) to exist in the Document but one was not found. React never removes the documentElement for any Document it renders into so the cause is likely in some other script running on this page.",
"453": "React expected a <head> element (document.head) to exist in the Document but one was not found. React never removes the head for any Document it renders into so the cause is likely in some other script running on this page.",
Split Cache into its own Dispatcher (#25474) * Missing Hooks * Remove www forks. These can use __SECRET... instead. * Move cache to separate dispatcher These will be available in more contexts than just render.
2022-10-12 23:13:39 -04:00
"454": "React expected a <body> element (document.body) to exist in the Document but one was not found. React never removes the body for any Document it renders into so the cause is likely in some other script running on this page.",
Add detach to Offscreen component (#25265)
2022-10-18 15:56:41 +01:00
"455": "This CacheSignal was requested outside React which means that it is immediately aborted.",
[Float] support meta tags as Resources (#25514) Stacked on #25508 This PR adds meta tags as a resource type. metas are classified in the following priority 1. charset 2. http-equiv 3. property 4. name 5. itemprop when using property, there is special logic for og type properties where a `property="og:image:height"` following a `property="og:image"` will inherit the key of the previous tag. this relies on timing effects to stay consistent so when mounting new metas it is important that if structured properties are being used all members of a structure mount together. This is similarly true for arrays where the implicit sequential order defines the array structure. if you need an array you need to mount all array members in the same pass.
2022-10-21 15:21:29 -07:00
"456": "Calling Offscreen.detach before instance handle has been set.",
[Flight] Use AsyncLocalStorage to extend the scope of the cache to micro tasks (#25542) This extends the scope of the cache and fetch instrumentation using AsyncLocalStorage for microtasks. This is an intermediate step. It sets up the dispatcher only once. This is unique to RSC because it uses the react.shared-subset module for its shared state. Ideally we should support multiple renderers. We should also have this take over from an outer SSR's instrumented fetch. We should also be able to have a fallback to global state per request where AsyncLocalStorage doesn't exist and then the whole client-side solutions. I'm still figuring out the right wiring for that so this is a temporary hack.
2022-10-23 01:06:58 -04:00
"457": "acquireHeadResource encountered a resource type it did not expect: \"%s\". This is a bug in React.",
Detect and warn if use(promise) is wrapped with try/catch block (#25543) The old (unstable) mechanism for suspending was to throw a promise. The purpose of throwing is to interrupt the component's execution, and also to signal to React that the interruption was caused by Suspense as opposed to some other error. A flaw is that throwing is meant to be an implementation detail — if code in userspace catches the promise, it can lead to unexpected behavior. With `use`, userspace code does not throw promises directly, but `use` itself still needs to throw something to interrupt the component and unwind the stack. The solution is to throw an internal error. In development, we can detect whether the error was caught by a userspace try/catch block and log a warning — though it's not foolproof, since a clever user could catch the object and rethrow it later. The error message includes advice to move `use` outside of the try/catch block. I did not yet implement the warning in Flight.
2022-10-28 14:46:03 -07:00
"458": "Currently React only supports one RSC renderer at a time.",
"459": "Expected a suspended thenable. This is a bug in React. Please file an issue.",
Track separate SuspendedOnAction flag by rethrowing a separate SuspenseActionException sentinel (#31554) This lets us track separately if something was suspended on an Action using useActionState rather than suspended on Data. This approach feels quite bloated and it seems like we'd eventually might want to read more information about the Promise that suspended and the context it suspended in. As a more general reason for suspending. The way useActionState works in combination with the prewarming is quite unfortunate because 1) it renders blocking to update the isPending flag whether you use it or not 2) it prewarms and suspends the useActionState 3) then it does another third render to get back into the useActionState position again.
2024-11-15 17:52:24 -05:00
"460": "Suspense Exception: This is not a real error! It's an implementation detail of `use` to interrupt the current render. You must either rethrow it immediately, or move the `use` call outside of the `try/catch` block. Capturing without rethrowing will lead to unexpected behavior.\n\nTo handle async errors, wrap your component in an error boundary, or call the promise's `.catch` method and pass the result to `use`.",
Track ThenableState alongside other hooks Now that hook state is preserved while the work loop is suspended, we don't need to track the thenable state in the work loop. We can track it alongside the rest of the hook state. This is a nice simplification and also aligns better with how it works in Fizz and Flight. The promises will still be cleared when the component finishes rendering (either complete or unwind). In the future, we could stash the promises on the fiber and reuse them during an update. However, this would only work for `use` calls that occur before an prop/state/context is processed, because `use` calls can only be assumed to execute in the same order if no other props/state/context have changed. So it might not be worth doing until we have finer grained memoization.
2022-11-03 19:25:43 -04:00
"461": "This is not a real error. It's an implementation detail of React's selective hydration feature. If this leaks into userspace, it's a bug in React. Please file an issue.",
Add Bun streaming server renderer (#25597) Add support for Bun server renderer
2022-11-17 13:15:56 -08:00
"462": "Unexpected SuspendedReason. This is a bug in React.",
"463": "ReactDOMServer.renderToNodeStream(): The Node Stream API is not available in Bun. Use ReactDOMServer.renderToReadableStream() instead.",
[ServerRenderer] Add option to send instructions as data attributes (#25437) ### Changes made: - Running with enableFizzExternalRuntime (feature flag) and unstable_externalRuntimeSrc (param) will generate html nodes with data attributes that encode Fizz instructions. ``` <div hidden data-rxi="" data-bid="param0" data-dgst="param1" ></div> ``` - Added an external runtime browser script `ReactDOMServerExternalRuntime`, which processes and removes these nodes - This runtime should be passed as to renderInto[...] via `unstable_externalRuntimeSrc` - Since this runtime is render blocking (for all streamed suspense boundaries and segments), we want this to reach the client as early as possible. By default, Fizz will send this script at the end of the shell when it detects dynamic content (e.g. suspenseful pending tasks), but it can be sent even earlier by calling `preinit(...)` inside a component. - The current implementation relies on Float to dedupe sending `unstable_externalRuntimeSrc`, so `enableFizzExternalRuntime` is only valid when `enableFloat` is also set.
2022-11-30 13:22:08 -05:00
"464": "ReactDOMServer.renderToStaticNodeStream(): The Node Stream API is not available in Bun. Use ReactDOMServer.renderToReadableStream() instead.",
Enable passing Server References from Server to Client (#26124) This is the first of a series of PRs, that let you pass functions, by reference, to the client and back. E.g. through Server Context. It's like client references but they're opaque on the client and resolved on the server. To do this, for security, you must opt-in to exposing these functions to the client using the `"use server"` directive. The `"use client"` directive lets you enter the client from the server. The `"use server"` directive lets you enter the server from the client. This works by tagging those functions as Server References. We could potentially expand this to other non-serializable or stateful objects too like classes. This only implements server->server CJS imports and server->server ESM imports. We really should add a loader to the webpack plug-in for client->server imports too. I'll leave closures as an exercise for integrators. You can't "call" a client reference on the server, however, you can "call" a server reference on the client. This invokes a callback on the Flight client options called `callServer`. This lets a router implement calling back to the server. Effectively creating an RPC. This is using JSON for serializing those arguments but more utils coming from client->server serialization.
2023-02-09 19:45:05 -05:00
"465": "enableFizzExternalRuntime without enableFloat is not supported. This should never appear in production, since it means you are using a misconfigured React bundle.",
Switch to mount dispatcher after use() when needed (#26232) When resuming a suspended render, there may be more Hooks to be called that weren't seen the previous time through. Make sure to switch to the mount dispatcher when calling use() if the next Hook call should be treated as a mount. Fixes #25964.
2023-02-24 12:06:27 -08:00
"466": "Trying to call a function from \"use server\" but the callServer option was not implemented in your router runtime.",
[Float][Fiber] implement a faster hydration match for hoistable elements (#26154) This PR is now based on #26256 The original matching function for `hydrateHoistable` some challenging time complexity since we built up the list of matchable nodes for each link of that type and then had to check to exclusion. This new implementation aims to improve the complexity For hoisted title tags we match the first title if it is valid (not in SVG context and does not have `itemprop`, the two ways you opt out of hoisting when rendering titles). This path is much faster than others and we use it because valid Documents only have 1 title anyway and if we did have a mismatch the rendered title still ends up as the Document.title so there is no functional degradation for misses. For hoisted link and meta tags we track all potentially hydratable Elements of this type in a cache per Document. The cache is refreshed once each commit if and only if there is a title or meta hoistable hydrating. The caches are partitioned by a natural key for each type (href for link and content for meta). Then secondary attributes are checked to see if the potential match is matchable. For link we check `rel`, `title`, and `crossorigin`. These should provide enough entropy that we never have collisions except is contrived cases and even then it should not affect functionality of the page. This should also be tolerant of links being injected in arbitrary places in the Document by 3rd party scripts and browser extensions For meta we check `name`, `property`, `http-equiv`, and `charset`. These should provide enough entropy that we don't have meaningful collisions. It is concievable with og tags that there may be true duplciates `<meta property="og:image:size:height" content="100" />` but even if we did bind to the wrong instance meta tags are typically only read from SSR by bots and rarely inserted by 3rd parties so an adverse functional outcome is not expected.
2023-03-06 19:52:35 -08:00
"467": "Update hook called on initial render. This is likely a bug in React. Please file an issue.",
[Flight Reply] Add Reply Encoding (#26360) This adds `encodeReply` to the Flight Client and `decodeReply` to the Flight Server. Basically, it's a reverse Flight. It serializes values passed from the client to the server. I call this a "Reply". The tradeoffs and implementation details are a bit different so it requires its own implementation but is basically a clone of the Flight Server/Client but in reverse. Either through callServer or ServerContext. The goal of this project is to provide the equivalent serialization as passing props through RSC to client. Except React Elements and Components and such. So that you can pass a value to the client and back and it should have the same serialization constraints so when we add features in one direction we should mostly add it in the other. Browser support for streaming request bodies are currently very limited in that only Chrome supports it. So this doesn't produce a ReadableStream. Instead `encodeReply` produces either a JSON string or FormData. It uses a JSON string if it's a simple enough payload. For advanced features it uses FormData. This will also let the browser stream things like File objects (even though they're not yet supported since it follows the same rules as the other Flight). On the server side, you can either consume this by blocking on generating a FormData object or you can stream in the `multipart/form-data`. Even if the client isn't streaming data, the network does. On Node.js busboy seems to be the canonical library for this, so I exposed a `decodeReplyFromBusboy` in the Node build. However, if there's ever a web-standard way to stream form data, or if a library wins in that space we can support it. We can also just build a multipart parser that takes a ReadableStream built-in. On the server, server references passed as arguments are loaded from Node or Webpack just like the client or SSR does. This means that you can create higher order functions on the client or server. This can be tokenized when done from a server components but this is a security implication as it might be tempting to think that these are not fungible but you can swap one function for another on the client. So you have to basically treat an incoming argument as insecure, even if it's a function. I'm not too happy with the naming parity: Encode `server.renderToReadableStream` Decode: `client.createFromFetch` Decode `client.encodeReply` Decode: `server.decodeReply` This is mainly an implementation details of frameworks but it's annoying nonetheless. This comes from that `renderToReadableStream` does do some "rendering" by unwrapping server components etc. The `create` part comes from the parity with Fizz/Fiber where you `render` on the server and `create` a root on the client. Open to bike-shedding this some more. --------- Co-authored-by: Josh Story <josh.c.story@gmail.com>
2023-03-10 11:36:15 -05:00
"468": "getNodesForType encountered a type it did not expect: \"%s\". This is a bug in React.",
"469": "Client Functions cannot be passed directly to Server Functions. Only Functions passed from the Server can be passed back again.",
"470": "Only global symbols received from Symbol.for(...) can be passed to Server Functions. The symbol Symbol.for(%s) cannot be found among global symbols.",
"471": "BigInt (%s) is not yet supported as an argument to a Server Function.",
"472": "Type %s is not supported as an argument to a Server Function.",
Check if suspensey instance resolves in immediate task (#26427) When rendering a suspensey resource that we haven't seen before, it may have loaded in the background while we were rendering. We should yield to the main thread to see if the load event fires in an immediate task. For example, if the resource for a link element has already loaded, its load event will fire in a task right after React yields to the main thread. Because the continuation task is not scheduled until right before React yields, the load event will ping React before it resumes. If this happens, we can resume rendering without showing a fallback. I don't think this matters much for images, because the `completed` property tells us whether the image has loaded, and during a non-urgent render, we never block the main thread for more than 5ms at a time (for now — we might increase this in the future). It matters more for stylesheets because the only way to check if it has loaded is by listening for the load event. This is essentially the same trick that `use` does for userspace promises, but a bit simpler because we don't need to replay the host component's begin phase; the work-in-progress fiber already completed, so we can just continue onto the next sibling without any additional work. As part of this change, I split the `shouldSuspendCommit` host config method into separate `maySuspendCommit` and `preloadInstance` methods. Previously `shouldSuspendCommit` was used for both. This raised a question of whether we should preload resources during a synchronous render. My initial instinct was that we shouldn't, because we're going to synchronously block the main thread until the resource is inserted into the DOM, anyway. But I wonder if the browser is able to initiate the preload even while the main thread is blocked. It's probably a micro-optimization either way because most resources will be loaded during transitions, not urgent renders.
2023-03-20 12:35:10 -04:00
"473": "React doesn't accept base64 encoded file uploads because we don't except form data passed from a browser to ever encode data that way. If that's the wrong assumption, we can easily fix it.",
[Float][Fiber] Implement waitForCommitToBeReady for stylesheet resources (#26450) Before a commit is finished if any new stylesheet resources are going to mount and we are capable of delaying the commit we will do the following 1. Wait for all preloads for newly created stylesheet resources to load 2. Once all preloads are finished we insert the stylesheet instances for these resources and wait for them all to load 3. Once all stylesheets have loaded we complete the commit In this PR I also removed the synchronous loadingstate tracking in the fizz runtime. It was not necessary to support the implementation on not used by the fizz runtime itself. It makes the inline script slightly smaller In this PR I also integrated ReactDOMFloatClient with ReactDOMHostConfig. It leads to better code factoring, something I already did on the server a while back. To make the diff a little easier to follow i make these changes in a single commit so you can look at the change after that commit if helpful There is a 500ms timeout which will finish the commit even if all suspended host instances have not finished loading yet At the moment error and load events are treated the same and we're really tracking whether the host instance is finished attempting to load.
2023-03-24 19:17:38 -07:00
"474": "Suspense Exception: This is not a real error, and should not leak into userspace. If you're seeing this, it's likely a bug in React.",
Rethrow errors from form actions (#26689) This is the next step toward full support for async form actions. Errors thrown inside form actions should cause the form to re-render and throw the error so it can be captured by an error boundary. The behavior is the same if the `<form />` had an internal useTransition hook, which is pretty much exactly how we implement it, too. The first time an action is called, the form's HostComponent is "upgraded" to become stateful, by lazily mounting a list of hooks. The rest of the implementation for function components can be shared. Because the error handling behavior added in this commit is just using useTransition under-the-hood, it also handles pending states, too. However, this pending state can't be observed until we add a new hook for that purpose. I'll add this next.
2023-04-21 13:29:46 -04:00
"475": "Internal React Error: suspendedState null when it was expected to exists. Please report this as a React bug.",
[Float][Flight] Flight support for Float (#26502) Stacked on #26557 Supporting Float methods such as ReactDOM.preload() are challenging for flight because it does not have an easy means to convey direct executions in other environments. Because the flight wire format is a JSON-like serialization that is expected to be rendered it currently only describes renderable elements. We need a way to convey a function invocation that gets run in the context of the client environment whether that is Fizz or Fiber. Fiber is somewhat straightforward because the HostDispatcher is always active and we can just have the FlightClient dispatch the serialized directive. Fizz is much more challenging becaue the dispatcher is always scoped but the specific request the dispatch belongs to is not readily available. Environments that support AsyncLocalStorage (or in the future AsyncContext) we will use this to be able to resolve directives in Fizz to the appropriate Request. For other environments directives will be elided. Right now this is pragmatic and non-breaking because all directives are opportunistic and non-critical. If this changes in the future we will need to reconsider how widespread support for async context tracking is. For Flight, if AsyncLocalStorage is available Float methods can be called before and after await points and be expected to work. If AsyncLocalStorage is not available float methods called in the sync phase of a component render will be captured but anything after an await point will be a noop. If a float call is dropped in this manner a DEV warning should help you realize your code may need to be modified. This PR also introduces a way for resources (Fizz) and hints (Flight) to flush even if there is not active task being worked on. This will help when Float methods are called in between async points within a function execution but the task is blocked on the entire function finishing. This PR also introduces deduping of Hints in Flight using the same resource keys used in Fizz. This will help shrink payload sizes when the same hint is attempted to emit over and over again
2023-04-21 20:45:51 -07:00
"476": "Expected the form instance to be a HostComponent. This is a bug in React.",
Fix: Resolve entangled actions independently (#26726) When there are multiple async actions at the same time, we entangle them together because we can't be sure which action an update might be associated with. (For this, we'd need AsyncContext.) However, if one of the async actions fails with an error, it should only affect that action, not all the other actions it may be entangled with. Resolving each action independently also means they can have independent pending state types, rather than being limited to an `isPending` boolean. We'll use this to implement an upcoming form API.
2023-04-25 20:43:20 -04:00
"477": "React Internal Error: processHintChunk is not implemented for Native-Relay. The fact that this method was called means there is a bug in React.",
Implement experimental_useOptimisticState (#26740) This adds an experimental hook tentatively called useOptimisticState. (The actual name needs some bikeshedding.) The headline feature is that you can use it to implement optimistic updates. If you set some optimistic state during a transition/action, the state will be automatically reverted once the transition completes. Another feature is that the optimistic updates will be continually rebased on top of the latest state. It's easiest to explain with examples; we'll publish documentation as the API gets closer to stabilizing. See tests for now. Technically the use cases for this hook are broader than just optimistic updates; you could use it implement any sort of "pending" state, such as the ones exposed by useTransition and useFormStatus. But we expect people will most often reach for this hook to implement the optimistic update pattern; simpler cases are covered by those other hooks.
2023-05-01 13:19:20 -04:00
"478": "Thenable should have already resolved. This is a bug in React.",
[Fizz] Allow an action provide a custom set of props to use for progressive enhancement (#26749) Stacked on top of #26735. This allows a framework to add a `$$FORM_ACTION` property to a function. This lets the framework return a set of props to use in place of the function but only during SSR. Effectively, this lets you implement progressive enhancement of form actions using some other way instead of relying on the replay feature. This will be used by RSC on Server References automatically by convention in a follow up, but this mechanism can also be used by other frameworks/libraries.
2023-05-01 16:01:14 -04:00
"479": "Cannot update optimistic state while rendering.",
[Fizz] Fallback to client replaying actions if we're trying to serialize a Blob (#28987) This follows the same principle as in #28611. We cannot serialize Blobs of a form data into HTML because you can't initialize a file input to some value. However the serialization of state in an Action can contain blobs. In this case we do error but outside the try/catch that recovers to error to client replaying instead of MPA mode. This errors earlier to ensure that this works. Testing this is a bit annoying because JSDOM doesn't have any of the Blob methods but the Blob needs to be compatible with FormData and the FormData needs to be compatible with `<form>` nodes in these tests. So I polyfilled those in JSDOM with some hacks. A possible future enhancement would be to encode these blobs in a base64 mode instead and have some way to receive them on the server. It's just a matter of layering this. I think the RSC layer's `FORM_DATA` implementation can pass some flag to encode as base64 and then have decodeAction include some way to parse them. That way this case would work in MPA mode too.
2024-05-07 21:53:10 -04:00
"480": "File/Blob fields are not yet supported in progressive forms. Will fallback to client hydration.",
Detect crashes caused by Async Client Components (#27019) Suspending with an uncached promise is not yet supported. We only support suspending on promises that are cached between render attempts. (We do plan to partially support this in the future, at least in certain constrained cases, like during a route transition.) This includes the case where a component returns an uncached promise, which is effectively what happens if a Client Component is authored using async/await syntax. This is an easy mistake to make in a Server Components app, because async/await _is_ available in Server Components. In the current behavior, this can sometimes cause the app to crash with an infinite loop, because React will repeatedly keep trying to render the component, which will result in a fresh promise, which will result in a new render attempt, and so on. We have some strategies we can use to prevent this — during a concurrent render, we can suspend the work loop until the promise resolves. If it's not a concurrent render, we can show a Suspense fallback and try again at concurrent priority. There's one case where neither of these strategies work, though: during a sync render when there's no parent Suspense boundary. (We refer to this as the "shell" of the app because it exists outside of any loading UI.) Since we don't have any great options for this scenario, we should at least error gracefully instead of crashing the app. So this commit adds a detection mechanism for render loops caused by async client components. The way it works is, if an app suspends repeatedly in the shell during a synchronous render, without committing anything in between, we will count the number of attempts and eventually trigger an error once the count exceeds a threshold. In the future, we will consider ways to make this case a warning instead of a hard error. See https://github.com/facebook/react/issues/26801 for more details.
2023-06-29 16:05:00 -04:00
"481": "Tried to encode a Server Action from a different instance than the encoder is from. This is a bug in React.",
Include component name in "async/await is not supported" error message if available (#32435)
2025-02-25 10:48:44 +01:00
"482": "An unknown Component is an async Client Component. Only Server Components can be async at the moment. This error is often caused by accidentally adding `'use client'` to a module that was originally written for the server.",
Add Postpone API (#27238) This adds an experimental `unstable_postpone(reason)` API. Currently we don't have a way to model effectively an Infinite Promise. I.e. something that suspends but never resolves. The reason this is useful is because you might have something else that unblocks it later. E.g. by updating in place later, or by client rendering. On the client this works to model as an Infinite Promise (in fact, that's what this implementation does). However, in Fizz and Flight that doesn't work because the stream needs to end at some point. We don't have any way of knowing that we're suspended on infinite promises. It's not enough to tag the promises because you could await those and thus creating new promises. The only way we really have to signal this through a series of indirections like async functions, is by throwing. It's not 100% safe because these values can be caught but it's the best we can do. Effectively `postpone(reason)` behaves like a built-in [Catch Boundary](https://github.com/facebook/react/pull/26854). It's like `raise(Postpone, reason)` except it's built-in so it needs to be able to be encoded and caught by Suspense boundaries. In Flight and Fizz these behave pretty much the same as errors. Flight just forwards it to retrigger on the client. In Fizz they just trigger client rendering which itself might just postpone again or fill in the value. The difference is how they get logged. In Flight and Fizz they log to `onPostpone(reason)` instead of `onError(error)`. This log is meant to help find deopts on the server like finding places where you fall back to client rendering. The reason that you pass in is for that purpose to help the reason for any deopts. I do track the stack trace in DEV but I don't currently expose it to `onPostpone`. This seems like a limitation. It might be better to expose the Postpone object which is an Error object but that's more of an implementation detail. I could also pass it as a second argument. On the client after hydration they don't get passed to `onRecoverableError`. There's no global `onPostpone` API to capture postponed things on the client just like there's no `onError`. At that point it's just assumed to be intentional. It doesn't have any `digest` or reason passed to the client since it's not logged. There are some hacky solutions that currently just tries to reuse as much of the existing code as possible but should be more properly implemented. - Fiber is currently just converting it to a fake Promise object so that it behaves like an infinite Promise. - Fizz is encoding the magic digest string `"POSTPONE"` in the HTML so we know to ignore it but it should probably just be something neater that doesn't share namespace with digests. Next I plan on using this in the `/static` entry points for additional features. Why "postpone"? It's basically a synonym to "defer" but we plan on using "defer" for other purposes and it's overloaded anyway.
2023-08-17 13:26:14 -04:00
"483": "Hooks are not supported inside an async component. This error is often caused by accidentally adding `'use client'` to a module that was originally written for the server.",
Scaffolding for useFormState (#27270) This exposes, but does not yet implement, a new experimental API called useFormState. It's gated behind the enableAsyncActions flag. useFormState has a similar signature to useReducer, except instead of a reducer it accepts an (async) action function. React will wait until the promise resolves before updating the state: ```js async function action(prevState, payload) { // .. } const [state, dispatch] = useFormState(action, initialState) ``` When used in combination with Server Actions, it will also support progressive enhancement — a form that is submitted before it has hydrated will have its state transferred to the next page. However, like the other action-related hooks, it works with fully client-driven actions, too.
2023-08-23 10:58:09 -04:00
"484": "A Server Component was postponed. The reason is omitted in production builds to avoid leaking sensitive details.",
[Fizz] Track postponed holes in the prerender pass (#27317) This is basically the implementation for the prerender pass. Instead of forking basically the whole implementation for prerender, I just add a conditional field on the request. If it's `null` it behaves like before. If it's non-`null` then instead of triggering client rendered boundaries it triggers those into a "postponed" state which is basically just a variant of "pending". It's supposed to be filled in later. It also builds up a serializable tree of which path can be followed to find the holes. This is basically a reverse `KeyPath` tree. It is unfortunate that this approach adds more code to the regular Fizz builds but in practice. It seems like this side is not going to add much code and we might instead just want to merge the builds so that it's smaller when you have `prerender` and `resume` in the same bundle - which I think will be common in practice. This just implements the prerender side, and not the resume side, which is why the tests have a TODO. That's in a follow up PR.
2023-08-31 12:23:26 -04:00
"485": "Cannot update form state while rendering.",
[Fizz] Replay Postponed Paths (#27379) This forks Task into ReplayTask and RenderTask. A RenderTask is the normal mode and it has a segment to write into. A ReplayTask doesn't have a segment to write into because that has already been written but instead it has a ReplayState which keeps track of the next set of paths to follow. Once we hit a "Resume" node we convert it into a RenderTask and continue rendering from there. We can resume at either an Element position or a Slot position. An Element pointing to a component doesn't mean we resume that component, it means we resume in the child position directly below that component. Slots are slots inside arrays. Instead of statically forking most paths, I kept using the same path and checked for the existence of a segment or replay state dynamically at runtime. However, there's still quite a bit of forking here like retryRenderTask and retryReplayTask. Even in the new forks there's a lot of duplication like resumeSuspenseBoundary, replaySuspenseBoundary and renderSuspenseBoundary. There's opportunity to simplify this a bit.
2023-09-15 15:24:04 -04:00
"486": "It should not be possible to postpone at the root. This is a bug in React.",
[Fizz] Client render the nearest child or parent suspense boundary if replay errors or is aborted (#27386) Based on #27385. When we error or abort during replay, that doesn't actually error the component that errored because that has already rendered. The error only affects any child that is not yet completed. Therefore the error kind of gets thrown at the resumable point. The resumable point might be a hole in the replay path, in which case throwing there errors the parent boundary just the same as if the replay component errored. If the hole is inside a deeper Suspense boundary though, then it's that Suspense boundary that gets client rendered. I.e. the child boundary. We can still finish any siblings. In the shell all resumable points are inside a boundary since we must have finished the shell. Therefore if you error in the root, we just simply just turn all incomplete boundaries into client renders.
2023-09-18 11:25:56 -04:00
"487": "We should not have any resumable nodes in the shell. This is a bug in React.",
[Fizz] Replay Postponed Paths (#27379) This forks Task into ReplayTask and RenderTask. A RenderTask is the normal mode and it has a segment to write into. A ReplayTask doesn't have a segment to write into because that has already been written but instead it has a ReplayState which keeps track of the next set of paths to follow. Once we hit a "Resume" node we convert it into a RenderTask and continue rendering from there. We can resume at either an Element position or a Slot position. An Element pointing to a component doesn't mean we resume that component, it means we resume in the child position directly below that component. Slots are slots inside arrays. Instead of statically forking most paths, I kept using the same path and checked for the existence of a segment or replay state dynamically at runtime. However, there's still quite a bit of forking here like retryRenderTask and retryReplayTask. Even in the new forks there's a lot of duplication like resumeSuspenseBoundary, replaySuspenseBoundary and renderSuspenseBoundary. There's opportunity to simplify this a bit.
2023-09-15 15:24:04 -04:00
"488": "Couldn't find all resumable slots by key/index during replaying. The tree doesn't match so React will fallback to client rendering.",
[Fizz] Reset error component stack and fix error messages (#27456) The way we collect component stacks right now are pretty fragile. We expect that we'll call captureBoundaryErrorDetailsDev whenever an error happens. That resets lastBoundaryErrorComponentStackDev to null but if we don't, it just lingers and we don't set it to anything new then which leaks the previous component stack into the next time we have an error. So we need to reset it in a bunch of places. This is still broken with erroredReplay because it has the inverse problem that abortRemainingReplayNodes can call captureBoundaryErrorDetailsDev more than one time. So the second boundary won't get a stack. We probably should try to figure out an alternative way to carry along the stack. Perhaps WeakMap keyed by the error object. This also fixes an issue where we weren't invoking the onShellReady event if we error a replay. That event is a bit weird for resuming because we're probably really supposed to just invoke it immediately if we have already flushed the shell in the prerender which is always atm. Right now, it gets invoked later than necessary because you could have a resumed hole ready before a sibling in the shell is ready and that's blocked.
2023-10-04 16:48:12 -04:00
"489": "Expected the resume to render <%s> in this slot but instead it rendered <%s>. The tree doesn't match so React will fallback to client rendering.",
"490": "Expected the resume to render <%s> in this slot but instead it rendered <%s>. The tree doesn't match so React will fallback to client rendering.",
Enforce that the "react-server" build of "react" is used (#27436) I do this by simply renaming the secret export name in the "subset" bundle and this renamed version is what the FlightServer uses. This requires us to be more diligent about always using the correct instance of "react" in our tests so there's a bunch of clean up for that.
2023-09-29 18:24:05 -04:00
"491": "It should not be possible to postpone both at the root of an element as well as a slot below. This is a bug in React.",
[Flight] Taint APIs (#27445) This lets a registered object or value be "tainted", which we block from crossing the serialization boundary. It's only allowed to stay in-memory. This is an extra layer of protection against mistakes of transferring data from a data access layer to a client. It doesn't provide perfect protection, because it doesn't trace through derived values and substrings. So it shouldn't be used as the only security layer but more layers are better. `taintObjectReference` is for specific object instances, not any nested objects or values inside that object. It's useful to avoid specific objects from getting passed as is. It ensures that you don't accidentally leak values in a specific context. It can be for security reasons like tokens, privacy reasons like personal data or performance reasons like avoiding passing large objects over the wire. It might be privacy violation to leak the age of a specific user, but the number itself isn't blocked in any other context. As soon as the value is extracted and passed specifically without the object, it can therefore leak. `taintUniqueValue` is useful for high entropy values such as hashes, tokens or crypto keys that are very unique values. In that case it can be useful to taint the actual primitive values themselves. These can be encoded as a string, bigint or typed array. We don't currently check for this value in a substring or inside other typed arrays. Since values can be created from different sources they don't just follow garbage collection. In this case an additional object must be provided that defines the life time of this value for how long it should be blocked. It can be `globalThis` for essentially forever, but that risks leaking memory for ever when you're dealing with dynamic values like reading a token from a database. So in that case the idea is that you pass the object that might end up in cache. A request is the only thing that is expected to do any work. The principle is that you can derive values from out of a tainted entry during a request. Including stashing it in a per request cache. What you can't do is store a derived value in a global module level cache. At least not without also tainting the object.
2023-10-02 13:55:39 -04:00
"492": "The \"react\" package in this environment is not configured correctly. The \"react-server\" condition must be enabled in any environment that runs React Server Components.",
"493": "To taint a value, a lifetime must be defined by passing an object that holds the value.",
"494": "taintUniqueValue cannot taint objects or functions. Try taintObjectReference instead.",
"495": "Cannot taint a %s because the value is too general and not unique enough to block globally.",
"496": "Only objects or functions can be passed to taintObjectReference. Try taintUniqueValue instead.",
[Flight] Enforce "simple object" rule in production (#27502) We only allow plain objects that can be faithfully serialized and deserialized through JSON to pass through the serialization boundary. It's a bit too expensive to do all the possible checks in production so we do most checks in DEV, so it's still possible to pass an object in production by mistake. This is currently exaggerated by frameworks because the logs on the server aren't visible enough. Even so, it's possible to do a mistake without testing it in DEV or just testing a conditional branch. That might have security implications if that object wasn't supposed to be passed. We can't rely on only checking if the prototype is `Object.prototype` because that wouldn't work with cross-realm objects which is unfortunate. However, if it isn't, we can check wether it has exactly one prototype on the chain which would catch the common error of passing a class instance.
2023-10-11 12:18:49 -04:00
"497": "Only objects or functions can be passed to taintObjectReference.",
[Flight] Add context for non null prototype error (#30293) We already added this for other thrown errors, not just console.errors. There's a production form of this. We just missed adding this context. Mainly the best context is the line number though which comes from owner stacks.
2024-07-08 22:51:59 -04:00
"498": "Only plain objects, and a few built-ins, can be passed to Client Components from Server Components. Classes or null prototypes are not supported.%s",
s/server action/server function (#31005) ## Overview Changes the error message to say "Server Functions" instead of "Server Actions" since this error can fire in cases like: ``` <button onClick={serverFunction} /> ``` Which is calling a server function, not a server action.
2024-12-02 10:02:31 -05:00
"499": "Only plain objects, and a few built-ins, can be passed to Server Functions. Classes or null prototypes are not supported.%s",
[Fizz] Support aborting with Postpone (#28183) Semantically if you make your reason for aborting a Postpone instance the render should not hit the error pathways but should instead follow the postpone pathways. It's awkward today to actually get your hands on a Postpone instance because you have to catch the throw from postpone and then pass that into `abort()` or `AbortController.abort()` (depending on the renderer API you are using) This change makes it so that in most circumstances if you abort with a postpone the `onPostpone` handler will be called and the Suspense boundaries still pending will be put into client render mode with the appropriate postpone digest to avoid trigger recoverable error pathways on the client. Similar to postponing in the shell during a resume or render however if you abort before the shell is complete in a resume or render we will fatally error. The fatal error is contextualized by React to avoid passing the postpone object itself to the `onError` and related options.
2024-02-01 07:14:08 -08:00
"500": "React expected a headers state to exist when emitEarlyPreloads was called but did not find it. This suggests emitEarlyPreloads was called more than once per request. This is a bug in React.",
[Flight] Delete Server Context (#28225) Server Context was never documented, and has been deprecated in https://github.com/facebook/react/pull/27424. This PR removes it completely, including the implementation code. Notably, `useContext` is removed from the shared subset, so importing it from a React Server environment would now should be a build error in environments that are able to enforce that.
2024-02-05 22:39:15 +00:00
"501": "The render was aborted with postpone when the shell is incomplete. Reason: %s",
"502": "Cannot read a Client Context from a Server Component.",
[Flight] Emit debug info for a Server Component (#28272) 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.
2024-02-08 08:01:32 -08:00
"503": "Cannot use() an already resolved Client Reference.",
Throw a better error when Lazy/Promise is used in React.Children (#28280) We could in theory actually support this case by throwing a Promise when it's used inside a render. Allowing it to be synchronously unwrapped. However, it's a bit sketchy because we officially only support this in the render's child position or in `use()`. Another alternative could be to actually pass the Promise/Lazy to the callback so that you can reason about it and just return it again or even unwrapping with `use()` - at least for the forEach case maybe.
2024-02-08 14:10:19 -08:00
"504": "Failed to read a RSC payload created by a development version of React on the server while using a production version on the client. Always use matching versions on the server and the client.",
[Flight] Better error message if you pass a function as a child to a client component (#28367) Similar to #28362 but if you pass it to a client component.
2024-02-19 12:36:16 -05:00
"505": "Cannot render an Async Component, Promise or React.Lazy inside React.Children. We recommend not iterating over children and just rendering them plain.",
Remove method name prefix from warnings and errors (#28432) This pattern is a petpeeve of mine. I don't consider this best practice and so most don't have these prefixes. Very inconsistent. At best this is useless and noisey that you have to parse because the information is also in the stack trace. At worse these are misleading because they're highlighting something internal (like validateDOMNesting) which even suggests an internal bug. Even the ones public to React aren't necessarily what you called because you might be calling a wrapper around it. That would be properly reflected in a stack trace - which can also properly ignore list so that the first stack you see is your callsite, Which might be like `render()` in react-testing-library rather than `createRoot()` for example.
2024-02-23 15:16:54 -05:00
"506": "Functions are not valid as a child of Client Components. This may happen if you return %s instead of <%s /> from render. Or maybe you meant to call this function rather than return it.%s",
"507": "Expected the last optional `callback` argument to be a function. Instead received: %s.",
[DOM] disable legacy mode behind flag (#28468) Adds a flag to disable legacy mode. Currently this flag is used to cause legacy mode apis like render and hydrate to throw. This change also removes render, hydrate, unmountComponentAtNode, and unstable_renderSubtreeIntoContainer from the experiemntal entrypoint. Right now for Meta builds this flag is off (legacy mode is still supported). In OSS builds this flag matches __NEXT_MAJOR__ which means it currently is on in experiemental. This means that after merging legacy mode is effectively removed from experimental builds. While this is a breaking change, experimental builds are not stable and users can pin to older versions or update their use of react-dom to no longer use legacy mode APIs.
2024-03-04 08:19:17 -08:00
"508": "The first argument must be a React class instance. Instead received: %s.",
[Flight] Encode React Elements in Replies as Temporary References (#28564) Currently you can accidentally pass React Element to a Server Action. It warns but in prod it actually works because we can encode the symbol and otherwise it's mostly a plain object. It only works if you only pass host components and no function props etc. which makes it potentially error later. The first thing this does it just early hard error for elements. I made Lazy work by unwrapping though since that will be replaced by Promises later which works. Our protocol is not fully symmetric in that elements flow from Server -> Client. Only the Server can resolve Components and only the client should really be able to receive host components. It's not intended that a Server can actually do something with them other than passing them to the client. In the case of a Reply, we expect the client to be stateful. It's waiting for a response. So anything we can't serialize we can still pass by reference to an in memory object. So I introduce the concept of a TemporaryReferenceSet which is an opaque object that you create before encoding the reply. This then stashes any unserializable values in this set and encode the slot by id. When a new response from the Action then returns we pass the same temporary set into the parser which can then restore the objects. This lets you pass a value by reference to the server and back into another slot. For example it can be used to render children inside a parent tree from a server action: ``` export async function Component({ children }) { "use server"; return <div>{children}</div>; } ``` (You wouldn't normally do this due to the waterfalls but for advanced cases.) A common scenario where this comes up accidentally today is in `useActionState`. ``` export function action(state, formData) { "use server"; if (errored) { return <div>This action <strong>errored</strong></div>; } return null; } ``` ``` const [errors, formAction] = useActionState(action); return <div>{errors}<div>; ``` It feels like I'm just passing the JSX from server to client. However, because `useActionState` also sends the previous state *back* to the server this should not actually be valid. Before this PR this actually worked accidentally. You get a DEV warning but it used to work in prod. Once you do something like pass a client reference it won't work tho. We could perhaps make client references work by stashing where we got them from but it wouldn't work with all possible JSX. By adding temporary references to the action implementation this will work again - on the client. It'll also be more efficient since we don't send back the JSX content that you shouldn't introspect on the server anyway. However, a flaw here is that the progressive enhancement of this case won't work because we can't use temporary references for progressive enhancement since there's no in memory stash. What is worse is that it won't error if you hydrate. ~It also will error late in the example above because the first state is "undefined" so invoking the form once works - it errors on the second attempt when it tries to send the error state back again.~ It actually errors on the first invocation because we need to eagerly serialize "previous state" into the form. So at least that's better. I think maybe the solution to this particular pattern would be to allow JSX to serialize if you have no temporary reference set, and remember client references so that client references can be returned back to the server as client references. That way anything you could send from the server could also be returned to the server. But it would only deopt to serializing it for progressive enhancement. The consequence of that would be that there's a lot of JSX that might accidentally seem like it should work but it's only if you've gotten it from the server before that it works. This would have to have pair them somehow though since you can't take a client reference from one implementation of Flight and use it with another.
2024-03-19 16:59:52 -04:00
"509": "ReactDOM: Unsupported Legacy Mode API.",
"510": "React Element cannot be passed to Server Functions from the Client without a temporary reference set. Pass a TemporaryReferenceSet to the options.%s",
"511": "Missing a temporary reference set but the RSC response returned a temporary reference. Pass a temporaryReference option with the set that was used with the reply.",
"512": "The RSC response contained a reference that doesn't exist in the temporary reference set. Always pass the matching set that was used to create the reply when parsing its response.",
"513": "Cannot render a Client Context Provider on the Server. Instead, you can export a Client Component wrapper that itself renders a Client Context Provider.",
"514": "Cannot access %s on the server. You cannot dot into a temporary client reference from a server component. You can only pass the value through to the client.",
"515": "Cannot assign to a temporary client reference from a server module.",
[Flight Reply] Don't allow Symbols to be passed to a reply (#28610) As mentioned in #28609 there's a potential security risk if you allow a passed value to the server to spoof Elements because it allows a hacker to POST cross origin. This is only an issue if your framework allows this which it shouldn't but it seems like we should provide an extra layer of security here. ```js function action(errors, payload) { try { ... } catch (x) { return [newError].concat(errors); } } ``` ```js const [errors, formAction] = useActionState(action); return <div>{errors}</div>; ``` This would allow you to construct a payload where the previous "errors" set includes something like `<script src="danger.js" />`. We could block only elements from being received but it could potentially be a risk with creating other React types like Context too. We use symbols as a way to securely brand these. Most JS don't use this kind of branding with symbols like we do. They're generally properties which we don't support anyway. However in theory someone else could be using them like we do. So in an abundance of carefulness I just ban all symbols from being passed (except by temporary reference) - not just ours. This means that the format isn't fully symmetric even beyond just React Nodes. #28611 allows code that includes symbols/elements to continue working but may have to bail out to replaying instead of no JS sometimes. However, you still can't access the symbols inside the server - they're by reference only.
2024-03-21 16:53:02 -04:00
"516": "Attempted to call a temporary Client Reference from the server but it is on the client. It's not possible to invoke a client function from the server, it can only be rendered as a Component or passed to props of a Client Component.",
Move Hydration Mismatch Errors to Throw or Log Once (Kind of) (#28502) Stacked on #28476. We used to `console.error` for every mismatch we found, up until the error we threw for the hydration mismatch. This changes it so that we build up a set of diffs up until we either throw or complete hydrating the root/suspense boundary. If we throw, we append the diff to the error message which gets passed to onRecoverableError (which by default is also logged to console). If we complete, we append it to a `console.error`. Since we early abort when something throws, it effectively means that we can only collect multiple diffs if there were preceding non-throwing mismatches - i.e. only properties mismatched but tag name matched. There can still be multiple logs if multiple siblings Suspense boundaries all error hydrating but then they're separate errors entirely. We still log an extra line about something erroring but I think the goal should be that it leads to a single recoverable or console.error. This doesn't yet actually print the diff as part of this message. That's in a follow up PR.
2024-03-26 17:01:41 -07:00
"517": "Symbols cannot be passed to a Server Function without a temporary reference set. Pass a TemporaryReferenceSet to the options.%s",
Use a Wrapper Error for onRecoverableError with a "cause" Field for the real Error (#28736) We basically have four kinds of recoverable errors: - Hydration mismatches. - Server errored but client didn't. - Hydration render errored but client render didn't (in Root or Suspense boundary). - Concurrent render errored but synchronous render didn't. For the first three we log an additional error that the root or Suspense boundary didn't error. This provides some context about what happened. However, the problem is that for hydration mismatches that's unnecessary extra context that is confusing. We also don't log any additional context for concurrent render errors that could recover. This used to be the only recoverable error so it didn't need extra context but now we need to distinguish them. When we log these to `reportError` it's confusing to just see the error because you didn't see anything error on the page. It's also hard to group them together as one. In this PR, I remove the unnecessary context for hydration mismatches. For hydration and concurrent errors, I now wrap them in an error that describes that what happened but then use the new `cause` field to link the original error so we can keep that as the cause. The error that happened was that hydration client rendered or you deopted to sync render, the cause of that error is some other error. For server errors, we control the Error object so I already had added some context to that error object's message. Since we hide the message in prod, it's nice not to have the raw message in DEV neither. We could potentially split these into two errors for parity though.
2024-04-03 21:53:07 -04:00
"518": "Saw multiple hydration diff roots in a pass. This is a bug in React.",
"519": "Hydration Mismatch Exception: This is not a real error, and should not leak into userspace. If you're seeing this, it's likely a bug in React.",
[DOM] move `flushSync` out of the reconciler (#28500) This PR moves `flushSync` out of the reconciler. there is still an internal implementation that is used when these semantics are needed for React methods such as `unmount` on roots. This new isomorphic `flushSync` is only used in builds that no longer support legacy mode. Additionally all the internal uses of flushSync in the reconciler have been replaced with more direct methods. There is a new `updateContainerSync` method which updates a container but forces it to the Sync lane and flushes passive effects if necessary. This combined with flushSyncWork can be used to replace flushSync for all instances of internal usage. We still maintain the original flushSync implementation as `flushSyncFromReconciler` because it will be used as the flushSync implementation for FB builds. This is because it has special legacy mode handling that the new isomorphic implementation does not need to consider. It will be removed from production OSS builds by closure though
2024-04-08 09:03:20 -07:00
"520": "There was an error during concurrent rendering but React was able to recover by instead synchronously rendering the entire root.",
Scaffolding for requestFormReset API (#28808) Based on: - #28804 --- This sets adds a new ReactDOM export called requestFormReset, including setting up the export and creating a method on the internal ReactDOM dispatcher. It does not yet add any implementation. Doing this in its own commit for review purposes. The API itself will be explained in the next PR.
2024-04-10 16:55:15 -04:00
"521": "flushSyncWork should not be called from builds that support legacy mode. This is a bug in React.",
[Flight] Encode ReadableStream and AsyncIterables (#28847) This adds support in Flight for serializing four kinds of streams: - `ReadableStream` with objects as a model. This is a single shot iterator so you can read it only once. It can contain any value including Server Components. Chunks are encoded as is so if you send in 10 typed arrays, you get the same typed arrays out on the other side. - Binary `ReadableStream` with `type: 'bytes'` option. This supports the BYOB protocol. In this mode, the receiving side just gets `Uint8Array`s and they can be split across any single byte boundary into arbitrary chunks. - `AsyncIterable` where the `AsyncIterator` function is different than the `AsyncIterable` itself. In this case we assume that this might be a multi-shot iterable and so we buffer its value and you can iterate it multiple times on the other side. We support the `return` value as a value in the single completion slot, but you can't pass values in `next()`. If you want single-shot, return the AsyncIterator instead. - `AsyncIterator`. These gets serialized as a single-shot as it's just an iterator. `AsyncIterable`/`AsyncIterator` yield Promises that are instrumented with our `.status`/`.value` convention so that they can be synchronously looped over if available. They are also lazily parsed upon read. We can't do this with `ReadableStream` because we use the native implementation of `ReadableStream` which owns the promises. The format is a leading row that indicates which type of stream it is. Then a new row with the same ID is emitted for every chunk. Followed by either an error or close row. `AsyncIterable`s can also be returned as children of Server Components and then they're conceptually the same as fragment arrays/iterables. They can't actually be used as children in Fizz/Fiber but there's a separate plan for that. Only `AsyncIterable` not `AsyncIterator` will be valid as children - just like sync `Iterable` is already supported but single-shot `Iterator` is not. Notably, neither of these streams represent updates over time to a value. They represent multiple values in a list. When the server stream is aborted we also close the underlying stream. However, closing a stream on the client, doesn't close the underlying stream. A couple of possible follow ups I'm not planning on doing right now: - [ ] Free memory by releasing the buffer if an Iterator has been exhausted. Single shots could be optimized further to release individual items as you go. - [ ] We could clean up the underlying stream if the only pending data that's still flowing is from streams and all the streams have cleaned up. It's not very reliable though. It's better to do cancellation for the whole stream - e.g. at the framework level. - [ ] Implement smarter Binary Stream chunk handling. Currently we wait until we've received a whole row for binary chunks and copy them into consecutive memory. We need this to preserve semantics when passing typed arrays. However, for binary streams we don't need that. We can just send whatever pieces we have so far.
2024-04-16 12:20:07 -04:00
"522": "Invalid form element. requestFormReset must be passed a form that was rendered by React.",
"523": "The render was aborted due to being postponed.",
Rename the react.element symbol to react.transitional.element (#28813) We have changed the shape (and the runtime) of React Elements. To help avoid precompiled or inlined JSX having subtle breakages or deopting hidden classes, I renamed the symbol so that we can early error if private implementation details are used or mismatching versions are used. Why "transitional"? Well, because this is not the last time we'll change the shape. This is just a stepping stone to removing the `ref` field on the elements in the next version so we'll likely have to do it again.
2024-04-22 12:39:56 -04:00
"524": "Values cannot be passed to next() of AsyncIterables passed to Client Components.",
[Flight Reply] Encode Objects Returned to the Client by Reference (#29010) Stacked on #28997. We can use the technique of referencing an object by its row + property name path for temporary references - like we do for deduping. That way we don't need to generate an ID for temporary references. Instead, they can just be an opaque marker in the slot and it has the implicit ID of the row + path. Then we can stash all objects, even the ones that are actually available to read on the server, as temporary references. Without adding anything to the payload since the IDs are implicit. If the same object is returned to the client, it can be referenced by reference instead of serializing it back to the client. This also helps preserve object identity. We assume that the objects are immutable when they pass the boundary. I'm not sure if this is worth it but with this mechanism, if you return the `FormData` payload from a `useActionState` it doesn't have to be serialized on the way back to the client. This is a common pattern for having access to the last submission as "default value" to the form fields. However you can still control it by replacing it with another object if you want. In MPA mode, the temporary references are not configured and so it needs to be serialized in that case. That's required anyway for hydration purposes. I'm not sure if people will actually use this in practice though or if FormData will always be destructured into some other object like with a library that turns it into typed data, and back. If so, the object identity is lost.
2024-05-09 20:00:56 -04:00
"525": "A React Element from an older version of React was rendered. This is not supported. It can happen if:\n- Multiple copies of the \"react\" package is used.\n- A library pre-bundled an old copy of \"react\" or \"react/jsx-runtime\".\n- A compiler tries to \"inline\" JSX instead of using the runtime.",
Throw if React and React DOM versions don't match (#29236) Throw an error during module initialization if the version of the "react-dom" package does not match the version of "react". We used to be more relaxed about this, because the "react" package changed so infrequently. However, we now have many more features that rely on an internal protocol between the two packages, including Hooks, Float, and the compiler runtime. So it's important that both packages are versioned in lockstep. Before this change, a version mismatch would often result in a cryptic internal error with no indication of the root cause. Instead, we will now compare the versions during module initialization and immediately throw an error to catch mistakes as early as possible and provide a clear error message.
2024-05-28 14:06:30 -04:00
"526": "Could not reference an opaque temporary reference. This is likely due to misconfiguring the temporaryReferences options on the server.",
[Fiber][Float] Error when a host fiber changes "flavor" (#29693) 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
2024-06-03 07:47:45 -07:00
"527": "Incompatible React versions: The \"react\" and \"react-dom\" packages must have the exact same version. Instead got:\n - react: %s\n - react-dom: %s\nLearn more: https://react.dev/warnings/version-mismatch",
Fix stylesheet typo in 29693 (#29732) stylehsheet -> stylesheet
2024-06-03 07:51:21 -07:00
"528": "Expected <link> not to update to be updated to a stylesheet with precedence. Check the `rel`, `href`, and `precedence` props of this component. Alternatively, check whether two different <link> components render in the same slot or share the same key.%s",
[Flight] Allow aborting during render (#29764) Stacked on #29491 Previously if you aborted during a render the currently rendering task would itself be aborted which will cause the entire model to be replaced by the aborted error rather than just the slot currently being rendered. This change updates the abort logic to mark currently rendering tasks as aborted but allowing the current render to emit a partially serialized model with an error reference in place of the current model. The intent is to support aborting from rendering synchronously, in microtasks (after an await or in a .then) and in lazy initializers. We don't specifically support aborting from things like proxies that might be triggered during serialization of props
2024-06-06 14:41:27 -07:00
"529": "Expected stylesheet with precedence to not be updated to a different kind of <link>. Check the `rel`, `href`, and `precedence` props of this component. Alternatively, check whether two different <link> components render in the same slot or share the same key.%s",
Add new package with renderToMarkup export (#30105) Name of the package is tbd (straw: `react-html`). It's a new package separate from `react-dom` though and can be used as a standalone package - e.g. also from a React Native app. ```js import {renderToMarkup} from '...'; const html = await renderToMarkup(<Component />); ``` The idea is that this is a helper for rendering HTML that is not intended to be hydrated. It's primarily intended to support a subset of HTML that can be used as embedding and not served as HTML documents from HTTP. For example as e-mails or in RSS/Atom feeds or other distributions. It's a successor to `renderToStaticMarkup`. A few differences: - This doesn't support "Client Components". It can only use the Server Components subset. No useEffect, no useState etc. since it will never be hydrated. Use of those are errors. - You also can't pass Client References so you can't use components marked with `"use client"`. - Unlike `renderToStaticMarkup` this does support async so you can suspend and use data from these components. - Unlike `renderToReadableStream` this does not support streaming or Suspense boundaries and any error rejects the promise. Since there's no feasible way to "client render" or patch up the document. - Form Actions are not supported since in an embedded environment there's no place to post back to across versions. You can render plain forms with fixed URLs though. - You can't use any resource preloading like `preload()` from `react-dom`. ## Implementation This first version in this PR only supports Server Components since that's the thing that doesn't have an existing API. Might add a Client Components version later that errors. We don't want to maintain a completely separate implementation for this use case so this uses the `dom-legacy` build dimension to wire up a build that encapsulates a Flight Server -> Flight Client -> Fizz stream to render Server Components that then get SSR:ed. There's no problem to use a Flight Client in a Server Component environment since it's already supported for Server-to-Server. Both of these use a bundler config that just errors for Client References though since we don't need any bundling integration and this is just a standalone package. Running Fizz in a Server Component environment is a problem though because it depends on "react" and it needs the client version. Therefore, for this build we embed the client version of "react" shared internals into the build. It doesn't need anything to be able to use those APIs since you can't call the client APIs anyway. One unfortunate thing though is that since Flight currently needs to go to binary and back, we need TextEncoder/TextDecoder to be available but this shouldn't really be necessary. Also since we use the legacy stream config, large strings that use byteLengthOfChunk errors atm. This needs to be fixed before shipping. I'm not sure what would be the best layering though that isn't unnecessarily burdensome to maintain. Maybe some kind of pass-through protocol that would also be useful in general - e.g. when Fizz and Flight are in the same process. --------- Co-authored-by: Sebastian Silbermann <silbermann.sebastian@gmail.com>
2024-06-27 18:09:40 +02:00
"530": "The render was aborted by the server with a promise.",
Move `react-html` to `react-markup` (#30688)
2024-08-14 19:22:44 +02:00
"531": "react-markup is not supported outside a React Server Components environment.",
Rename `renderToMarkup` to `renderToHTML` (#30689)
2024-08-14 19:35:16 +02:00
"532": "Attempted to render a Client Component from renderToHTML. This is not supported since it will never hydrate. Only render Server Components with renderToHTML.",
"533": "Attempted to render a Server Action from renderToHTML. This is not supported since it varies by version of the app. Use a fixed URL for any forms instead.",
"534": "renderToHTML should not have emitted Client References. This is a bug in React.",
"535": "renderToHTML should not have emitted Server References. This is a bug in React.",
"536": "Cannot pass ref in renderToHTML because they will never be hydrated.",
"537": "Cannot pass event handlers (%s) in renderToHTML because the HTML will never be hydrated so they can never get called.",
"538": "Cannot use state or effect Hooks in renderToHTML because this component will never be hydrated.",
[Flight] Allow String Chunks to Passthrough in Node streams and renderToMarkup (#30131) It can be efficient to accept raw string chunks to pass through a stream instead of encoding them into a binary copy first. Previously our Flight parsers didn't accept receiving string chunks. That's partly because we sometimes need to encode binary chunks anyway so string only transport isn't enough but some chunks can be strings. This adds a partial ability for chunks to be received as strings. However, accepting strings comes with some downsides. E.g. if the strings are split up we need to buffer it which compromises the perf for the common case. If the chunk represents binary data, then we'd need to encode it back into a typed array which would require a TextEncoder dependency in the parser. If the string chunk represents a byte length encoded string we don't know how many unicode characters to read without measuring them in terms of binary - also requiring a TextEncoder. This PR is mainly intended for use for pass-through within the same memory. We can simplify the implementation by assuming that any string chunk is passed as the original chunk. This requires that the server stream config doesn't arbitrarily concatenate strings (e.g. large strings should not be concatenated which is probably a good heuristic anyway). It also means that this is not suitable to be used with for example receiving string chunks on the client by passing them through SSR hydration data - except if the encoding that way was only used with chunks that were already encoded as strings by Flight. Web streams mostly just work on binary data anyway so they can't use this. In Node.js streams we concatenate precomputed and small strings into larger buffers. It might make sense to do that using string ropes instead. However, in the meantime we can at least pass large strings that are outside our buffer view size as raw strings. There's no benefit to us eagerly encoding those. Also, let Node accept string chunks as long as they're following our expected constraints. This lets us test the mixed protocol using pass-throughs. This can also be useful when the RSC server is in the same environment as the SSR server as they don't have to go from strings to typed arrays back to strings. Now we can also use this in the pass-through used in renderToMarkup. This lets us avoid the dependency on TextDecoder/TextEncoder in that package.
2024-07-03 13:25:04 -04:00
"539": "Binary RSC chunks cannot be encoded as strings. This is a bug in the wiring of the React streams.",
Add unstable context bailout for profiling (#30407) **This API is not intended to ship. This is a temporary unstable hook for internal performance profiling.** This PR exposes `unstable_useContextWithBailout`, which takes a compare function in addition to Context. The comparison function is run to determine if Context propagation and render should bail out earlier. `unstable_useContextWithBailout` returns the full Context value, same as `useContext`. We can profile this API against `useContext` to better measure the cost of Context value updates and gather more data around propagation and render performance. The bailout logic and test cases are based on https://github.com/facebook/react/pull/20646 Additionally, this implementation allows multiple values to be compared in one hook by returning a tuple to avoid requiring additional Context consumer hooks.
2024-07-26 14:38:24 -04:00
"540": "String chunks need to be passed in their original shape. Not split into smaller string chunks. This is a bug in the wiring of the React streams.",
Track separate SuspendedOnAction flag by rethrowing a separate SuspenseActionException sentinel (#31554) This lets us track separately if something was suspended on an Action using useActionState rather than suspended on Data. This approach feels quite bloated and it seems like we'd eventually might want to read more information about the Promise that suspended and the context it suspended in. As a more general reason for suspending. The way useActionState works in combination with the prewarming is quite unfortunate because 1) it renders blocking to update the isPending flag whether you use it or not 2) it prewarms and suspends the useActionState 3) then it does another third render to get back into the useActionState position again.
2024-11-15 17:52:24 -05:00
"541": "Compared context values must be arrays",
[crud] Fix deps comparison bug (#31599) Fixes a bug with the experimental `useResourceEffect` hook where we would compare the wrong deps when there happened to be another kind of effect preceding the ResourceEffect. To do this correctly we need to add a pointer to the ResourceEffect's identity on the update. I also unified the previously separate push effect impls for resource effects since they are always pushed together as a unit.
2024-11-20 16:54:41 -05:00
"542": "Suspense Exception: This is not a real error! It's an implementation detail of `useActionState` to interrupt the current render. You must either rethrow it immediately, or move the `useActionState` call outside of the `try/catch` block. Capturing without rethrowing will lead to unexpected behavior.\n\nTo handle async errors, wrap your component in an error boundary.",
Add <ViewTransition> Component (#31975) This will provide the opt-in for using [View Transitions](https://developer.mozilla.org/en-US/docs/Web/API/View_Transition_API) in React. View Transitions only trigger for async updates like `startTransition`, `useDeferredValue`, Actions or `<Suspense>` revealing from fallback to content. Synchronous updates provide an opt-out but also guarantee that they commit immediately which View Transitions can't. There's no need to opt-in to View Transitions at the "cause" side like event handlers or actions. They don't know what UI will change and whether that has an animated transition described. Conceptually the `<ViewTransition>` component is like a DOM fragment that transitions its children in its own isolate/snapshot. The API works by wrapping a DOM node or inner component: ```js import {ViewTransition} from 'react'; <ViewTransition><Component /></ViewTransition> ``` The default is `name="auto"` which will automatically assign a `view-transition-name` to the inner DOM node. That way you can add a View Transition to a Component without controlling its DOM nodes styling otherwise. A difference between this and the browser's built-in `view-transition-name: auto` is that switching the DOM nodes within the `<ViewTransition>` component preserves the same name so this example cross-fades between the DOM nodes instead of causing an exit and enter: ```js <ViewTransition>{condition ? <ComponentA /> : <ComponentB />}</ViewTransition> ``` This becomes especially useful with `<Suspense>` as this example cross-fades between Skeleton and Content: ```js <ViewTransition> <Suspense fallback={<Skeleton />}> <Content /> </Suspense> </ViewTransition> ``` Where as this example triggers an exit of the Skeleton and an enter of the Content: ```js <Suspense fallback={<ViewTransition><Skeleton /></ViewTransition>}> <ViewTransition><Content /></ViewTransition> </Suspense> ``` Managing instances and keys becomes extra important. You can also specify an explicit `name` property for example for animating the same conceptual item from one page onto another. However, best practices is to property namespace these since they can easily collide. It's also useful to add an `id` to it if available. ```js <ViewTransition name="my-shared-view"> ``` The model in general is the same as plain `view-transition-name` except React manages a set of heuristics for when to apply it. A problem with the naive View Transitions model is that it overly opts in every boundary that *might* transition into transitioning. This is leads to unfortunate effects like things floating around when unrelated updates happen. This leads the whole document to animate which means that nothing is clickable in the meantime. It makes it not useful for smaller and more local transitions. Best practice is to add `view-transition-name` only right before you're about to need to animate the thing. This is tricky to manage globally on complex apps and is not compositional. Instead we let React manage when a `<ViewTransition>` "activates" and add/remove the `view-transition-name`. This is also when React calls `startViewTransition` behind the scenes while it mutates the DOM. I've come up with a number of heuristics that I think will make a lot easier to coordinate this. The principle is that only if something that updates that particular boundary do we activate it. I hope that one day maybe browsers will have something like these built-in and we can remove our implementation. A `<ViewTransition>` only activates if: - If a mounted Component renders a `<ViewTransition>` within it outside the first DOM node, and it is within the viewport, then that ViewTransition activates as an "enter" animation. This avoids inner "enter" animations trigger when the parent mounts. - If an unmounted Component had a `<ViewTransition>` within it outside the first DOM node, and it was within the viewport, then that ViewTransition activates as an "exit" animation. This avoids inner "exit" animations triggering when the parent unmounts. - If an explicitly named `<ViewTransition name="...">` is deep within an unmounted tree and one with the same name appears in a mounted tree at the same time, then both are activated as a pair, but only if they're both in the viewport. This avoids these triggering "enter" or "exit" animations when going between parents that don't have a pair. - If an already mounted `<ViewTransition>` is visible and a DOM mutation, that might affect how it's painted, happens within its children but outside any nested `<ViewTransition>`. This allows it to "cross-fade" between its updates. - If an already mounted `<ViewTransition>` resizes or moves as the result of direct DOM nodes siblings changing or moving around. This allows insertion, deletion and reorders into a list to animate all children. It is only within one DOM node though, to avoid unrelated changes in the parent to trigger this. If an item is outside the viewport before and after, then it's skipped to avoid things flying across the screen. - If a `<ViewTransition>` boundary changes size, due to a DOM mutation within it, then the parent activates (or the root document if there are no more parents). This ensures that the container can cross-fade to avoid abrupt relayout. This can be avoided by using absolutely positioned children. When this can avoid bubbling to the root document, whatever is not animating is still responsive to clicks during the transition. Conceptually each DOM node has its own default that activates the parent `<ViewTransition>` or no transition if the parent is the root. That means that if you add a DOM node like `<div><ViewTransition><Component /></ViewTransition></div>` this won't trigger an "enter" animation since it was the div that was added, not the ViewTransition. Instead, it might cause a cross-fade of the parent ViewTransition or no transition if it had no parent. This ensures that only explicit boundaries perform coarse animations instead of every single node which is really the benefit of the View Transitions model. This ends up working out well for simple cases like switching between two pages immediately while transitioning one floating item that appears on both pages. Because only the floating item transitions by default. Note that it's possible to add manual `view-transition-name` with CSS or `style={{ viewTransitionName: 'auto' }}` that always transitions as long as something else has a `<ViewTransition>` that activates. For example a `<ViewTransition>` can wrap a whole page for a cross-fade but inside of it an explicit name can be added to something to ensure it animates as a move when something relates else changes its layout. Instead of just cross-fading it along with the Page which would be the default. There's more PRs coming with some optimizations, fixes and expanded APIs. This first PR explores the above core heuristic. --------- Co-authored-by: Sebastian "Sebbie" Silbermann <silbermann.sebastian@gmail.com>
2025-01-08 12:11:18 -05:00
"543": "Expected a ResourceEffectUpdate to be pushed together with ResourceEffectIdentity. This is a bug in React.",
[Fizz] Support Suspense boundaries anywhere (#32069) Suspense is meant to be composable but there has been a lonstanding limitation with using Suspense above the `<body>` tag of an HTML document due to peculiarities of how HTML is parsed. For instance if you used Suspense to render an entire HTML document and had a fallback that might flush an alternate Document the comment nodes which describe this boundary scope won't be where they need to be in the DOM for client React to properly hydrate them. This is somewhat a problem of our own making in that we have a concept of a Preamble and we leave the closing body and html tags behind until streaming has completed which produces a valid HTML document that also matches the DOM structure that would be parsed from it. However Preambles as a concept are too important to features like Float to imagine moving away from this model and so we can either choose to just accept that you cannot use Suspense anywhere except inside the `<body>` or we can build special support for Suspense into react-dom that has a coherent semantic with how HTML documents are written and parsed. This change implements Suspense support for react-dom/server by correctly serializing boundaries during rendering, prerendering, and resumgin on the server. It does not yet support Suspense everywhere on the client but this will arrive in a subsequent change. In practice Suspense cannot be used above the `<body>` tag today so this is not a breaking change since no programs in the wild could be using this feature anyway. React's streaming rendering of HTML doesn't lend itself to replacing the contents of the documentElement, head, or body of a Document. These are already special cased in fiber as HostSingletons and similarly for Fizz the values we render for these tags must never be updated by the Fizz runtime once written. To accomplish these we redefine the Preamble as the tags that represent these three singletons plus the contents of the document.head. If you use Suspense above any part of the Preamble then nothing will be written to the destination until the boundary is no longer pending. If the boundary completes then the preamble from within that boudnary will be output. If the boundary postpones or errors then the preamble from the fallback will be used instead. Additionally, by default anything that is not part of the preamble is implicitly in body scope. This leads to the somewhat counterintuitive consequence that the comment nodes we use to mark the borders of a Suspense boundary in Fizz can appear INSIDE the preamble that was rendered within it. ```typescript render(( <Suspense> <html lang="en"> <body> <div>hello world</div> </body> </html> </Suspense> )) ``` will produce an HTML document like this ```html <!DOCTYPE html> <html lang="en"> <head></head> <body> <!--$--> <-- this is the comment Node representing the outermost Suspense <div>hello world</div> <$--/$--> </body> </html> ``` Later when I update Fiber to support Suspense anywhere hydration will similarly start implicitly in the document body when the root is part of the preamble (the document or one of it's singletons).
2025-01-17 10:54:11 -08:00
"544": "Found a pair with an auto name. This is a bug in React.",
[crud] Merge useResourceEffect into useEffect (#32205) Merges the useResourceEffect API into useEffect while keeping the underlying implementation the same. useResourceEffect will be removed in the next diff. To fork between behavior we rely on a `typeof` check for the updater or destroy function in addition to the CRUD feature flag. This does now have to be checked every time (instead of inlined statically like before due to them being different hooks) which will incur some non-zero amount (possibly negligble) of overhead for every effect. --- [//]: # (BEGIN SAPLING FOOTER) Stack created with [Sapling](https://sapling-scm.com). Best reviewed with [ReviewStack](https://reviewstack.dev/facebook/react/pull/32205). * #32206 * __->__ #32205
2025-02-11 14:18:50 -05:00
"545": "The %s tag may only be rendered once.",
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
"546": "useEffect CRUD overload is not enabled in this build of React.",
"547": "startGesture cannot be called during server rendering.",
Rerender useSwipeTransition when direction changes (#32379) 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.
2025-02-20 18:13:09 -05:00
"548": "Finished rendering the gesture lane but there were no pending gestures. React should not have started a render in this case. This is a bug in React.",
"549": "Cannot start a gesture with a disconnected AnimationTimeline.",
Remove useSwipeTransition (#32786) Stacked on #32785. This is now replaced by `startGestureTransition` added in #32785. I also renamed the flag from `enableSwipeTransition` to `enableGestureTransition` to correspond to the new name.
2025-04-01 11:43:33 -04:00
"550": "startGestureTransition is not yet supported in react-art.",
"551": "startGestureTransition is not yet supported in React Native.",
"552": "Cannot use a startGestureTransition() on a detached root.",
Add startGestureTransition API (#32785) Stacked on #32783. This will replace [the `useSwipeTransition` API](https://github.com/facebook/react/pull/32373). Instead, of a special Hook, you can make updates to `useOptimistic` Hooks within the `startGestureTransition` scope. ``` import {unstable_startGestureTransition as startGestureTransition} from 'react'; const cancel = startGestureTransition(timeline, () => { setOptimistic(...); }, options); ``` There are some downsides to this like you can't define two directions as once and there's no "standard" direction protocol. It's instead up to libraries to come up with their own conventions (although we can suggest some). The convention is still that a gesture recognizer has two props `action` and `gesture`. The `gesture` prop is a Gesture concept which now behaves more like an Action but 1) it can't be async 2) it shouldn't have side-effects. For example you can't call `setState()` in it except on `useOptimistic` since those can be reverted if needed. The `action` is invoked with whatever side-effects you want after the gesture fulfills. This is isomorphic and not associated with a specific renderer nor root so it's a bit more complicated. To implement this I unify with the `ReactSharedInternal.T` property to contain a regular Transition or a Gesture Transition (the `gesture` field). The benefit of this unification means that every time we override this based on some scope like entering `flushSync` we also override the `startGestureTransition` scope. We just have to be careful when we read it to check the `gesture` field to know which one it is. (E.g. I error for setState / requestFormReset.) The other thing that's unique is the `cancel` return value to know when to stop the gesture. That cancellation is no longer associated with any particular Hook. It's more associated with the scope of the `startGestureTransition`. Since the schedule of whether a particular gesture has rendered or committed is associated with a root, we need to somehow associate any scheduled gestures with a root. We could track which roots we update inside the scope but instead, I went with a model where I check all the roots and see if there's a scheduled gesture matching the timeline. This means that you could "retain" a gesture across roots. Meaning this wouldn't cancel until both are cancelled: ``` const cancelA = startGestureTransition(timeline, () => { setOptimisticOnRootA(...); }, options); const cancelB = startGestureTransition(timeline, () => { setOptimisticOnRootB(...); }, options); ``` It's more like it's a global transition than associated with the roots that were updated. Optimistic updates mostly just work but I now associate them with a specific "ScheduledGesture" instance since we can only render one at a time and so if it's not the current one, we leave it for later. Clean up of optimistic updates is now lazy rather than when we cancel. Allowing the cancel closure not to have to be associated with each particular update.
2025-03-31 20:05:50 -04:00
"553": "A Timeline is required as the first argument to startGestureTransition.",
"554": "Cannot setState on regular state inside a startGestureTransition. Gestures can only update the useOptimistic() hook. There should be no side-effects associated with starting a Gesture until its Action is invoked. Move side-effects to the Action instead.",
Implement Partial Hydration for Activity (#32863) Stacked on #32862 and #32842. This means that Activity boundaries now act as boundaries which can have their effects mounted independently. Just like Suspense boundaries, we hydrate the outer content first and then start hydrating the content in an Offscreen lane. Flowing props or interacting with the content increases the priority just like Suspense boundaries. This skips emitting even the comments for `<Activity mode="hidden">` so we don't hydrate those. Instead those are deferred to a later client render. The implementation are just forked copies of the SuspenseComponent branches and then carefully going through each line and tweaking it. The main interesting bit is that, unlike Suspense, Activity boundaries don't have fallbacks so all those branches where you might commit a suspended tree disappears. Instead, if something suspends while hydration, we can just leave the dehydrated content in place. However, if something does suspend during client rendering then it should bubble up to the parent. Therefore, we have to be careful to only pushSuspenseHandler when hydrating. That's really the main difference. This just uses the existing basic Activity tests but I've started work on port all of the applicable Suspense tests in SelectiveHydration-test and PartialHydration-test to Activity versions.
2025-04-22 21:00:30 -04:00
"555": "Cannot requestFormReset() inside a startGestureTransition. There should be no side-effects associated with starting a Gesture until its Action is invoked. Move side-effects to the Action instead.",
"556": "Expected prepareToHydrateHostActivityInstance() to never be called. This error is likely caused by a bug in React. Please file an issue.",
"557": "Expected to have a hydrated activity instance. This error is likely caused by a bug in React. Please file an issue.",
Add Fragment Refs to Fabric with intersection observer support (#33056) Adds Fragment Ref support to RN through the Fabric config, starting with `observeUsing`/`unobserveUsing`. This is mostly a copy from the implementation on DOM, and some of it can likely be shared in the future but keeping it separate for now and we can refactor as we add more features. Added a basic test with Fabric, but testing specific methods requires so much mocking that it doesn't seem valuable here. I built Fabric and ran on the Catalyst app internally to test with intersection observers end to end.
2025-04-30 10:47:18 -04:00
"558": "Client rendering an Activity suspended it again. This is a bug in React.",
Prevent errors from comment node roots with enableViewTransition (#33205) We have many cases internally where the `containerInstance` resolves to a comment node. `restoreRootViewTransitionName` is called when `enableViewTransition` is on, even without introducing a `<ViewTransition />`. So that means it can crash pages because `containerInstance.style` is `undefined` just by turning on the flag. This skips cancel/restore of root view transition name if a comment node is the root.
2025-05-21 13:57:35 -04:00
"559": "Expected to find a host node. This is a bug in React.",
"560": "Cannot use a startGestureTransition() with a comment node root."
Move `react-html` to `react-markup` (#30688)
2024-08-14 19:22:44 +02:00
}
Reference in New Issue Copy Permalink