[pickers] Unexpected token 'export' error when using @mui/x-date-pickers/internals/demo/DemoContainer

[yalinn]

Steps to reproduce 🕹

I tried this example with nextjs 12.3.4

Current behavior 😯

page doesn't load and gives an error

Expected behavior 🤔

A date-picker component

Context 🔦

I see error in below:

Your environment 🌎

npx @mui/envinfo ountput:

System:
    OS: Windows 10 10.0.22621
  Binaries:
    Node: 18.17.0 - C:\Program Files\nodejs\node.EXE
    Yarn: 1.22.19 - ~\AppData\Roaming\npm\yarn.CMD
    npm: 9.7.2 - C:\Program Files\nodejs\npm.CMD
  Browsers:
    Chrome: Not Found
    Edge: Spartan (44.22621.2283.0), Chromium (117.0.2045.36)
  npmPackages:
    @emotion/react: ^11.11.1 => 11.11.1
    @emotion/styled: ^11.11.0 => 11.11.0
    @mui/base:  5.0.0-beta.16
    @mui/core-downloads-tracker:  5.14.10
    @mui/lab: ^5.0.0-alpha.145 => 5.0.0-alpha.145
    @mui/material: ^5.14.10 => 5.14.10
    @mui/private-theming:  5.14.10
    @mui/styled-engine:  5.14.10
    @mui/system: ^5.14.10 => 5.14.10
    @mui/types:  7.2.4
    @mui/utils: ^5.14.10 => 5.14.10
    @mui/x-data-grid: ^6.15.0 => 6.15.0
    @mui/x-date-pickers: ^6.15.0 => 6.15.0
    @mui/x-tree-view:  6.0.0-alpha.1
    @types/react: 18.0.8 => 18.0.8
    react: 18.2.0 => 18.2.0
    react-dom: 18.2.0 => 18.2.0
    typescript: 4.6.4 => 4.6.4

tsconfig.json:

{
  "compilerOptions": {
    "baseUrl": ".",
    "rootDir": "src",
    "target": "es6",
    "lib": [
      "dom",
      "dom.iterable",
      "esnext"
    ],
    "allowJs": true,
    "noImplicitAny": false,
    "skipLibCheck": true,
    "strict": true,
    "forceConsistentCasingInFileNames": true,
    "noEmit": true,
    "esModuleInterop": true,
    "module": "esnext",
    "moduleResolution": "node",
    "resolveJsonModule": true,
    "isolatedModules": true,
    "jsx": "preserve",
    "incremental": true,
    "paths": {
      "apexcharts": [
        "./node_modules/apexcharts-clevision"
      ],
      "apexcharts/*": [
        "./node_modules/apexcharts-clevision/*"
      ],
      "@core/*": [
        "./src/@core/*"
      ],
      "@components/*": [
        "./src/@core/components/*"
      ],
      "@services/*": [
        "./src/services/*"
      ],
    }
  },
  "include": [
    "src",
    "node_modules/@types"
  ],
  "exclude": [
    "node_modules"
  ]
}

Order ID or Support key 💳 (optional)

No response

[oliviertassinari]

I think this was raised in the past, @mui/x-date-pickers/internals/demo is not a possible import path:

https://mui.com/material-ui/guides/minimizing-bundle-size/#option-one-use-path-imports.

We could have @mui/x-date-pickers/internals-demo instead to solve this. This feels like a quick win.

---

I tried this example with nextjs 12.3.4

What's the use case for <DemoContainer> here? It feels like we can simply remove it: simpler, and less overwhelming for a new developer.

---

In https://github.com/mui/mui-x/pull/7900#issuecomment-1431680209 I made the case to break down <DemoContainer> which feels one level of abstraction too high.

I think that the main problem today is that we can't really iterate on DemoContainer, it's used in so many places and depends on screen width that it's so easy to regress more than move forward.

I could see a DemoContainer that has no notion of padding or width but only covers overflow: auto (if we decide that it's not the docs-infra place to host it, which can make sense if we want to spot issues) and some helpers to label.

[alexfauquette]

The <DemoContainer /> is an internal tool used with <DemoItem /> to show multiple components in a demo without having to add layout components (Box, Stack`, ...) such that:

• The layout code is as small as possible to let the reader focus on what matters (the component)
• The layout is consistent across all the demonstration

So the import does not work, and that's good because you are not supposed to import it 😁 Does removing it solves your issue?

@flaviendelangle Is there a reason why basic demo have those container? For demo with multiple components, I assume devs read the code to copy past only the component they want. But for basic usacase, I can understand the whish to copy past and get something working

[LukasTy]

Is there a reason why basic demo have those container? For demo with multiple components, I assume devs read the code to copy past only the component they want. But for basic usacase, I can understand the whish to copy past and get something working

The DemoContainer adds some logic even in the most basic examples - like the minWidth property on the TextField. This is not very evident on the DatePicker examples, especially now, but will become more apparent when we will have the clearable examples. 🤔 If I recall correctly, I was and still am in favor of simplicity over abstraction. All the lessons that we've learned and issues that we've seen during v6, sort of prove this point.

We could aim to hide certain components in the code previews instead, to minimize the noise, until the code is expanded. In regards to the overflow, yeah, I'd agree that having it applied globally on the docs-infra level would probably be most appropriate. 🤔

[flaviendelangle]

Same topic as https://github.com/mui/mui-x/issues/10106, maybe the JSDoc is not explicit enough

[alexfauquette]

After discussion, we found an alternative solution to keep at the same time clarity of the demonstration content, and the transparency about what are those containers.

Using multiple files in the demonstration:

• main.tsx
• DemoContainer.tsx
• DemoItem.tsx

This would require to fix this issue in docs-infra: https://github.com/mui/material-ui/issues/38911