Import error with Material UI (X) components

[rhenkin]

Hi,
I'm trying to use the SimpleTreeView from https://mui.com/x/react-tree-view/getting-started/
I wrote a minimal markdown but it seems I can't even get past the import statement. I followed the MUI guide and installed some of the dependencies manually:
npm install @mui/material @emotion/react @emotion/styled
I understand there may be some version compatibility problems, but it's not clear at all to me if that's the case. I'm attaching the markdown, please note that I'm not installing the main packages manually, only the dependencies, but happy to try anything if you have any ideas. I also kept the Box component as it was part of the example.

simpletreetest.md

I'm using the latest framework version btw, I tested a simpler react component and also the "greetings" example in the docs and both are fine.

Thanks,
Rafael

[Fil]

If you install modules locally, you must remove the npm: prefix when you import them, otherwise Framework just fetches the resources from npm and ignores the modules that might be locally installed.

However this does not solve the issue: I've tried both approaches, npm: and node modules, and both seem to fail.

[mbostock]

I also wouldn’t recommend using node imports for React components currently, because currently Framework’s built-in React supports uses npm:react (not react) and it’s not configurable, so you’d end up with duplicate copies of React as it would be imported twice.

[mbostock]

It still doesn’t work, but the recommended way to do this now would be to use npm: imports instead of node imports. (When we support a configurable React engine #1465 then you could switch to node imports.) When using npm: imports, you don’t need to install anything, and the example code would look like this:

import Box from "npm:@mui/material/Box";
import {SimpleTreeView} from "npm:@mui/x-tree-view/SimpleTreeView";
import {TreeItem} from "npm:@mui/x-tree-view/TreeItem";

function FirstComponent() {
  return (
    <Box sx={{ minHeight: 352, minWidth: 250 }}>
      <SimpleTreeView>
        <TreeItem itemId="grid" label="Data Grid">
          <TreeItem itemId="grid-community" label="@mui/x-data-grid" />
          <TreeItem itemId="grid-pro" label="@mui/x-data-grid-pro" />
          <TreeItem itemId="grid-premium" label="@mui/x-data-grid-premium" />
        </TreeItem>
        <TreeItem itemId="pickers" label="Date and Time Pickers">
          <TreeItem itemId="pickers-community" label="@mui/x-date-pickers" />
          <TreeItem itemId="pickers-pro" label="@mui/x-date-pickers-pro" />
        </TreeItem>
        <TreeItem itemId="charts" label="Charts">
          <TreeItem itemId="charts-community" label="@mui/x-charts" />
        </TreeItem>
        <TreeItem itemId="tree-view" label="Tree View">
          <TreeItem itemId="tree-view-community" label="@mui/x-tree-view" />
        </TreeItem>
      </SimpleTreeView>
    </Box>
  );
}

display(<FirstComponent />);

But there are a couple challenges here.

First is that MUI brings in a fairly enormous tree of 105 dependencies. That dependency graph looks like this:

Second is that many of these packages (and many packages in the Node ecosystem in general) are not distributed as standard ES modules; they tend to be distributed as CommonJS packages that are only directly usable in Node.js, requiring transpilation to work in a browser. And hence Framework relies on jsDelivr (esm.run) to convert them into standard ES modules. And one of the problems here is that it isn’t always clear how to convert CommonJS modules into ES modules.

The error in the SimpleTreeView example code is:

TypeError: A is not a function

This is transpiled code which is a bit hard to read, but you can see the import of A here:

https://cdn.jsdelivr.net/npm/@mui/[email protected]/Box/index.js/+esm

And the imported A comes from here:

https://cdn.jsdelivr.net/npm/@mui/[email protected]/createStyled/+esm

We expect the default export of the above ES module to be a function. However, jsDelivr seems to have gotten confused, because the default export is a {default} object, wrapping the default export we want. You can see that by importing it directly:

import createStyled from "https://cdn.jsdelivr.net/npm/@mui/[email protected]/createStyled.js/+esm";

display(createStyled);

This should display a function, but instead it displays a {default} object. 😞

jsDelivr is likely confused because it’s using a built CommonJS module to create the ES module:

https://cdn.jsdelivr.net/npm/@mui/[email protected]/createStyled.js

Ironically, MUI does also provide an ES module version of this file, but it isn’t properly declared and so isn’t discoverable by jsDelivr:

https://cdn.jsdelivr.net/npm/@mui/[email protected]/esm/createStyled.js

esbuild describes the problem of default exports here:

https://esbuild.github.io/content-types/#default-interop

So, maybe it’s possible to get jsDelivr to workaround these issues in how MUI is packaged, but ideally MUI would adopt standard ES modules in its distribution and declare them using subpath or conditional exports in its package.json. Then downstream consumers wouldn’t try to uncompile the CommonJS modules and could use the ES module source directly.

[rhenkin]

Thanks for looking into this! When I was trying to figure out what could be wrong, I bumped into people having issues with MUI versions and issues with the style dependencies, so it already seemed messy even before getting into Framework.

Assuming I found the correct github issue, it looks like it will take some time for MUI to adopt the ES modules so I will look for other tree components.

[mbostock]

Thanks for your patience and the link. I’m glad the MUI team is looking into this. Hopefully the universal ES module future will be here eventually… 😅