-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(react): add ErrorBoundary component #4619
feat(react): add ErrorBoundary component #4619
Conversation
Deploy preview for carbon-elements ready! Built with commit c910ea4 |
Deploy preview for carbon-components-react ready! Built with commit c910ea4 https://deploy-preview-4619--carbon-components-react.netlify.com |
Deploy preview for the-carbon-components ready! Built with commit c910ea4 https://deploy-preview-4619--the-carbon-components.netlify.com |
@jendowns any tips on getting the prop table to generate correctly? 😂 |
… into feat/add-error-boundary
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey @joshblack! I have an idea for this --
|
||
return 'Successfully rendered'; | ||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@joshblack You could add this to give DemoComponent
the same info as ErrorBoundary
, so it will show the right component name in the story source + also show the props in the prop table.
(Though unfortunately all props will be Oh oops, they ARE type node
type -- I'm not sure how to fix that yetnode
😆 Disregard this comment then)
DemoComponent.displayName = 'ErrorBoundary'; | |
DemoComponent.__docgenInfo = ErrorBoundary.__docgenInfo; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This might be a dumb question, but what's the difference between this proposal and:
DemoComponent.__docgenInfo = ErrorBoundary.__docgenInfo;
Just noticed the double spread and was curious.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh there's no difference! I think I've personally gotten into the habit of doing this as a way to very explicitly show "I'm need the props here" etc 😆 I'll update my suggestions to be more succinct 👍
|
||
return 'Successfully rendered'; | ||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same as above:
DemoComponent.displayName = 'ErrorBoundary'; | |
DemoComponent.__docgenInfo = ErrorBoundary.__docgenInfo; |
@aledavila let me know if you want to go through this today! |
Same to you @vpicone if you want to chat about it 😄 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@joshblack looks solid. Is this meant as a helper for us internally? There's nothing Carbon specific with how this would be implemented right?
@vpicone nah, just a pattern that seems to come up more that would be great to bring in so folks could use it. Just makes it easier to build stuff with Carbon 😄 |
Let me know if you have any questions @vpicone @aledavila! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great
Let me know if you have any questions @vpicone! |
@joshblack no questions, just not sure I agree that it goes with the rest of the library. I don’t think we should include components that have nothing to do with the design language but increase or surface area for no reason other than someone might find it helpful. What if react-router/gatsby/next started exporting an ErrorBoundary helper. If I’m an app dev do I use there’s or Carbons? Both/Either? I think increasing the surface area of the library and the types of the components we export might not actually make Carbon easier to build with. |
@vpicone happy to chat about this in person, I think this matches our path forward with exposing best practices and patterns for building UIs at IBM. I think as a system when we start going into patterns territory we're not so much targeting a design language as helping folks build better product experiences. I think this component helps further that goal and would be a great addition. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me. And I agree that helpers like this (and a few others we've talked about) will be more and more necessary when we're shipping whole experiences via patterns
* consumers can specify their own logic for logging errors. For example, | ||
* reporting an error in the UI to an external service for every `ErrorBoundary` | ||
* used. | ||
* |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lovely documentation.
React introduced error boundary handling in v16. This PR aims to form an opinion on what an error boundary means for a design system. At a high-level, this works by doing the following:
With this setup, if
ComponentThatMayThrow
or any of its children have an error the component passed tofallback
will be displayed instead.This API was heavily inspired by Data fetching with Suspense in Relay
The way this may work in product is as follows:
In addition,
ErrorBoundary
has an optionalErrorBoundaryContext
that may be supplied. The only method currently islog
which is called incomponentDidCatch
as a side-effect. This may be useful for logging errors to an external service.Changelog
New
ErrorBoundary
andErrorBoundaryContext
Changed
Removed