Default ErrorBoundary and Hook?

[chantastic]

A couple days ago, @drcmda and I were having a discussion on Twitter over a minimal suspense-fetch example using only React-supplied libraries. ErrorBoundary and the third-party library use-error-boundary was came up as a point of frustration.

The current state of ErrorBoundary is extremely flexible — geared toward adaptability in real-world conditions. But I wonder if there is a way to provide a flexible convenience for newcomers as well.

My goal here is not so much to suggest a particular API but raise an area where there is a lot of newcomer friction.

While this might not hit all of the buttons, I think an experience like this could provide a very clean on-boarding experience:

import * as React from "react";
import * as ReactFetch from "react-fetch";

export default function App() {
  return (
    <React.ErrorBoundary fallback={<p>something went wrong</p>}>
      <React.SuspenseBoundary fallback={<p>...waiting</p>}>
        <PokemonCollection />
      </React.SuspenseBoundary>
    </React.ErrorBoundary>
  );
}

function PokemonCollection() {
  let data = ReactFetch.fetch(
    `https://pokeapi.co/api/v2/pokemon/?offset=${offset}`
  ).json();

  return (
    <ol>
      {data.results.map(({ name }) => (
        <li key={name}>{name}</li>
      ))}
    </ol>
  );
}

Problems

Providing a basic implementation definitely runs the risk of being interpreted as a default implementation. And, in an effort to make the component more flexible, there would be a number of unsightly design decisions that would have to be made:

// example
<React.ErrorBoundary
  fallback={(, errorInfo) => <p>This exact thing went wrong: {errorInfo}</p>}
  onCatch={(error, errorInfo) => logErrorToMyService(error, errorInfo)}
/>

Benefits

The benefit of providing a basic implementation is that newcomers get a quick path-to-first-fetch and can move quickly onto understanding the relationship between error boundaries and Suspense boundaries, and how to coordinate them with data.

[gaearon]

Just to clarify, is this more a...

• Proposal to add React.ErrorBoundary? (That seems like it should probably be an RFC.)
• Proposal to add a default error boundary + Suspense for default templates of CRA and Next.js?
• Some combination of the above?

[chantastic]

That's a great question!

I don't have an outcome in mind. Right now, I just want to raise a point of confusion/frustration in the newcomer experience.

Not having an basic ErrorBoundary component increases the perceived complexity of getting started examples and guides. It leaves educators in a position where they have to choose one of the following:

1. defer error handling to later in the curriculum
2. diverge from hooks based education to introduce classes and lifecycle events (only for errors)
3. install a third party

Proposal to add a default error boundary + Suspense for default templates of CRA and Next.js?

While this would be a positive newcomer experience for CRA and Next.js users, I worry that it won't improve React-only education material. And it might confuse folks as to where React ends and CRA/Next.js begin.

Proposal to add React.ErrorBoundary? (That seems like it should probably be an RFC.)

If you feel like such a component would be compatible with React's goals, I'm happy draft an RFC there.

---

As we've discussed in the past, there's a perception that React is "academic." And I think this is largely a byproduct of the flexibility that React provides to developers. If a guide was able to present the example above (no external libraries, no class components), it would help dispell the notion that React is comparatively "difficult" or "academic."

But I am not married to any particular outcome, if other options are in the pipeline.

[gaearon]

It leaves educators in a position where they have to choose one of the following:

Of these options, currently I would recommend that they either not teach it at all, or teach react-error-boundary.

I worry that it won't improve React-only education material. And it might confuse folks as to where React ends and CRA/Next.js begin.

What is React-only these days? Which scenario? CodeSandbox could also have them.

If you feel like such a component would be compatible with React's goals, I'm happy draft an RFC there.

There's existing discussion in reactjs/rfcs#126 so please feel free to participate!

If a guide was able to present the example above (no external libraries, no class components), it would help dispell the notion that React is comparatively "difficult" or "academic."

I see what you're saying but I also don't quite agree with the argument that adding react-error-boundary to a project is what stands between feeling academic or not. Considering installing things like Material UI happens very soon when learning, and if you didn't install any third parties, error handling might be a bit premature anyway. E.g. is this really different from installing react-fetch? Intuitively I'd expect that "feeling academic" has more to do with learning concepts like immutability than installing a component. But yes, we'd want this to be a first-class feature in the longer run. We just don't know the API yet.

[chantastic]

Thank you for the thorough reply!
Specifically for the link to the RFC. Understanding the thought process in deferring a first-class ErrorBoundary Component is helpful. And knowing that it isn't immediately up for consideration resolves my question, here.

Of these options, currently I would recommend that they either not teach it at all, or teach react-error-boundary.

I can definitely go this direction. I'm looking react-error-boundary now and the interface looks very similar to the example I posted.

What is React-only these days? Which scenario? CodeSandbox could also have them.

This could use some clarity on my end. From my perspective, a "React-only" persona has two sub-groups:

1. Those evaluating React for the first time, comparing it to UI libraries and frameworks
2. Those using React in addition to a full-stack framework. A decent example of this (which is conveniently similar my work experience) is GitHub. React is part of a mixed production stack that likely doesn't have the conveniences and additional ergonomics of Next.js or CRA.

While these stacks couldn't be described as "React-only", targeting "React-only" keeps material naturally inclusive of mixed-stack environments.

There's existing discussion in reactjs/rfcs#126 so please feel free to participate!

Thanks for the link! Reading thru the additional considerations, and knowing that there is not a near-term timeline for consideration is helpful and resolves my question.

I also don't quite agree with the argument that adding react-error-boundary to a project is what stands between feeling academic or not.

I agree that requiring a third-party library is not contributing to the problem of "feeling academic". I'd say these are isolated issues.

is this really different from installing react-fetch?

The difference is that react-error-boundary isn't maintained alongside React. Folks have been burned by libraries that are compatible — at the time of writing — but suffer from poor maintenance over time. react-fetch is an additional install — yes — but it's not 'third-party'. It's more akin to 'standard library'. There's an expectation that it will retain compatibility with the core library.

Obviously the specifics here are a little different, as the package is published and maintained by Brian. But that relationship isn't clear without fairly intimate knowledge of the team.

If react-error-boundary is the recommend library, could the package be maintained inside of React repo (to communicate it's proximity to React core)?

[markerikson]

FWIW, although Brian wrote that package originally, he handed maintainership over to Kent C Dodds a while back:

https://github.com/bvaughn/react-error-boundary/releases/tag/v2.0.0

[chantastic]

Thanks for the update, Mark.