/ directus Public
Improve error handling for app extensions #17191
Add this suggestion to a batch that can be applied as a single commit. This suggestion is invalid because no changes were made to the code. Suggestions cannot be applied while the pull request is closed. Suggestions cannot be applied while viewing a subset of changes. Only one suggestion per line can be applied in a batch. Add this suggestion to a batch that can be applied as a single commit. Applying suggestions on deleted lines is not supported. You must change the existing code in this line in order to create a valid suggestion. Outdated suggestions cannot be applied. This suggestion has been applied or marked resolved. Suggestions cannot be applied from pending reviews. Suggestions cannot be applied on multi-line comments. Suggestions cannot be applied while the pull request is queued to merge.
Currently when an app extension is faulty or contains bugs, the error thrown will brick the app, thus requiring a browser refresh.
This PR aims to handle said errors more gracefully for app extensions such as panels, flows, interface and displays using the
onErrorCaptured()lifecycle hook. It is then used inside a
<v-error-boundary>component, similar to React's Error Boundaries and a Vue counterpart of error boundary.
For Module and Layout extensions, currently the added global error handler does prevent the app from breaking entirely anymore, but I've opted to not implement "low-level" error handler for them because they may incur more changes, to be more specific:
Module: After this PR, module that has error will be a blank route, but we can go back to previous page since the global error handler prevents it from crashing.
The blocker for lower level module error handler would be each module is wrapped by the
Lines 42 to 49 in 6793d9f
which is a functional component used in several other places:
Lines 1 to 8 in 6793d9f
so if we want to narrow down and capture module errors "earlier", we may need to have another router view wrapper specifically for modules.
Layout: After this PR, layout that has error will just be empty (but nav, sidebar etc are all intact) and will not crash the app anymore.
THe blocker for lower level layout error handler would be layouts are generally wrapped into LayoutWrapper in several places, so if we wish to capture layout specific errors, we may need to cover all layout wrapper usages in the app.
Type of Change
If adding a new feature: