Generic Error Boundary

[scheidtdav]

Type of Change

• Dependency upgrade
• Bug fix (non-breaking change)
• Breaking change
  • e.g. a fixed bug or new feature that may break something else
• New feature
• Code quality improvements
  • e.g. refactoring, documentation, tests, tooling, ...

Implementation

First of all the arguably rashly copy-and-pasted duplications of the ever same error boundary were removed.
Some unused code was cleaned up and a generic boundary was added.
This way no component has to declare a boundary itself. They sure can, but don't have to.

Only "downside" to the generic boundary is, that it is displayed on a blank page. However there are convenient back buttons.
If a component wants to handle errors more gracefully, I think it should implement its own version of an error boundary that is more helpful than just showing the generic message but inside its own layout.

Checklist

• I gave this pull request a meaningful title
• My pull request is targeting the dev branch
• I have added documentation to my code
• I have deleted code that I have commented out

Additional Information

[github-actions]

Coverage Report

Status	Category	Percentage	Covered / Total
🔵	Lines	71.27%	1670 / 2343
🔵	Statements	69.58%	1741 / 2502
🔵	Functions	73.33%	341 / 465
🔵	Branches	58.14%	928 / 1596

File Coverage

No changed files found.

Generated in workflow #2246 for commit 7065c72 by the Vitest Coverage Report Action

[jona159]

Should we come up with some criteria when we should use a component-level error boundary? It is still a bit unclear to me when we would want to favor it over the root error boundary

[scheidtdav]

Should we come up with some criteria when we should use a component-level error boundary? It is still a bit unclear to me when we would want to favor it over the root error boundary

I have added a quick note above the function itself until there is a better place to put this.
Things like this should go into developer documentation I suppose?
The more specific boundaries we get, the clearer it gets I suppose.