Add errorInfo argument to onError in Fizz

[gnoff]

Fizz currently accepts an onError callback which is provided any errors thrown during rendering. However previously the component stack was generated and sent to the client after logging the error so if you relied upon server logs to see where an error ocurred it was hard to make sense of it.

This change adds errorInfo as an optional second argument to onError. In dev, it will be passed a componentStack if one exists. in Prod the argument will be omitted because we do not generate component stacks in prod yet.

[sizebot]

Comparing: fecc288b7dce182fbc3056b3f98a445a95fb1e68...6f7aa85cf1120030c3b8f133ad16d835b51a56d0

Critical size changes

Includes critical production bundles, as well as any change greater than 2%:

Name	+/-	Base	Current	+/- gzip	Base gzip	Current gzip
oss-stable/react-dom/cjs/react-dom.production.min.js	=	152.69 kB	152.69 kB	=	48.70 kB	48.70 kB
oss-experimental/react-dom/cjs/react-dom.production.min.js	=	154.61 kB	154.61 kB	=	49.31 kB	49.31 kB
facebook-www/ReactDOM-prod.classic.js	=	526.73 kB	526.73 kB	=	94.10 kB	94.09 kB
facebook-www/ReactDOM-prod.modern.js	=	511.99 kB	511.99 kB	=	91.94 kB	91.94 kB
facebook-www/ReactDOMForked-prod.classic.js	=	526.73 kB	526.73 kB	=	94.10 kB	94.10 kB

Significant size changes

Includes any change greater than 0.2%:

(No significant changes)

Generated by :no_entry_sign: dangerJS against 6f7aa85cf1120030c3b8f133ad16d835b51a56d0

[sebmarkbage]

Hm. It's unfortunate to expose this only in DEV when it's prod on the client. Maybe we'll do the full stacks but those are really slow to generate and there are many legit reasons to throw on the server (intentional client rendering, redirects, etc). Maybe if we have a way to opt out those.

The main purpose of this API is to log in production to a server in production. Maybe we should console.error even if this is implemented and instead have some other override to take over those logs?

[github-actions[bot]]

This pull request has been automatically marked as stale. If this pull request is still relevant, please leave any comment (for example, "bump"), and we'll keep it open. We are sorry that we haven't been able to prioritize reviewing it yet. Your contribution is very much appreciated.