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
When throwing a FormError, we'd expect a non-200 status code to be used in the response and the status code of the HTTP to match it. For example:
constres=awaitaction.submit(data)res.status===200// <- should be 500
As additional topics to discuss, in this RFC QwikDev/qwik-evolution#205 we're planning on standardising Qwik errors. Part of this work is that server errors should also throw on the frontend so they can be caught rather than having the error response returned successfully in the response object. This is so that we don't need to handle transient errors differently from our thrown errors.
With the introduction of ServerError types in Qwik, we can set the status code for errors being thrown, it seems like this would make sense to work with ModuleForms as well otherwise we're unable to differentiate between error types correctly in code and in our monitoring.
So something like this might make sense for the FormError, which throws a ServerError in Qwik:
In Qwik we will use the ServerError going forward so that we can handle it in middleware correctly. So we should possibly have the FormError extend the ServerError, at least for Qwik apps.
The text was updated successfully, but these errors were encountered:
It also seems like a second issue is that after setting the response, Qwik refetches the loaders on the page and rerenders which updates the form state which resets the response. So the response is removed when the initial data is returned by a routeLoader
When throwing a FormError, we'd expect a non-200 status code to be used in the response and the status code of the HTTP to match it. For example:
As additional topics to discuss, in this RFC QwikDev/qwik-evolution#205 we're planning on standardising Qwik errors. Part of this work is that server errors should also throw on the frontend so they can be caught rather than having the error response returned successfully in the response object. This is so that we don't need to handle transient errors differently from our thrown errors.
With the introduction of ServerError types in Qwik, we can set the status code for errors being thrown, it seems like this would make sense to work with ModuleForms as well otherwise we're unable to differentiate between error types correctly in code and in our monitoring.
So something like this might make sense for the FormError, which throws a ServerError in Qwik:
There is also some confusion, at least from me, with using the Qwik error
throw event.fail(500, {...})
And then a more useful client side error handling would be this:
In Qwik we will use the ServerError going forward so that we can handle it in middleware correctly. So we should possibly have the FormError extend the ServerError, at least for Qwik apps.
The text was updated successfully, but these errors were encountered: