[docs] Allows to customize menu with any icon

[alexfauquette]

Allows to user to chose any icon (tested in mui-x here: mui/mui-x#8148)

[mui-bot]

Netlify deploy preview

https://deploy-preview-36408--material-ui.netlify.app/

Bundle size report

No bundle size changes

Generated by 🚫 dangerJS against f564142

[oliviertassinari]

The visual design of the icon looks fair.

Regarding the API, I'm not sure, it feels like a leaky abstraction of the docs-infra. We are now bundling the charts icon for all the products, and we have to update the docs-infra for using a new nonstandard icon. Supporting this could make sense:

import type { MuiPage } from '@mui/monorepo/docs/src/MuiPage';
import TableViewRoundedIcon from '@mui/icons-material/TableViewRounded';

const pages: MuiPage[] = [
  {
    pathname: '/x/introduction-group',
    title: 'Introduction',
    icon: 'DescriptionIcon', // Standard
    children: [
      { pathname: `/x/introduction`, title: 'Overview' },
      { pathname: `/x/introduction/installation` },
      { pathname: `/x/introduction/licensing` },
      { pathname: `/x/introduction/support` },
      { pathname: `/x/introduction/roadmap` },
    ],
  },
  {
    pathname: '/x/react-data-grid-group',
    title: 'Data Grid',
    icon: TableViewRoundedIcon, // Custom
    children: [

[oliviertassinari]

#36789 is another reason why to make the icons configurable.

[siriwatknp]

I am afraid that this could lead to inconsistency if someone forgets to change the icon on other pages (Material UI, Joy UI, and Base UI follow the same structure). I think it makes more sense for the core pages to reuse the same icons.

[flaviendelangle]

Could we export the "standard page icons" from a doc file ?
Something like

import { DescriptionIcon } from '../some/endpoint/doc-pages-icons';

[alexfauquette]

I moved to a solution where AppNavIcons.ts exports the object of icons available. and pages use this object.

For core pages, it means the following diff

- icons: "DescriptionIcon",
+ icons: standardNavIcons.DescriptionIcon,

So you still have a centralized list of standard icons. It's simpler to modify thanks to TS autocomplete, and others can still have access to those icons

[siriwatknp]

Nice initiative! I have one comment related to sharing icons for the core.

[oliviertassinari]

There is a warning in the console:

Maybe to discourage the use of the string API:

diff --git a/docs/src/modules/components/AppNavDrawerItem.js b/docs/src/modules/components/AppNavDrawerItem.js
index b673cbfe92..ead7c9aac5 100644
--- a/docs/src/modules/components/AppNavDrawerItem.js
+++ b/docs/src/modules/components/AppNavDrawerItem.js
@@ -285,7 +285,7 @@ AppNavDrawerItem.propTypes = {
   comingSoon: PropTypes.bool,
   depth: PropTypes.number.isRequired,
   href: PropTypes.oneOfType([PropTypes.string, PropTypes.object]),
-  icon: PropTypes.string,
+  icon: PropTypes.elementType,
   legacy: PropTypes.bool,
   linkProps: PropTypes.object,
   newFeature: PropTypes.bool,

or if we want to support both types

diff --git a/docs/src/modules/components/AppNavDrawerItem.js b/docs/src/modules/components/AppNavDrawerItem.js
index b673cbfe92..0806dcd5c8 100644
--- a/docs/src/modules/components/AppNavDrawerItem.js
+++ b/docs/src/modules/components/AppNavDrawerItem.js
@@ -285,7 +285,7 @@ AppNavDrawerItem.propTypes = {
   comingSoon: PropTypes.bool,
   depth: PropTypes.number.isRequired,
   href: PropTypes.oneOfType([PropTypes.string, PropTypes.object]),
-  icon: PropTypes.string,
+  icon: PropTypes.oneOfType([PropTypes.string, PropTypes.elementType]),
   legacy: PropTypes.bool,
   linkProps: PropTypes.object,
   newFeature: PropTypes.bool,