-
Notifications
You must be signed in to change notification settings - Fork 47.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rethrow errors from form actions #26689
Conversation
This sets up the initial writing for form actions. The idea is that form actions are implicitly wrapped with `startTransition`. This does not handle async actions yet, so error and pending states don't work. That will be added in later steps.
a775e83
to
128404f
Compare
Comparing: cc93a85...87a2258 Critical size changesIncludes critical production bundles, as well as any change greater than 2%:
Significant size changesIncludes any change greater than 0.2%: Expand to show
|
aeb3e94
to
34003e2
Compare
next: null, | ||
}; | ||
|
||
stateHook.queue = queue; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
good catch, it's superfluous
34003e2
to
ce6c12f
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The flag should probably check both enableAsyncActions and enableFormActions where it's relevant.
In terms of the naming on the react-reconciler side. Maybe this should be named something about the HostComponent being Transition aware rather than about Forms specifically.
startFormAction
-> startHostTransition
StatefulHostComponent
-> TransitionAwareHostComponent
Want to update the Flight fixture to use this instead of console.error for error handling?
if (!enableFormActions) { | ||
return false; | ||
} | ||
return renderWithHooks( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This overrides updateQueue
to null. That field is fine to reuse after diffInCommitPhase
and outside of legacy mode hydration I think.
But just setting it to null here is probably also fine, since it's only used to carry data from complete phase to commit phase.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder what the specialized form of this looks like for this use case when we can ignore all the user space stuff like multiple render passes, DEV warnings. We don't even have to set the ReactCurrentDispatcher.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah I explored during that in this diff but it started getting out of hand so I punted on that for now. Maybe once there's 2 cases.
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.
ce6c12f
to
87a2258
Compare
Errors in form actions are now rethrown during render (facebook#26689), so we can handle the using an error boundary.
Errors in form actions are now rethrown during render (facebook#26689), so we can handle the using an error boundary.
Errors in form actions are now rethrown during render (facebook#26689), so we can handle the using an error boundary.
Errors in form actions are now rethrown during render (#26689), so we can handle them using an error boundary.
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.
Errors in form actions are now rethrown during render (#26689), so we can handle them using an error boundary.
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.
Errors in form actions are now rethrown during render (facebook#26689), so we can handle them using an error boundary.
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. DiffTrain build for commit fd3fb8e.
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.