[Bug]: Docs Rendering does not recover from errors thrown in React

[tmeasday]

Describe the bug

If you get an error in your MDX that comes from React (e.g. invalid value passed to useOf), and you fix it on HMR, all you get is a white screen.

To Reproduce

1. yarn start
2. Add to Introduction.mdx:

import * as ButtonStories from './Button.stories';

<Meta of={ButtonStories} />
<Story of={ButtonStories} />

3. You see an error:
   

4. Change to <Story of={ButtonStories.Primary} />

5. You see a white screen, no error in console:

System

No response

Additional context

No response

[shilman]

Shiver me timbers!! I just released https://github.com/storybookjs/storybook/releases/tag/v7.0.0-beta.63 containing PR #21454 that references this issue. Upgrade today to the @next NPM tag to try it out!

npx sb@next upgrade --prerelease

[wintercounter]

Unfortunately, I'm still experiencing this issue using 7.0.6. Ever since I upgraded to v7 I constantly need to restart Storybook as it's not recovering after I make slight modifications to my components.

I'm using it with React+Webpack, CSF 3.

MDX:

import * as Stories from './button.stories';

<Meta title="Elements/Button" />
<Canvas of={Stories.Showcase} />

[tmeasday]

@wintercounter are the errors in the .mdx files or the components? I think you might want to open another issue for this with a reproduction.

[yannbf]

@tmeasday I found out how to reproduce it, it's quite simple actually, just add a throw new Error('bla') to a component

error.recovery.mov

[wintercounter]

@tmeasday It's happening in docs. It's not consistent to reproduce it for me. Sometimes it doesn't do it for a longer period, sometimes on the first change. The error I get is exactly the same as OP (different from @yannbf's repro). It's an even bigger issue that many times it does this on error-free changes, like duplicating a simple <div />.

Error with stack:

Error
Invalid value passed to the 'of' prop. The value was resolved to a 'component or unknown' type but the only types for this block are: story.
- Did you pass a component to the 'of' prop when the block only supports a story or a meta?
- ... or vice versa?
- Did you pass a story, CSF file or meta to the 'of' prop that is not indexed, ie. is not targeted by the 'stories' globs in the main configuration?
Call Stack
 DocsContext.resolveOf
  runtime.mjs:82:4027
 useSourceProps
  vendors-node_modules_storybook_addon-docs_dist_chunk-PCJTTTQV_mjs.iframe.bundle.js:468:534
 useDeprecatedPreviewProps
  vendors-node_modules_storybook_addon-docs_dist_chunk-PCJTTTQV_mjs.iframe.bundle.js:488:1271
 Canvas
  vendors-node_modules_storybook_addon-docs_dist_chunk-PCJTTTQV_mjs.iframe.bundle.js:488:2202
 renderWithHooks
  vendors-node_modules_pmmmwh_react-refresh-webpack-plugin_client_ErrorOverlayEntry_js-node_mod-7ceeba.iframe.bundle.js:180051:18
 mountIndeterminateComponent
  vendors-node_modules_pmmmwh_react-refresh-webpack-plugin_client_ErrorOverlayEntry_js-node_mod-7ceeba.iframe.bundle.js:183815:13
 beginWork
  vendors-node_modules_pmmmwh_react-refresh-webpack-plugin_client_ErrorOverlayEntry_js-node_mod-7ceeba.iframe.bundle.js:185328:16
 HTMLUnknownElement.callCallback
  vendors-node_modules_pmmmwh_react-refresh-webpack-plugin_client_ErrorOverlayEntry_js-node_mod-7ceeba.iframe.bundle.js:167910:14
 Object.invokeGuardedCallbackDev
  vendors-node_modules_pmmmwh_react-refresh-webpack-plugin_client_ErrorOverlayEntry_js-node_mod-7ceeba.iframe.bundle.js:167959:16
 invokeGuardedCallback
  vendors-node_modules_pmmmwh_react-refresh-webpack-plugin_client_ErrorOverlayEntry_js-node_mod-7ceeba.iframe.bundle.js:168023:31

[wintercounter]

I've put a breakpoint where the error is. Here are the values around there when throwing the exception.

[wintercounter]

Here is the initial value for resolved when restarting Storybook. (Sorry for the spam.) It seems like type is changing from story to component upon saving and that's causing the issue.

storybook/code/lib/preview-api/src/modules/preview-web/docs-context/DocsContext.ts

