Caveats about MDXProvider

[lannonbr]

In the docs, there's mention of both pulling in components in individual MDX files with import statements as well as putting them into the MDXProvider which will then expose them to all MDX pages. Something I've been thinking about is a possible anti-pattern of putting everything in the MDXProvider, as if you are using a component only on one or two MDX files, then for the rest of the site, those files would be possibly part of a bundle or the module dependency tree of any page that uses the MDXProvider.

I think it could be useful to possibly look at updating the docs with something like this, but bringing up a discussion on the matter may be good to think about it in the various contexts of using MDX (Gatsby, Next, Vue, etc)

[ChristianMurphy]

Welcome @lannonbr!
Thanks for taking time to think about patterns and anti-patterns, and doing a write up!

Something I've been thinking about is a possible anti-pattern of putting everything in the MDXProvider

Can you expand why you think this is an anti-pattern?
This seems it may be a personal preference.

as if you are using a component only on one or two MDX files

This isn't always the case, components can be used on many/all pages.

then for the rest of the site, those files would be possibly part of a bundle or the module dependency tree of any page that uses the MDXProvider

Possibly, but that would be by choice, code splitting is still supported https://create-react-app.dev/docs/code-splitting
Components can still be loaded on demand when bundle size is a concern.

[ChristianMurphy]

With the code splitting stuff, can you give an example of how to put components in the provider on demand only when you need them

Sure,
Taking the example from https://mdxjs.com/advanced/components#mdxprovider
This does not code split:

import React from 'react'
import {MDXProvider} from '@mdx-js/react'
import {Heading, Text, Pre, Code, Table} from './components'
export default class Layout extends React.Component {
  state = {
    h1: Heading,
    // ...
    p: Text,
    code: Pre,
    inlineCode: Code
  }
  render() {
    return (
      <MDXProvider components={this.state}>
        <main {...this.props} />
      </MDXProvider>
    )
  }
}

---

it could be refactored

import React from 'react'
import {MDXProvider} from '@mdx-js/react'

export default class Layout extends React.Component {
  state = {
    h1: React.lazy(() => import( './components/Heading')),
    // ...
    p: React.lazy(() => import( './components/Text')),
    code: React.lazy(() => import( './components/Pre')),
    inlineCode: React.lazy(() => import( './components/Code'))
  }
  render() {
    return (
      <Suspense fallback={<>loading</>}>
        <MDXProvider components={this.state}>
          <main {...this.props} />
        </MDXProvider>
      </Suspense>
    )
  }
}

which lazy loads components on demand.

[lannonbr]

Alright, yeah that's valid. Now is this possible somehow with Server Side Rendering yet or no? (Sorry that I forgot to bring that up earlier)

[ChristianMurphy]

what you'd tend to go towards directly using import in an MDX file for.

Personally, I use MDX as an alternative to shortcodes, and only use import in an MDX file when I need to import something exported from a sibling MDX file.
But again, that's a personal preference, import is flexible and can be used in many ways, using it to import components is also fine.

[ChristianMurphy]

Alright, yeah that's valid. Now is this possible somehow with Server Side Rendering yet or no?

It is, the details change framework to framework, taking Next.js as an example https://nextjs.org/docs/advanced-features/dynamic-import can be used.

[lannonbr]

Alright. I think I will need to dive deeper and experiment on this further and if I find anything deeper I will get back to this with further questions