Welcome to ShenZhenJia Knowledge Sharing Community for programmer and developer-Open, Learning and Share
menu search
person
Welcome To Ask or Share your Answers For Others

Categories

What I understood from here:

componentDidCatch:

  • is called always in the browser
  • is called during the "commit phase" when the DOM has already been updated
  • should be used for something like error's reporting

getDerivedStateFromError:

  • is also called during server-side-rendering
  • is called in "render phase" when the DOM has not yet been updated
  • should be used for rendering a fallback UI

Still, I'm bit confused about some things:

  1. are they both catching the same type of errors? or each lifecycle will catch the different error?
  2. should I always use both (in the same "error-catching" component possibly)?
  3. "using componentDidCatch for error recovery is not optimal because it forces the fallback UI to always render synchronously" what's wrong with that?
See Question&Answers more detail:os

与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…
thumb_up_alt 0 like thumb_down_alt 0 dislike
397 views
Welcome To Ask or Share your Answers For Others

1 Answer

The statements in the question are mostly correct. Currently error boundaries aren't supported in SSR, getDerivedStateFromError and componentDidCatch don't affect server side.

are they both catching the same type of errors? or each lifecycle will catch the different error?

They are catching same errors but at different phases. This previously was possible with componentDidCatch alone:

  static getDerivedStateFromError() {
    return { hasError: true };
  }

and

  componentDidCatch() {
    this.setState({ hasError: true });
  }

do the same thing, componentDidCatch has no chances to be supported on server side until the support for asynchronous rendering will be added to ReactDOMServer.

should I always use both (in the same "error-catching" component possibly)?

You can use both. An example from the documentation shows that:

class ErrorBoundary extends React.Component {
  state = { hasError: false };

  static getDerivedStateFromError(error) {
    return { hasError: true };
  }

  componentDidCatch(error, info) {
    logComponentStackToMyService(info.componentStack);
  }

  render() {
    if (this.state.hasError) {
      return <h1>Something went wrong.</h1>;
    }

    return this.props.children; 
  }
}

In this case responsibilities are divided between them. getDerivedStateFromError does the only thing it is good for, i.e. updates the state if an error occurs, while componentDidCatch provides side effects and can access this component instance if needed.

"using componentDidCatch for error recovery is not optimal because it forces the fallback UI to always render synchronously" what's wrong with that?

New React releases are aimed at asynchronous rendering which is more efficient. As it was also mentioned in the comment, synchronous rendering is not a big concern for fallback UI because it can be considered edge case.


与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…
thumb_up_alt 0 like thumb_down_alt 0 dislike
Welcome to ShenZhenJia Knowledge Sharing Community for programmer and developer-Open, Learning and Share
...