Lines 134 to 147 in c10da37

	private resolveModuleExport<TType extends ResolvedModuleExportType>(
	moduleExportOrType: ModuleExport
	): ResolvedModuleExportFromType<TType, TRenderer> {
	type TResolvedExport = ResolvedModuleExportFromType<TType, TRenderer>;
	const csfFile = this.exportsToCSFFile.get(moduleExportOrType);
	if (csfFile) return { type: 'meta', csfFile } as TResolvedExport;
	const story = this.exportToStory.get(moduleExportOrType);
	if (story) return { type: 'story', story } as TResolvedExport;
	// If the export isn't a module, default or story export, we assume it is a component
	return { type: 'component', component: moduleExportOrType } as TResolvedExport;
	}

It seems like in the exportToStory Map this export won't exist, so it'll return as a component. I guess it's completely valid to receive a new module reference, but why is it the same reference sometimes and completely different other times?!

[tmeasday]

@yannbf I guess that's a new issue that was never actually addressed by this PR or #22127 shall we open a new issue? Probably easy to fix by changing the showMain here to unset the error?

storybook/code/ui/blocks/src/components/Story.tsx

Lines 52 to 55 in cded4cd

	showMain: () => {},
	showError: ({ title, description }: { title: string; description: string }) =>
	setError(new Error(`${title} - ${description}`)),
	showException: (err: Error) => setError(err),

[tmeasday]

@wintercounter Can you log what's actually in moduleExportToType when the error occurs? Is it empty or does it contain "old" story references?

It seems very odd though, IIRC the code path is that the HMR triggers a recreation of the DocsContext and a re-rendering of the DocsContainer (containing your MDX, and ultimately the Story block) with that new context. So I am not sure how the the Story block could end up talking to the old context.

It's not when you make >1 change at the same time?

The error I get is exactly the same as OP

To be clear the error in the OP is a legitimate error, this issue was about SB not recovering from that error, if you made a mistake and passed the wrong thing to <Story of={}>. But we can debug further here if you can't get a repro.

[tmeasday]

Maybe it is an interaction with React Refresh somehow. I wonder what component it is trying to re-render?

What's also odd in your stack trace is:

  vendors-node_modules_pmmmwh_react-refresh-webpack-plugin_client_ErrorOverlayEntry_js-node_mod-7ceeba.iframe.bundle.js:180051:18

It's rendering webpack's error overlay that causes the resolveOf issue? Maybe I am reading that wrong, React stacktraces are hard to understand.

[wintercounter]

It's there above (3rd picture): #21440 (comment)

It is not caused by Fast Refresh. I tried disabling it and still have the same problem. The issue I believe is that it was always expected that upon editing, Storybook gets the same module reference. I guess that's not the case and that's not handled.

If you want I open a new issue, I just thought to keep/re-open this maybe as it's the same error message, but it's a new issue indeed.

[tmeasday]

It's there above (3rd picture): #21440 (comment)

Sorry, I was hoping to see the value of this.exportToStory at that breakpoint.

The issue I believe is that it was always expected that upon editing, Storybook gets the same module reference. I guess that's not the case and that's not handled.

But it doesn't always happen, right? I mean it's never happened to me before :)

[wintercounter]

It's undefined, since it's a new module reference and the Map doesn't have that yet.

UPDATE:

Actually, the Map is completely empty.

Checked csfFiles in the constructor:

First load (working)

After it's broken, it becomes empty:

[tmeasday]

Hmm, so csfFiles is set in the prepare function via store.loadEntry:

storybook/code/lib/preview-api/src/modules/preview-web/render/MdxDocsRender.ts

Lines 65 to 69 in 07145b6

	const { entryExports, csfFiles = [] } = await this.store.loadEntry(this.id);
	if (this.torndown) throw PREPARE_ABORTED;
	this.csfFiles = csfFiles;
	this.exports = entryExports;

@wintercounter I wonder if you can put a logpoint in this function to see what the entry looks like on HMR:

storybook/code/lib/preview-api/src/modules/store/StoryStore.ts

Lines 264 to 270 in 07145b6

	const entry = await this.storyIdToEntry(id);
	const { importFn, storyIndex } = this;
	if (!storyIndex || !importFn) throw new Error(`loadEntry called before initialization`);
	const storyImports = entry.type === 'docs' ? entry.storiesImports : [];

We've had a user report an issue before where a docs entry somehow got turned into a story entry on HMR. I've no idea how that could happen but if that's happening here, I guess that'd lead to storyImports being []?