Post
rich harris
@rich-harris.dev
<svelte:boundary>
suuuuper happy with how this panned out — been a major gap in svelte for a while, with our new foundation dominic was able to bang it out in like 5 minutes
give it a spin and let us know what you reckon
svelte.dev/playground/e...
</svelte:boundary>
We've been looking into add error boundaries to Svelte. If people would like an early preview and to play around with them, please do! Feedback is greatly appreciated:
github.com/sveltejs/sve...
November 8, 2024 at 7:23 AM
20 reposts
4 quotes
232 likes
fun fact, we're able to share these playground links because added support for pkg.pr.new — every PR results in an npm-installable package URL, and we grab that tarball and shove it into a virtual filesystem in a web worker that builds everything with rollup. neat!
we did it man! the 🐐 is using the tool.
So... it catches any error and displays the failed snippet? If so, then hopefully people won't use it global layout :D
Anyway, great work! Can't wait to use that
last time I checked react they still hadn't implemented error boundary :p
It's really bizarre that React was (as far as I know) the first to introduce the concept of error boundaries but never actually introduced them
To this day the official recommendation in the documentation is to use a third-party library that uses class components
Incredible work
It's a bit annoying that it's different from other control flow APIs, as it's not a block
But reading the PR it makes sense to choose this design for this API
yep, that was our first instinct, but we couldn't make it feel right
Great work, I feel like this really was the final missing part for svelte!
What's up with the "failed" snippet though?
Took me a while to understand that this is the expected way to handle errors.
Wouldn't a error boundary template block with ":else" be more intuitive here?
They address this in the pull request:
github.com/sveltejs/sve...
ah, because you can set an onerror handler on the svelte:boundary..
I'm not sure it's worth the tradeoff of breaking with svelte's usual way of handling control flow though
You could rethrow/log the error from inside a script tag of a component inside the try block.. not very elegant either though
Regarding "...svelte's usual way of handling control flow...", the `{#if}...{/if}` syntax really seems to scare a lot of people when they first view the framework, and telling them there's 10+ more to handle async/errors/whatever to learn doesn't help.
I feel only the bare minimum of control flow should be done with the "handlebars" syntax (`{#if}` and `{#each}`), with everything else being done via snippets. After using v5 for a while snippets just feel so much more versatile for advanced use-cases.
Also, splitting off the error case to a different {:catch} branch or whatever really starts to make it look like a JS try/catch block, and every try/catch block I come across is an absolute mess that often takes two passes to understand what it's doing (even if I wrote it lol).
Woah this is super cool - is it essentially a localized error catch, is state kept? From your example it seems like the mouse coords go back to 0,0 when you click "reset". Or is that just how the demo is?
If state is localized inside the boundary, it resets. If state is passed in from outside the boundary, it stays. That's my understanding.
Yep, exactly this. It doesn't make sense to try and preserve stuff inside the boundary because that's what resulted in an error
Nice error boundaries are very handy 🙌🏻
Great addition!
