[docs] Add redirects for MUI X v6

[m4theushw]

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

Preview: https://deploy-preview-6374--material-ui-x.netlify.app/x/react-data-grid/
Preview: https://deploy-preview-34296--material-ui.netlify.app/

I created this PR to change the default version shown when visiting a X page. Now it will show v6... by default in the dropdown below, and v5 will be the 2nd option. This can't be seen in the preview because I first need to merge this PR and upgrade the monorepo in the X repo.

I also removed all other pages and added a redirect back to the stable docs. I don't want to have https://mui.com/material-ui/getting-started/overview/ and https://next.mui.com/material-ui/getting-started/overview/. After this PR is merged I'll open another one adding the v6 option in master.

[mui-bot]

No bundle size changes

Generated by 🚫 dangerJS against 91429e8

[oliviertassinari]

@m4theushw This git diff is very large, it's hard to review. Adding an ! should remove the need to remove all the pages. It tells Netlify to ignore the existing html pages.

/* https://mui.com/:splat 301!

[docs] Add menu option for MUI X v6

Also, the title of this PR confuses me. I don't see why the JavaScript code of the next branch should have edits. I assume that we need to do this:

• Update the Netlify configuration to host the v6 of MUI X on the next subdomain. This impacts the next branch here because it owns https://next.mui.com/ routings.
• Have links on https://next.mui.com/x/ that don't point to MUI X to redirect back to https://mui.com/. This impacts the next branch here because it owns the domain routing.
• Update the docs infrastructure to be able for MUI X next branch and MUI X master branch to add their own navigation in the version side nav. This impacts the master branch here because it's owns the latest version of the docs and code infra that MUI X v5 and v6 should use.

Hence I assume that the changes in the next branch we talked get here should only be about HTTP routes.

[m4theushw]

Adding an ! should remove the need to remove all the pages. It tells Netlify to ignore the existing html pages.

@oliviertassinari I didn't know about !. I re-added the pages.

I don't see why the JavaScript code of the next branch should have edits.

We need to change the docs/src/modules/components/AppNavDrawer.js component to add the new option. We don't duplicate this component in the X repo.

Update the docs infrastructure to be able for MUI X next branch and MUI X master branch to add their own navigation in the version side nav.

This is not the point of this PR but it can be done in the future. It's a more complex task to read the options from next.config.js and build the menu.

I'll also open a PR targeting master to only add a generic v6 option in the sidebar redirecting to https://next.mui.com/x/react-data-grid. My idea is:

When accessing https://mui.com/x/react-data-grid/ the options in the sidebar will be:

• v6 goes to https://next.mui.com/x/react-data-grid/
• v5.x.x (selected by default)
• v4 goes to https://v4.mui.com/components/data-grid/

When accessing https://next.mui.com/x/react-data-grid/ the options in the sidebar will be:

• v6.0.0-alpha.x (selected by default)
• v5 goes to https://next.mui.com/x/react-data-grid/
• v4 goes to https://v4.mui.com/components/data-grid/

[oliviertassinari]

I assume it should be?

Suggested change

	/x/react-data-grid/* https://docs-next--material-ui-x.netlify.app/x/:splat 200
	/x/api/data-grid/* https://docs-next--material-ui-x.netlify.app/x/:splat 200
	/x/* https://docs-next--material-ui-x.netlify.app/x/:splat 200

[oliviertassinari]

What is this line for? I assume this would be enough:

Suggested change

{ text: 'v5', href: `https://mui.com${languagePrefix}/components/data-grid/` },

I don't understand the previous argument used:

We need to change the docs/src/modules/components/AppNavDrawer.js component to add the new option. We don't duplicate this component in the X repo.

MUI X (v5, v6) is using and should be using the master branch of the mono repo for its code and docs infra, so I fail to understand how it has an impact.

[m4theushw]

If I remove this line users won't have a link for the v5 version if they access a v6 page.

MUI X (v5, v6) is using and should be using the master branch of the mono repo for its code and docs infra, so I fail to understand how it has an impact.

It's related to why we can't remove the line above. When accessing https://next.mui.com/x/react-data-grid/ the menu will show v6-alpha.x, v5 and v4, and in https://mui.com/x/react-data-grid/ it will contain v6, v5.17.4 and v4. MUI X v5 will use the master branch of the monorepo, while v6 will use the next branch because I don't have the v6 version in the master branch of the MUI X repo to use here. It comes from package.json.

[oliviertassinari]

@m4theushw I think that as much as we can, there should be a single version of @mui/monorepo (docs infra + code infra). The value is that fixes done to it like #34619 don't need to be cherry-picked on two different versions (next and master).

Now, if we assume that we have this as a constraint for the solution, then the option that seems to be the best is to continue in the direction that we started to serve the docs infra as a standalone product. This means, if we were using https://docusaurus.io/, we wouldn't go to docusaurus repo to open a PR to ask to update the versions. We would use the API it exposes to do such, I think we should do the same with all the docs that rely on the docs-infra.

[m4theushw]

I created mui/mui-x#6374 to demonstrate how this PR will work in production. See https://deploy-preview-6374--material-ui-x.netlify.app/x/react-data-grid/

We'll need to find a solution for

cc @danilo-leal

[oliviertassinari]

@m4theushw Thanks for the demo. From what I can see, mui/mui-x#6374 is based on https://github.com/mui/material-ui.git#master + #34296 but this PR is on the next branch, not the master branch. So I think that we should:

1. Solve the HTTP routing issue. Revert the changes in docs/src/modules/components/AppNavDrawer.js of this PR and merge.
2. Solve the HTML display issue. Have the versions in the side nav injected from https://github.com/mui/mui-x and not come from https://github.com/mui/material-ui in any way. I believe the pages that are on the side nav of MUI X are coming from the MUI X repository and not Material UI repository. This is better for reducing the coupling.

At the same time of 2, I think that we could look into the version displayed.

It looks confusing, MUI X is on v5.17.2, the actual version of the date picker is not that much important as it's eventually the version of MUI X.

[siriwatknp]

Can the layout be something like this? so that we don't have to deal with the text-overflow in the future. cc @danilo-leal

[oliviertassinari]

@siriwatknp On this one, I wonder if the root of the problem isn't that the side nav header was built for the cases of a product family that has sub-products. But it doesn't work with a standalone product, e.g. MUI Toolpad:

https://mui.com/toolpad/getting-started/installation/. I think that it would work better with Toolpad only displayed once.

In the case of MUI X, It's not clear to me if we should show "Date pickers" in the header. I think that we have eventually a lot more components to build in MUI X: Tree View, File Upload, Carousel, Scheduler, Sparkline, Window Splitter, Rich Text Editor, Cascader Select, Tour, Tree Select, Charts, Signature. It could look like this:

and maybe:

• remove the all uppercase to teach people the right capitalization of the product
• use the MUI X/MUI Toolpad/etc. logos rather than MUI company logo

[m4theushw]

I reverted the changes in docs/src/modules/components/AppNavDrawer.js and kept only the redirects.

Solve the HTML display issue. Have the versions in the side nav injected from https://github.com/mui/mui-x and not come from https://github.com/mui/material-ui in any way.

@oliviertassinari The specific version v5.x.x is already coming from https://github.com/mui/mui-x. But the available major versions, e.g. v5 and v4, come from https://github.com/mui/material-ui. To solve that the X repo will have to recreate the page structure to replace the AppNavDrawer available in the monorepo with a custom one.

[oliviertassinari]

To solve that the X repo will have to recreate the page structure to replace the AppNavDrawer available in the monorepo with a custom one.

@m4theushw We started to cover the topic a bit in https://www.notion.so/mui-org/Scaling-docs-infra-to-more-teams-f8f2322f5a95436ab23044c3a939840b#36a08a48b8b949238f93f1566443545a when Andrew needed to update the same component. I think that it depends on the level of abstraction of the API that we want to expose in the docs-infra. We could use https://nextra.vercel.app/get-started as inspiration. For example, it could look like this:

diff --git a/docs/pages/_app.js b/docs/pages/_app.js
index 9e157c4505..c12ad0ed76 100644
--- a/docs/pages/_app.js
+++ b/docs/pages/_app.js
@@ -171,6 +171,20 @@ Tip: you can access the documentation \`theme\` object directly in the console.
     'font-family:monospace;color:#1976d2;font-size:12px;',
   );
 }
+
+function AppNavDrawerHeader() {
+  return (
+    <ProductIdentifier
+      name="MUI X"
+      metadata="MUI X"
+      versionSelector={renderVersionSelector([
+        { text: `v${process.env.DATA_GRID_VERSION}`, current: true },
+        { text: 'v4', href: `https://v4.mui.com${languagePrefix}/components/data-grid/` },
+      ])}
+    />
+  );
+}
+
 function AppWrapper(props) {
   const { children, emotionCache, pageProps } = props;

@@ -219,7 +233,7 @@ function AppWrapper(props) {
         <LanguageNegotiation />
         <CodeCopyProvider>
           <CodeVariantProvider>
-            <PageContext.Provider value={{ activePage, pages: productPages }}>
+            <PageContext.Provider value={{ activePage, pages: productPages, AppNavDrawerHeader }}>
               <ThemeProvider>
                 <DocsStyledEngineProvider cacheLtr={emotionCache}>
                   {children}

which MUI X can inject: https://github.com/mui/mui-x/blob/b8841eada5582cac03e3aa4b97711bf8f0719513/docs/pages/_app.js#L261. And on this repository:

diff --git a/docs/src/modules/components/AppNavDrawer.js b/docs/src/modules/components/AppNavDrawer.js
index cd3452bd1c..058846ce94 100644
--- a/docs/src/modules/components/AppNavDrawer.js
+++ b/docs/src/modules/components/AppNavDrawer.js
@@ -281,7 +281,7 @@ const iOS = typeof navigator !== 'undefined' && /iPad|iPhone|iPod/.test(navigato

 export default function AppNavDrawer(props) {
   const { className, disablePermanent, mobileOpen, onClose, onOpen } = props;
-  const { activePage, pages } = React.useContext(PageContext);
+  const { activePage, pages, AppNavDrawerHeader } = React.useContext(PageContext);
   const router = useRouter();
   const [anchorEl, setAnchorEl] = React.useState(null);
   const userLanguage = useUserLanguage();
@@ -391,6 +391,7 @@ export default function AppNavDrawer(props) {
               <SvgMuiLogo width={30} />
             </Box>
           </NextLink>
+          <AppNavDrawerHeader />
           {canonicalAs.startsWith('/material-ui/') && (
             <ProductIdentifier
               name="Material UI"
@@ -440,32 +441,6 @@ export default function AppNavDrawer(props) {
               ])}
             />
           )}
-          {canonicalAs.startsWith('/x/introduction/') && (
-            <ProductIdentifier name="Advanced components" metadata="MUI X" />
-          )}
-          {(canonicalAs.startsWith('/x/react-data-grid/') ||
-            canonicalAs.startsWith('/x/api/data-grid/')) && (
-            <ProductIdentifier
-              name="Data Grid"
-              metadata="MUI X"
-              versionSelector={renderVersionSelector([
-                // DATA_GRID_VERSION is set from the X repo
-                { text: `v${process.env.DATA_GRID_VERSION}`, current: true },
-                { text: 'v4', href: `https://v4.mui.com${languagePrefix}/components/data-grid/` },
-              ])}
-            />
-          )}
-          {(canonicalAs.startsWith('/x/react-date-pickers/') ||
-            canonicalAs.startsWith('/x/api/date-pickers/')) && (
-            <ProductIdentifier
-              name="Date pickers"
-              metadata="MUI X"
-              versionSelector={renderVersionSelector([
-                // DATE_PICKERS_VERSION is set from the X repo
-                { text: `v${process.env.DATE_PICKERS_VERSION}`, current: true },
-              ])}
-            />
-          )}
           {canonicalAs.startsWith('/toolpad/') && (
             <ProductIdentifier name="Toolpad" metadata="MUI Toolpad" />
           )}

[m4theushw]

@oliviertassinari We can go further and remove from AppNavDrawer the role of building the options. This could be injected by each _app.js. Each _app.js doesn't need to provide their custom component, only the options. I'll make a proposal.

[cherniavskii]

Shouldn't it be 302 instead of 301? This redirect is temporary and will be removed as soon as we start working on the core v6

[oliviertassinari]

Yeah, makes sense. In

$ curl -I https://next.mui.com/material-ui/react-alert/
HTTP/2 301

we could expect a 302.

[cherniavskii]

Addressed in #36296