You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
First, thanks for creating the framework. I'm new to it but I think there are a lot of interesting and exciting ideas here.
As a newcomer, one of the surprising things to me as I port an app over to Remix is the bubble up behaviour of CatchBoundary. The rationale for the bubble up behaviour, as I understand, is that it ensures all errors are "handled". Instead of an add to cart button failing silently, we show the user a predefined error component (even if it's several components up). I understand this is one of the core concepts of Remix, but I wanted to share why I would prefer to keep this bubble up behaviour off.
Rationale 1
I think this is actually a strictly worse experience. The correct behaviour where I would consider the error "handled" in that nextjs/remix ecommerce example is some UI element that communicates the add to cart button is broken (ex. it turns red), anything else, I would considered that "unhandled" (ex. for nextjs, that's no action. for remix, that's showing the catchboundary of the parent component).
In the ecomm example, having the button do nothing is frustrating, but the user still has options. They can re-try manually (which would actually fix some errors), or they can still use the rest of the page, like looking through pictures. In Remix, the user gets one try, and if it fails, they are barred from doing anything else.
Rationale 2
On a typical React frontend application with no ErrorBoundaries, any thrown errors completely crashes the whole app. This is why ErrorBoundaries are so great on the front-end, it constraints the failure. In CatchBoundary, this is opposite! HTTP request failures are already constrained by default (they affect only exactly the parts that need to be affected).
If you consider two applications, one where http request errors fail silently, and one where http request errors crashes the whole app (essentially what the CatchBoundary is doing in the Remix ecomm example), and ask a bunch of users to rate these applications, I would bet most users think that the Remix app is way more unstable and frustrating to use, as action/loader failures are completely catastrophic failures.
The best UX will be if every component had a CatchBoundary. The error will then be constrained, specific, and likely more helpful. But, as was noted in the remix vs next blog post, many developers will just skip this. In most cases, they might just have a root CatchBoundary! Providing an option to turn off the bubbling behaviour and default to no action if no CatchBoundary was defined (in the same component as the failing loader/action) would be helpful for the reasons outlined above. This would also keep the other benefits of CatchBoundary, which is keeping failure out of the happy path.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
First, thanks for creating the framework. I'm new to it but I think there are a lot of interesting and exciting ideas here.
As a newcomer, one of the surprising things to me as I port an app over to Remix is the bubble up behaviour of CatchBoundary. The rationale for the bubble up behaviour, as I understand, is that it ensures all errors are "handled". Instead of an add to cart button failing silently, we show the user a predefined error component (even if it's several components up). I understand this is one of the core concepts of Remix, but I wanted to share why I would prefer to keep this bubble up behaviour off.
Rationale 1
I think this is actually a strictly worse experience. The correct behaviour where I would consider the error "handled" in that nextjs/remix ecommerce example is some UI element that communicates the add to cart button is broken (ex. it turns red), anything else, I would considered that "unhandled" (ex. for nextjs, that's no action. for remix, that's showing the catchboundary of the parent component).
In the ecomm example, having the button do nothing is frustrating, but the user still has options. They can re-try manually (which would actually fix some errors), or they can still use the rest of the page, like looking through pictures. In Remix, the user gets one try, and if it fails, they are barred from doing anything else.
Rationale 2
On a typical React frontend application with no ErrorBoundaries, any thrown errors completely crashes the whole app. This is why ErrorBoundaries are so great on the front-end, it constraints the failure. In CatchBoundary, this is opposite! HTTP request failures are already constrained by default (they affect only exactly the parts that need to be affected).
If you consider two applications, one where http request errors fail silently, and one where http request errors crashes the whole app (essentially what the CatchBoundary is doing in the Remix ecomm example), and ask a bunch of users to rate these applications, I would bet most users think that the Remix app is way more unstable and frustrating to use, as action/loader failures are completely catastrophic failures.
Real examples that this issue affects
My recommendation
The best UX will be if every component had a CatchBoundary. The error will then be constrained, specific, and likely more helpful. But, as was noted in the remix vs next blog post, many developers will just skip this. In most cases, they might just have a root CatchBoundary! Providing an option to turn off the bubbling behaviour and default to no action if no CatchBoundary was defined (in the same component as the failing loader/action) would be helpful for the reasons outlined above. This would also keep the other benefits of CatchBoundary, which is keeping failure out of the happy path.
Beta Was this translation helpful? Give feedback.
All reactions