expose MantineHooks and MantineCore for use with custom components

[BSd3v]

Closes #641

To utilize in custom components, you need to place this in your webpack.config.js externals:

         '@mantine/core': {
            commonjs: '@mantine/core',
            commonjs2: '@mantine/core',
            amd: '@mantine/core',
            root: 'MantineCore', // This maps to window.MantineCore
        },
        '@mantine/hooks': {
            commonjs: '@mantine/hooks',
            commonjs2: '@mantine/hooks',
            amd: '@mantine/hooks',
            root: 'MantineHooks', // This maps to window.MantineHooks
        },

[BSd3v]

Once this is placed into the webpack.config.js:externals you can use the component like its inside the dmc library. No need to wrap in a MantineProvider.

You import like such:

const ManySelect = ({
  id,
  mantine,
}: Props & { mantine: any }) => {
  const {
    CheckIcon,
    Combobox,
    Group,
    Input,
    Pill,
    PillsInput,
    useCombobox,
  } = mantine;

...

export default function ManySelectLoader(props: Props) {
  const [mantine, setMantine] = useState<any>(null);

  useEffect(() => {
    import("@mantine/core").then(setMantine);
  }, []);

  if (!mantine) {
    return null;
  }

  return <ManySelect {...props} mantine={mantine} />;
}

This wrapper makes sure that the matine/core is loaded before trying to render. This helps with the lazy loading of the MantineProvider or the component suites being imported at the same time.

To avoid config issues, you should make sure that your versions of dmc and your custom component match with Mantine as this could cause issues with specific functionality.

[AnnMarieW]

Added MantineDates as well.

Total bundle size: dash_mantine_components.js (1.01 MiB)
Previous bundle size 984 KiB

[AnnMarieW]

Here is a sample DMC custom component project: https://github.com/AnnMarieW/dmc_custom_components

[alexcjohnson]

Sure, this makes sense to me. import("@mantine/core").then(...) doesn't actually trigger the loading of dash_mantine_components.js right? Do we know for sure (ie have we tested by deliberately slowing it down) that this waits for it to load? I guess we know for sure that it will have been triggered to load because your app will still use dmc.MantineProvider as the outer container, I just want to ensure we aren't setting up a flaky race condition due to the use of externals that might be loading at the same time.

How confident are you both that core, hooks, and dates are the only pieces people will want to use with this? If there are other big pieces they will request, we'll need a different pattern that somehow forwards chunk requests.

[BSd3v]

I did try to slow it down, and it seemed to work fine.

As far as other imports, I was thinking of wrapping specific (non-exposed to Dash) components to which you could expand and expose more components to the window. You pass the argument to the MantineProvider and then it would mount those components async.

[BSd3v]

Although, we did change the logic from this example, here is the updated version:

https://github.com/AnnMarieW/dmc_custom_components/blob/main/src/ts/utils/withMantine.tsx

It waits for the MantineProvider to load to the window object, so it never imports directly from the @mantine/core.

[alexcjohnson]

Hmph it's pretty annoying if everyone who wants to make custom components has to write their own withMantine - I was kind of hoping that would be handled automatically by import from externals. If there isn't a cleaner way to handle this we might consider publishing that as a little npm package. But that can be a separate task, this PR is still fine.

[BSd3v]

@AnnMarieW made the boilerplate to start from. 💯

[AnnMarieW]

Thanks for the PR @BSd3v and for the review @alexcjohnson 🎆