-
Notifications
You must be signed in to change notification settings - Fork 70
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
Create a generic error handling mechanism #10865
Conversation
775149f
to
2ba1675
Compare
Codecov ReportPatch coverage:
Additional details and impacted files@@ Coverage Diff @@
## master #10865 +/- ##
==========================================
+ Coverage 79.25% 79.28% +0.03%
==========================================
Files 549 550 +1
Lines 9297 9325 +28
Branches 1218 1220 +2
==========================================
+ Hits 7368 7393 +25
- Misses 1720 1722 +2
- Partials 209 210 +1
☔ View full report in Codecov by Sentry. |
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.
Ryddig og bra!
frontend/packages/shared/src/components/ErrorBoundaryFallback.tsx
Outdated
Show resolved
Hide resolved
Agree with @TomasEng clean and nice work! Loved the way we can pass a configuration object for QueryClient into the ServiceContext. 👏 Looking forward to getting this merged into the master branch. :) |
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.
👏
Description
Created a generic error handling mechanism using :
react-error-boundary
to catch errors that occur during rendering (synchronous) (https://react.dev/reference/react/Component#catching-rendering-errors-with-an-error-boundary)react-query
callbacks to catch errors that occur when an API call fail (asynchronous) (https://tkdodo.eu/blog/react-query-error-handling)axios
interceptors seem like the best place for handling errors as they are closer to the HTTP Layer, but using them withreact-query
can be problematic due to the retry mechanism, which would show an error from the first request and log multiple identical requests. The main drawback of not usingaxios
interceptors is that our error handling won't work if we useaxios
directly (e.g. XSDUpload).Moved the QueryClient instance inside the component to access the i18n instance, as suggested here.
Added a new clientConfig property to pass a QueryClientConfig to ServicesContext, instead of passing a QueryClient instance, as QueryCache and MutationCache can't be set after a QueryClient instance has been created.
Disabling global error message
Now, whenever an API call fails, a toast will be shown displaying a generic error message. This can be problematic if we already have a specific error message, as both error messages will be visible.
To prevent these duplicate error messages, we can disable the global error message by setting
meta.hideDefaultError
totrue
(as suggested here and here).We can also disable it for specific HTTP codes:
Related Issue(s)
Verification
Documentation