* It's not very useful to write error handling code in every component. The thinking about the feature is you'll put it in a few strategic places: https://facebook.github.io/react/blog/2017/07/26/error-handl...

* If error boundary could catch its own errors, what happened if it tried to render error message and threw then? It would get into an infinite loop, trying to handle its own error and failing again. Thanks to the restriction, this can never happen.

When a component throws, it means the user's code has encountered an unexpected error. That means the component is in an unexpected state, and you cannot reasonably say that that component can rebuild it's (internal) state to a stable (and renderable) state.

but in theory at that point in the operation, we're still in the process of building a new DOM (hence the old DOM is still around)? So you could replace the component with an error node and during the diffing process replace with the old node?

Not great but if you hit a fatal error you hit a fatal error

personally I would rather a website tell me that an error occurred using the new mechanism than fall back to a previous version of the DOM and have me wondering why clicking that button isn't doing anything.

If you package this up as a higher-order component, you basically get this behavior. It would be pretty easy to do. But I think the way they designed it is smart. You want components that account for very granular concerns, and then compose them together to get more complex behavior.