Improve error handling in BlockContent

[balazsorban44]

The title says it all, I was curious if it would be a good idea to be able to either set an ENV variable or send a prop to the block renderer, so if NODE_ENV !== "production", only write missing serializer types errors to the console, instead of throwing. I am working in Next.js, and these errors cause the app to crash if BlockContent throws an error on server-side. We cannot add all the serializer types at once.

[richardvanbergen]

I'm also affected by this. My issue was that I was using the build in sanity reference type in a block. The block content for some reason didn't know how to handle this and would crash the entire application in the preview.

Strangely, the reference was a child of another block and it was the top-level block that was complaining when nothing had been added. I think it was something to do with the preview and fetching new data from sanity.

I "fixed" by adding a serialiser for the reference at the top level of the application. Seems to still be rendering the array references on the next level down so I'm happy.

Some sort of option to render as a fallback or some error handling built in would be a more desirable option to console.error, I think. The built in React error boundaries don't help in my case because the error was caused as a result of an async action.

[xiata]

It would be nice to have a prop to handle unknown schema types, e.g. unknownType where the default behavior is to do the exact thing it is currently doing right now: throw, but allow a react component to specified.

Why?

• Current behavior is preserved, so no backward compatibility issues introduced.
• Allows the developers to better work as teams allowing creation and usage of new schema without causing pages to crash if the developer's branch isn't aware of it yet. This is providing the developer opts in by defining a component that can do things such as draw a placeholder, complain to sentry, console log errors, or whatever the developer decides.
• Much nicer than the current "wait for a teammate to break my page, then stub out their new schema type on my branch" approach.

[balazsorban44]

I really like the idea by @xiata!

[balazsorban44]

Looks like there is already an open issue similar to this #10

[rexxars]

Closing this, as the new @portabletext/react library is the successor to this module. Please see https://github.com/portabletext/react-portabletext