[docs-infra] Support shared source between demos

[oliviertassinari]

What's the problem? 🤔

This is a continuation of #36498, mui/mui-x#10197, and #37222.

If we take https://mui.com/base-ui/react-button/ as an example, we duplicate a lot of code between each demo.

What are the requirements? ❓

What are our options? 💡

Proposed solution 🟢

What if we could share the same component source between many demos? We could have a shared source of truth, one that encapsulates the component logic, and then have the demos use them where relevant.

Demo https://mui.com/base-ui/react-button/#introduction would look something like this:

The Button would be defined in another tab

With these shared demos, we could at a later point in time create a CLI to allow developers to copy its source directly to their filesystem.

---

In the same way, we could update https://mui.com/material-ui/react-autocomplete/#combo-box to have datasets stored in a different tab. When using the general copy (not the local one) button, it should automatically concatenate the sources if the file type are compatible (.ts + .ts: yes, .ts + .css: no)

Resources and benchmarks 🔗

• Radix UI https://www.radix-ui.com/primitives/docs/components/progress

• Vuetify https://vuetifyjs.com/en/components/sheets/#color

• https://v7.mantine.dev/styles/responsive

[alexfauquette]

Charts use case

Currently, charts face a tradeoff between:

• having a short demo but then with little data (not realistic)
• having realistic charts but with long data in the code

Would be nice to be able to split the demonstration into two files: chart.tsx and data.tsx.

In a perfect world, those data file would not be duplicated. Like the data grid curretnly has 2 dataset used every where (comodity and employes) I could build data set like: financialResults.tsx, climateData.tsx, or populationData.tsx only once and reuse them in different demonstration

[danilo-leal]

Yeah, the same as Olivier described up there with the Autocomplete component. Another similar use case, again with Base UI, is having the same styles file shared across multiple demos. That way, we'd only need to maintain one file and not multiple as we do today. 🤙

I've removed the Base UI reference from the title and the label to make this issue a broader problem — not just something we want to do for one product only. There already are cases where Material UI and the MUI X components would benefit.

[LukasTy]

For the Pickers documentation, we have a few cases where this could really benefit the readability and code reusability.

1. In a lot of the demos we are using DemoContainer and DemoItem components that we author.
   It handles a consistent layout for various Pickers components. This approach proved problematic, because it's not really clear to the user, what this component does, what its intent is, and whether they should use it.
   Having the option to put this component into a tab could provide much-needed clarity in this regard.
2. In the shortcuts feature demonstrations we could put the shortcutItems array into a separate tab/file to separate the concerns.
3. In slot page we could extract the slot components into a separate tab.
4. In the custom field demonstration we could clearly benefit from having the option to extract and reuse the BrowserField and JoyField components to avoid repeating them in every demo.

[oliviertassinari]

I have forked a bit the problem into two:

1. [docs-infra] Support code tabs #39837 about the ability to have code tabs. Say to show the Tailwind CSS config used in the Base UI Tailwind CSS demos. This one is probably not functional end to end, but needed to pull off the next one:
2. [docs-infra] Support shared source between demos #38911 (here) about sharing the same source between demos, using code tabs, so depending on 1.