-
Notifications
You must be signed in to change notification settings - Fork 68
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
Enh error handling #330
Enh error handling #330
Conversation
allow full control of error handling with global fallback handler add 404 error add websocket opening control for get methods
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.
Uuuuuugh i'm not sure how to review this because ETOOMANYCHANGES ... Looking in diagonal this just looks legit to me and I would naively just yolomerge this to be able to test & iterate
Alright idk, yolomerging, I may have some time tonight to re-test the entire new vuejs interface |
Changelog
The changelog is also there for me to remember to add this to the docs.
I called every API calls "request", and "actions" are requests that are usually triggered by the user and ends up in the history. "request" that have
websocket: true
are "actions".reworked the whole process of making a call to the api:
api.get()
,api.post()
,api.put()
,api.delete()
) to call for data that is cached or not (used to be separate functions), the difference is theuri
arg which is a string for a regular call and an object literal ({ uri, storeKey }
for a cached call.api.fetchAll
(see below) to every initial request (data needed by a view to render itself). The option allow to trigger a redirect if the view can't render so the user doesn't get stuck at a never ending skeleton.api.getAll
and replaced it by a more genericapi.fetchAll
that allow all method types.store.waiting
to true then false only once).added global error handler for
unhandledrejection
. This will catch errors that are thrown/rejected from inside a promise (all our api calls).A view (like form views for instance) can catch an error before the global handler and mitigate its propagation or display it independently.
If nothing catch the error it will be displayed as a modal blocking the view (like the "waiting for server response"). The user will have to click on "Ok" to dismiss the modal or "Go back" to go to previous page if the error occurred as an initial query.
This global handling only cares about
APIError
s, regular javascript or other unexpected errors will still end up in the browser's console with no specific handling.APIError
carries more information that is used to display proper error messages and can also be used when caught in a view to decide what to do with it:name
: Error's name as stringcode
: response'sstatus
status
: response'sstatusText
method
: method of the guilty api callpath
: api call's urirequest
: some data produced by the api caller that is used in the history and overlaynew error:
APIErrorLog
. Thrown if the error response haslog_ref
in it. Setting this as an error on itself is convenient, it avoid checking this in a catch and let it be handled by the global catcher and redirect the user to the lognew error:
APINotFoundError
. (That should not append but just in case…)add ability to review an error from the history (only those with websocket for now but won't be hard to inject a failed
GET
request to the history if we want to)rework the error and waiting modal:
rework a bit the history (but will still need some improvements):
last action
which will auto display the last one.misc short fixes:
- moved
ErrorPage
,DomainForm
,PasswordForm
intoviews/_partials
to differentiate modular components from reusable view samples- fixed error modal not closing itself if user hit the browser's back button.
- removed the
Error
route since every errors are now displayed in a modal- removed the obligation of having a name that is at least 2 characters in user creation.
- fixed
runDiagnosis
missing execution- fixed
ToolLog
's actionShare with YunoPaste
missing websocket message.- fixed the ConfigPanel view, i mean it works for Archivist at least.
Preview
History
Waiting Modal
Error Modal
PR Status
Will require some tests since i had to modify quite a few lines dXD.