Join the discussion
Comments
Loading comments...
Cookie preferences
We use essential cookies for sign-in and preferences. With your permission, we also use basic analytics to improve lessons.
Join the discussion
Loading comments...
We use essential cookies for sign-in and preferences. With your permission, we also use basic analytics to improve lessons.
React कैसे component tree में errors पकड़ता है और fallback UI दिखाता है।
Error Boundaries, React class components हैं जो अपने child component tree में कहीं भी JavaScript errors catch करते हैं, उन errors को log करते हैं, और पूरी application crash होने की बजाय fallback UI display करते हैं। ये JavaScript के catch{'} block की तरह काम करते हैं, लेकिन component tree के लिए। एक Error Boundary, rendering के दौरान, lifecycle methods में, और नीचे पूरे tree के constructors में errors catch करता है।
जब subtree का कोई component rendering (या lifecycle method में) throw करता है, React error को fiber tree में ऊपर propagate करना शुरू करता है, सबसे नज़दीकी Error Boundary ढूंढते हुए।
React parent fibers में ऊपर traverse करता है। यदि कोई class component मिलता है जो getDerivedStateFromError या componentDidCatch implement करता है, तो वहाँ रुक जाता है। यदि बिना कुछ मिले root तक पहुंच जाता है, तो पूरी app unmount हो जाती है।
React boundary class पर getDerivedStateFromError(error) call करता है। यह static method नई state return करती है (जैसे '{' hasError: true '}') जिससे boundary fallback UI के साथ re-render होती है।
Fallback UI दिखाए जाने के बाद, React componentDidCatch(error, errorInfo) call करता है — error को Sentry जैसी logging service पर भेजने के लिए एक अच्छी जगह।
Boundary component अपनी state (hasError) check करता है और या तो children (normal) या एक fallback JSX element render करता है। Boundary के बाहर बाकी app normally काम करती रहती है।
Static class method। Child throw करने पर render phase के दौरान call होता है। Fallback rendering trigger करने के लिए नई state return करता है।
Instance method। Fallback render होने के बाद commit phase के दौरान call होता है। Error logging के लिए उपयोग करें। Error + component stack receive करता है।
Errors fiber tree में सबसे नज़दीकी boundary तक bubble होते हैं, जैसे exceptions call stacks में bubble होती हैं।
Boundaries को उनकी key prop बदलकर reset किया जा सकता है, जिससे React पूरे subtree को unmount और fresh remount करता है।
1class ErrorBoundary extends React.Component {2 state = { hasError: false, error: null };34 static getDerivedStateFromError(error) {5 // Called during render — must be pure, no side effects6 return { hasError: true, error };7 }89 componentDidCatch(error, info) {10 // Called after commit — safe for side effects like logging11 logErrorToSentry(error, info.componentStack);12 }1314 render() {15 if (this.state.hasError) {16 return <FallbackUI error={this.state.error} />;17 }18 return this.props.children;19 }20}2122// Usage:23<ErrorBoundary>24 <MyComponent /> {/* If this throws, ErrorBoundary catches it */}25</ErrorBoundary>
Error boundaries के बिना, एक single unhandled render error पूरी React app crash कर देता है और blank screen दिखाता है। Error boundaries आपको failures को UI के isolated sections तक quarantine करने देते हैं — बाकी app काम करती रहती है। यह production apps के लिए critical है जहाँ आप हर edge case predict नहीं कर सकते।
Your e-commerce app crashes in production when a product with malformed data renders. The entire page goes white and users see nothing — you lose the sale and have no visibility into what happened.
Without error boundaries, a single component throwing an error unmounts the ENTIRE React tree. The user sees a blank page. No error tracking fires because the crash happened during rendering, not in a try/catch block.
Wrap critical sections in error boundaries with strategic granularity: one around the product card, one around the cart, one around the whole page. Use componentDidCatch to send the error + componentStack to Sentry. Show a helpful fallback UI ('Something went wrong, refresh to try again') instead of a blank page.
Takeaway: Error boundaries are your PRODUCTION safety net. Place them at route level (catch everything), feature level (isolate failures), and widget level (for third-party components you don't control). Always log to an error tracking service in componentDidCatch.
You embed a third-party analytics chart widget in your dashboard. After a library update, the widget occasionally throws during rendering due to unexpected data formats.
The chart crash cascades — it's nested inside your dashboard layout, so the error propagates up and takes down the entire dashboard, including the navigation, sidebar, and all other widgets.
Wrap ONLY the third-party widget in its own error boundary. The fallback shows a placeholder ('Chart unavailable — refresh to retry'). The rest of the dashboard remains fully functional. Users can still use all other features while you investigate the chart issue.
Takeaway: Error boundaries give you component-level fault isolation, similar to microservice circuit breakers. Treat each third-party or unstable component as an isolated fault domain.