[docs-infra] Add GitHub source link to components

[Jay-Karia]

Adds a "Source" chip in component header links.
Chip links to their respective folder in packages/mui-material.

Note:

• The docs page for Progress components has LinearProgress and CircularProgress, the source chip can only link to one page, I have linked to LinearProgress
• Transfer List page does not have any Source chip, as I could not find any package for it.
• Base UI and MUI X components are not included.

Part of #36824

• I have followed (at least) the PR section of the contributing guide.

[mui-bot]

Netlify deploy preview

• docs/data/material/components/accordion/accordion.md
• docs/data/material/components/alert/alert.md
• docs/data/material/components/app-bar/app-bar.md
• docs/data/material/components/autocomplete/autocomplete.md
• docs/data/material/components/avatars/avatars.md

Bundle size report

No bundle size changes (Toolpad)
No bundle size changes

Generated by 🚫 dangerJS against 5e404a1

[Jay-Karia]

@aarongarciah Should we wait for failing CIs ?

[alexfauquette]

Thanks for the contribution. Effectively, it's a quick win.

I removed the autocolosing because the issue is about API pages. In that case the link should ba done by a script. Otherwise, it would be hard to keep something up to date.

I'm modifying the way to define the path. The URL of the repo and the current branch are left to the config. The markdown only have the take care of the file path. Such that when releasing the new major, this feature does not require extra modifications

[alexfauquette]

I left this PR open if someone want to give a second look at my modification. Otherwise I will mere it during at the end of the week

[bharatkashyap]

Looks good to me, the only suggestion is if we want to relook at the order of the chips, and move the GitHub source one to be the first or second to indicate its priority.

[Jay-Karia]

Should we close #36824 after merge ?

[alexfauquette]

Should we close #36824 after merge ?

Answered in #43228 (comment)

TLTR; no ;)

I removed the autocolosing because the issue is about API pages. In that case the link should be done by a script. Otherwise, it would be hard to keep something up to date.

[oliviertassinari]

Are we sure about this change? It feels a bit strange in two ways:

1. The links to the source are hardcoded. Isn't there room to automatically generate them, as we do for the link to the API?
2. I'm a bit confused about the UX, a source to a component from the component demo page doesn't make a lot of sense to me as a user. Sometimes it works (simple one-component demo page), some other times it doesn't. I would expect to see this link from each API page.

[oliviertassinari]

This link we break once we version the docs pages: Why not do the same thing as with the link to the source for the demos?

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

Line 132 in 4b31d50

githubLocation={`${process.env.SOURCE_CODE_REPO}/blob/v${process.env.LIB_VERSION}${fileNameWithLocation}`}

[alexfauquette]

Was not aware of this part of the code

[oliviertassinari]

Alright, then I assume we can move to do the same 😄

[alexfauquette]

Are we sure about this change?

1. About generating the links. I don't think since some pages have multiple components. It would require to define a way to pick one of them
2. About the UX for me those chips are entry points to additional documentation (the WARAI spec, the material design spec) In that context the source is an entry point to where components are. I see that more like a junior friendly introduction to the source code.

About having links in API pages, I agree it would be more reliable and could be automated.

For me they solve different issues:

• I'm on the API page because. I'm looking for something specific. Then I need to read the code of the actual component
• I'm on the Demo page. I'm looking for something general. Just knowing where components are defined is good enough for my purpose

[oliviertassinari]

1. About generating the links. I don't think since some pages have multiple components. It would require to define a way to pick one of them

@alexfauquette Maybe we could have a default logic that picks the first component listed in the components: field, and still allow people to manually specify a custom one?

2. I see that more like a junior friendly introduction to the source code.

Would it be better if we were to only show the action if there is a single entry in the components: field? I don't know, when I land on https://deploy-preview-43228--material-ui.netlify.app/material-ui/react-accordion/ and click on Source, I was expecting to see the source of the whole component. Only seeing the root component confuses me.

@colmtuite I'm curious about your view on this. https://www.radix-ui.com/primitives/docs/components/switch has a link to the source, which makes sense in this context and in the context of Base UI because of how the sources are organized: https://github.com/mui/base-ui/tree/master/packages/mui-base/src/Menu. We basically say to the developers, that if you import a Menu, you won't get tree shaking in dev mode for the menu components that you don't use.