storybook: [Bug]: Unable to use Description without a Story in MDX

I browsed the docs for 7.0 and got an impression that it’s totally possible to use doc blocks in documentation-only mdx pages, but then run into this issue 😢 Would be a really useful feature, looking forward to it!

In 7.0.0-beta.8, I also have a similar error but this time related to the <Canvas> component. Based on the doc here, I should be able to use the folowing without issue.

import { Meta, Canvas } from '@storybook/addon-docs';

<Meta title="Documentation/Foundations/Color" />

<Canvas>
  <h2>Some here</h2>
</Canvas>

I’m running into this issue again with Canvas after upgrading to Storybook 8.

I’m just trying to wrap a piece of JSX in a Canvas inside a documentation-only MDX file. I’ve tried importing Canvas and Meta from @storybook/addon-docs and from @storybook/blocks (I tried all possible import combinations) but in all cases I get the same error: “No primary story defined for docs entry. Did you forget to use <Meta>?”. Same if I don’t use Meta at all and let the title be inferred from the first heading.

Thanks for the update! I upgraded my project to beta.25 and it seems to have fixed Description. However I’m still seeing the original error for ArgsTable, Source, and Canvas. Are there plans to fix these components as well?

Thanks @mdaoust-sidlee, I’ve fixed it in #20803, should be released in the next couple of days.

Seems to work fine for Title but not for Subtitle yet. Stacktrace still shows storyById is called from the Subtitle2 component.

import { Meta, Title, Subtitle } from '@storybook/blocks';

<Meta title='Introduction' />
<Title>Title test</Title>
<Subtitle>Sub title test</Subtitle>

Error: No primary story defined for docs entry. Did you forget to use `<Meta>`?

@JReinhold using doc blocks in docs-only mdx files works great, the only caveat that i have run into is that you cannot import stories in .mdx docs-only files using the webpack aliases you defined in main.ts.

Something like this in a .mdx file:

import * as ComponentStories from '../../components/src/Component/Component.stories';

<Canvas of={ComponentStories.Default} />

will render correctly, while this:

import * as ComponentStories from '@components/Component/Component.stories';

<Canvas of={ComponentStories.Default} />

will fail with 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

A little debug reveals that with the second scenario csfFiles passed to DocsContext is empty and then resolveOf throws.

The aliases itself are resolved because i can console.log in the mdx files the imported stories definitions, the problem is that exportsToCSFFile map is simply empty in DocsContext when using these aliases.

Did i run into some known limitation or is it a problem with my setup and you would need a reproduction from me?

For someone still face the problem Did you forget to use <Meta>?, place Meta tag before other tags like Title, Primary 😂

@JReinhold yes. I looked into doing that first, but I wanted it to look the same as the actual canvases I used. And looking at the code, there’s quite a bit involved in getting the same style as the builtin blocks:

• https://github.com/storybookjs/storybook/blob/next/code/ui/blocks/src/components/BlockBackgroundStyles.tsx#L3
• https://github.com/storybookjs/storybook/blob/next/code/ui/blocks/src/components/Preview.tsx#L51

I guess what I really would want is a block that has this “preview” view, as just a simple styled component.

@JReinhold it’s mostly a visual thing. What we have currently is this:

## Sizes

<Canvas>
	<Story name="Large">
		<Button>Large button</Button>
	</Story>
	<Story name="Small">
		<Button size="small">Small button</Button>
	</Story>
</Canvas>

which renders as following:

While also producing 2 stories. I use the same pattern multiple places:

I mostly just care about the border/look of the Canvas, not the source and features like that - so I’d be completely OK with not using Canvas but something else. It would be even better if that “something” had unstyled set on it.

The last example I have is this:

<Canvas withSource="none">
	<Unstyled>
		<H1>H1 - Heading - Overskrift</H1>
		<H2>H2 - Form title - Skjematittel</H2>
		<H3>H3 - Section title - Grupperingstittel</H3>
		<H4>H4 - Form elements title - Tittel over skjemafelter</H4>
		<P>Txt - Body text - Brødtekst</P>
		<Span>Txt - Unstyled text</Span>
	</Unstyled>
</Canvas>

This more or less shows what I really want. The “look” of a canvas, with no storybook styling inside, and then showing multiple stories in that “box”. In this case:

I’d love to hear which use cases you have for having multiple stories in a single canvas

Showing all the variants of a small component (e.g. a button) in a summary view at the top of a document.

Did i run into some known limitation or is it a problem with my setup and you would need a reproduction from me?

The issue here will be that we need to interpret that import in the story indexer (which reads your MDX file statically). I’m not sure it is feasible for it to understand things like aliases. WDYT @shilman?

@JReinhold does that mean you can no longer do multiple stories in one canvas?

Still no luck with 7.0.0-beta.34. I still encounter the following error when I try to use the following mdx file :

import { Meta, Canvas } from '@storybook/addon-docs';

<Meta title="Documentation/Foundations/Color" />

<Canvas>
  <h2>Some here</h2>
</Canvas>

Ahh, so are you using <Source code="..." /> in an unattached docs file (i.e plain .mdx file) @dryton? I think this is a bug for sure, I’ll open a new ticket for it.

We’ve finished migrating all the blocks to the new API, so this should be fixed.

We’ve changed the API for many of the blocks (with deprecation warnings), we’re not ready with the new docs for them, but in the mean time you can check the migration notes which should give a sense of the changes.

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

npx sb@next upgrade --prerelease

Closing this issue. Please re-open if you think there’s still more to do.