MDX linkings should not rely on the remark-slug plugin to generate slug for headers

[patricklafrance]

Is your feature request related to a problem? Please describe.
The current version of MDX linkings rely on the remark-slug plugin to generate the slugs for headers:

<h1 id="supported-platforms" class="sbdocs sbdocs-h1 css-1j28tt">

There is a few issues with this approach:

• The plugin doesn't handle MDX dynamic expression:

The following dynamic expression ## <Fragment children={props.title} /> result in the following slug:

<h2 id="fragment-childrenpropstitle-" class="sbdocs sbdocs-h2 css-1lg570m">

• Since remark-slug is an MDX plugin, it can't be used for DocsPage.

Describe the solution you'd like
SB should develop a set of <Header /> components that will take care of rendering the header element and generate the appropriate slug.

These components could be used for DocsPage and also as custom MDX components for MDX linkings.

[kevin940726]

Looks like we already have a set of components like in

storybook/addons/docs/src/blocks/mdx.tsx

Lines 185 to 202 in da303c5

	export const HeaderMdx: FC<HeaderMdxProps> = props => {
	const { as, id, children, ...rest } = props;
	// An id should have been added on every header by the "remark-slug" plugin.
	if (id) {
	return (
	<HeaderWithOcticonAnchor as={as} id={id} {...rest}>
	{children}
	</HeaderWithOcticonAnchor>
	);
	}
	// @ts-ignore
	const Header = components[as];
	// Make sure it still work if "remark-slug" plugin is not present.
	return <Header {...props} />;
	};

So now we need to slugify the text content into id? Since the content is evaluated in run time, how should it suppose to do that 🤔?

[shilman]

We’re cleaning house! Storybook has changed a lot since this issue was created and we don’t know if it’s still valid. Please open a new issue referencing this one if this is still relevant in SB 7.x.