DEV Community

loading...
Cover image for #9 Of 100DaysOfCode

#9 Of 100DaysOfCode

icecoffee profile image atulit023 Updated on ・2 min read

In the continuation of my yesterday's topic, I studied more about state management in React and a couple of more topics.

Following are the new things that I learned today about React.

  • Synthetic Event handlers
    Just like browsers React got its native event handlers too. But you may as why do we need'em? We already got our silly old toys to play with. But hold up,

    • Synthetic event handlers provide improved performance and
    • Cross Browser compatibility.
  • Then there was this thing about when React renders or re-renders?
    So react renders when

    • State changes - any of it and remember state must always be declared at the top of the scope.
    • Prop changes
    • Parent renders
    • Context Changes As React is a declarative language so we rarely need any optimization but you still can control whether the state should render or not explicitly.

Here you can get more info about states.

  • useContext() useContext hook is a great tool and I learned something more about it .
useContext(callback, [dependency array])
Enter fullscreen mode Exit fullscreen mode

Now we all know about the callback but the dependency array is the new cool thing
dependency array is a list of reasons that will make useEffect re-render or in layman's terms any states or props we will list in this array will make useEffect re-render every time they change.
The second definition is better, I know. lol

  • Handling Errors via Error Boundary This thing takes care of its child.
class ErrorBoundary extends React.Component {
  constructor(props) {
    super(props);
    this.state = { hasError: false };
  }

  static getDerivedStateFromError(error) {
    // Update state so the next render will show the fallback UI.
    return { hasError: true };
  }

  render() {
    if (this.state.hasError) {
      // You can render your custom fallback UI for errors
      return (
                <h1>Heyyy!!! Glitch in the martrix.😲 
                    Sit tight we are coming...</h1>
      );
    }

    return this.props.children; 
  }
}
Enter fullscreen mode Exit fullscreen mode

Code for making an error boundary class

And then you can just use it like a normal component. 😀

<ErrorBoundary>
  <App />
</ErrorBoundary>
Enter fullscreen mode Exit fullscreen mode

Pretty cool right!!!

I know this looks familiar.
Here you can get this in a little more detail.

But, It got limitations too.

  • The Error Boundaries ought to be classes
  • They can't catch certain types of errors:
    • Errors in event handlers
    • Errors in async code
    • Errors in server sider rendering
    • Error thrown in error boundary itself Also they are just concerned of the errors within their child elements.

A little tip

We can handle async errors with error boundries with a little bit of quick fix.
Plan:

  • Make a state that will store error and set it to null.
  • Catch error and set state equals to corresponding error.
  • Apply an if before rendering markup
if(error) throw error
Enter fullscreen mode Exit fullscreen mode

and error boundary will take over.😎
LOL Nice.

That's it for today.😌
Thanks for joining me.
Have a wonderful day.🌷

Discussion (0)

Forem Open with the Forem app