[docs] Able to load doc components inside markdown files

[flaviendelangle]

Follow up on #26774
Fixes this TODO:

material-ui/docs/src/modules/components/MarkdownDocs.js

Line 14 in adda22c

// TODO: Only import on demand via @mui/markdown/loader

I want to use the {{ "component" }} synthax on MUI-X to inject some new components.
But I can't because the light of available components is hardcoded in this repository.

• In the Markdown loader, add a new srcComponents (better name) export that contains the custom components for the current page
• In MarkdownDocs render the custom components using srcComponents
• Modify all the files using the markdown loader to spread the props instead of defining them one by one (I had to add one for the components and it's a pain was there a reason not to spread before ?)
• Test that I can now import custom components from MUI-X ([docs] Use components instead of demos for SelectorsDocs mui-x#6103)

https://deploy-preview-34243--material-ui.netlify.app/material-ui/react-button/

[mui-bot]

No bundle size changes

Generated by 🚫 dangerJS against c4ee119

[siriwatknp]

@flaviendelangle If my understanding is correct, you want to reuse the component with default props right? The benefit of the new approach is to reduce the demo files, are there other benefits to this?

---

My comment about the usage:

// From
{{"component": "modules/components/SelectorsDocs.js", "category": "Visible Columns"}}

// To
{{"component": "modules/components/SelectorsDocs.js", "props": { "category": "Visible Columns" }}}

I rather group the properties under "props" to avoid props overriding.

[flaviendelangle]

@siriwatknp

Concerning the way we pass props, I kept the synthax used for ComponentLinkHeader

{{"component": "modules/components/ComponentLinkHeader.js", "design": false}}

But if we want to change the signature for something more explicit, that's fine for me.
And I agree that being explicit is probably better here.

---

The benefit of the new approach is to reduce the demo files, are there other benefits to this?

I have two main reasons

1. For coherence: We have a way of rendering components with the {{"component"}} syntax, but it is only usable for ComponentLinkHeader, which is weird.
   When I arrived at MUI, I had a hard time understanding the logic being those syntaxes. Sometime we have {{"component"}}, sometime {{"demo"}} leading to a 2 lines JS file calling a component.

2. I have a use case where the demo approach is painful. I would like to render a small table on some doc page with the signature of 1-2 props (the one explained in the same section).
   And it would force me to create a lot of small demo, with a NoSnap suffix to avoid having snapshots of it in our regressions tests.

Something like

{{ "component": "modules/components/PickerValidationPropTable.js", "props: { "propNames": ["shouldDisableMonth"] }}

[flaviendelangle]

@oliviertassinari @siriwatknp if you can take a look

[oliviertassinari]

It looks fair enough

[oliviertassinari]

Would it be better with?

Suggested change

	<MarkdownDocs {...pageProps} />
	<MarkdownDocs pageProps={pageProps} />

My concern is about how can we help the future developers to find where these props are coming from.

[flaviendelangle]

My main problem is that it was a major pain to add a new prop on all those files because it was not spread.
And it's very easy to forget one file and have missing content that will be hard to spot.

And I don't see how the current version solves this: help the future developers to find where these props are coming from
If I want to know what is passed to MarkdownDocs, I can check the props it receives.
The hard part when I tried to understand how everything works was to find the loader.js file, which took me some time.

[siriwatknp]

I agree with @flaviendelangle, the MarkdownDocs is the only component that connects to the {{ }} format anyway. I don't see why we need to pass props as pageProps.

[oliviertassinari]

The only value would be about making how props drill down a bit more explicit. Spreading tends to hide the actual structure of the props that the component receives. If this argument doesn't resonate, then please ignore my initial comment.

[flaviendelangle]

OK I misread your comment, I thought you wanted to keep today's signature.
No strong opinion between your proposal and mine then.

[siriwatknp]

👍 LGTM