You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We've all been annoyed when entering and for some reason losing form data. Basically the worst thing that can happen to a site is that a user loses its data at the last step of purchasing, subscribing, etc.
Unfortunately, this is the default behavior of use:enhance. If a server error occurs, it will jump straight to the nearest +error boundary, effectively removing the form and all data. This is not nice UX.
Describe the proposed solution
If the default behaviour is open to change, having it behave as described in the docs in the case of result.type being success or invalid would solve this issue straight away.
A status: number field could even be added to the error type of ActionResult, so you could detect specific errors returned from the server, not just 500. A 503 is useful to know if you should try again soon, for example. It's important for $page.status to be updated, so an error message could be displayed at the form based on the status, for a decent UX.
If the default behavior cannot change, or if it does but to keep the previous behavior optional, adding an option to update that won't render the error would be great:
<formmethod="POST"use:enhance={()=>{returnasync({ result, update })=>{// `result` is an `ActionResult` object// `update` is a function which triggers the logic that would be triggered if this callback wasn't setupdate({renderError: false})};}}>
Right now quite complicated logic is required to make a generic workaround, so this simple addition would be very helpful.
Alternatives considered
No response
Importance
would make my life easier
Additional Information
Let me know if it's a quick fix, or if I should make a PR for this.
The text was updated successfully, but these errors were encountered:
It's not totally clear to me what we'd gain with a renderError option — is there any drawback to just doing this?
<form
method="POST"
use:enhance={() => {
return async ({ result, update }) => {
// `result` is an `ActionResult` object
// `update` is a function which triggers the logic that would be triggered if this callback wasn't set
+ if (result.type === 'error') doSomething(result.error);+ else update()- update({renderError: false})
};
}}
>
Good point re missing status code, that feels like an oversight
The drawback is that I don't know exactly what happens behind the scenes of update, which is basically the problem. :) I had some problems when using update as per your suggestion, so I eventually made it work by doing this:
It's a bit more code than I'd like, and of course it was a bit of trial and error to figure the differences between applyAction and update, so having a future-proof update with an extra option instead would be much nicer.
Btw: A big thanks to you Rich and your team for all the hard work on SvelteKit, I'm working on a large project that will use it, and the overall feeling is fantastic. All the changes with routing, loading, etc, just clicks. You made the right choice there. :)
Describe the problem
We've all been annoyed when entering and for some reason losing form data. Basically the worst thing that can happen to a site is that a user loses its data at the last step of purchasing, subscribing, etc.
Unfortunately, this is the default behavior of
use:enhance
. If a server error occurs, it will jump straight to the nearest+error
boundary, effectively removing the form and all data. This is not nice UX.Describe the proposed solution
If the default behaviour is open to change, having it behave as described in the docs in the case of
result.type
beingsuccess
orinvalid
would solve this issue straight away.A
status: number
field could even be added to theerror
type ofActionResult
, so you could detect specific errors returned from the server, not just 500. A 503 is useful to know if you should try again soon, for example. It's important for$page.status
to be updated, so an error message could be displayed at the form based on the status, for a decent UX.If the default behavior cannot change, or if it does but to keep the previous behavior optional, adding an option to
update
that won't render the error would be great:Right now quite complicated logic is required to make a generic workaround, so this simple addition would be very helpful.
Alternatives considered
No response
Importance
would make my life easier
Additional Information
Let me know if it's a quick fix, or if I should make a PR for this.
The text was updated successfully, but these errors were encountered: