- Start Date: 2021-02-09
- RFC PR: (leave this empty)
- Svelte Issue: (leave this empty)
Creation of an error boundary which catches errors and allows the system to handle them.
- After using Sentry in production to handle errors, having specific boundaries for handling errors in different ways is desirable.
- Catching errors in Sapper is critical and currently infeasible. Errors in Sapper break the router, and a user sees a "frozen" site. I would imagine this is similar for Kit.
It's a bit of a dealbreaker for Sapper users currently.
There's actually prior art. I use this in production myself. The source code for such is here:
https://github.com/crownframework/svelte-error-boundary
and a working example here:
https://svelte.dev/repl/9d44bbcf30444cd08cca6b85f07f2e2a?version=3.29.4
My suggestion for alternative syntax is detailed below, but I am proposing a tag which can be added to any component to make it a boundary:
<svelte:error handler={myErrorHandler} />
This solves a solution such as on:error
attribute being a breaking change.
This exists in a variety of frameworks, React has native support, whilst vue currently does not.
The impetus for creating it as a native feature of Svelte is to prevent the "brittle" nature of the way the current third-party solution works.
See:
There is actually a reference implementation which has been proven to work in production environments. I would suggest that we go with this implementation.
The stark advantage to making this part of core is that the current implementation relies on non-public parts of the Svelte API which can change at any time, causing it to be brittle.
The pre-existing component uses onError
for technical reasons, I can suggest two alternatives for handling
this as onError
doesn't really fit the Svelte language:
- To allow components to simply implement
on:error
as with existing handlers, however the naming of such would have to be considered, as it is likely that people will have alread created custom events with the nameerror
and this would conflict with them. - To allow a new svelte tag
<svelte:error handler={myErrorHandler}>
. This tag could be included in any component to make itself a boundary.
The important factor here is allowing a handler function, which can then be wired up to https://forum.sentry.io/t/requesting-svelte-support/8477 or LogRocket. Sentry have noted that lack of an error boundary component is a blocker to them having native support for Svelte.
- Is API documentation required? Yes.
- Is a tutorial section required? No.
Community support will be available for this, for example, Sentry would likely add a section to their documentation about specific Svelte integration, which they currently can't do due to lack of this component.
Implementation drawbacks:
on:error
would be a breaking change.onError
is not Svelte-esque syntax- A directive doesn't feel like a core component
Therefore I propose the tag approach <svelte:error handler={} />
.
With regards to drawbacks of a tag:
Q. You can't put this tag into third-party components A. This isn't really a drawback, implementors can either add the tag in their libraries and allow the user to pass in a handler function, or, you can wrap any component you want as an error boundary, with a new component which has the tag.
I don't have any alternatives right now, other than sticking with the crownframework boundary and being careful during Svelte upgrades, which isn't very scalable.
Merely Syntactical. I don't know if my suggestion around a new tag is feasible/desirable/can solve all use-cases.