MDX content inside JSX elements (perhaps inside JS code)?

[egnor]

Root problem: I want to write MDX content which has occasional conditional branches, like (pseudocode)

~~ if props.foo ~~
## Foo is true!
So you can rely on foo.
~~ else ~~
## There's no foo here!
So don't even think about using it.
~~ endif ~~

Anyhoo, let's talk about some other non foo related stuff

Logically, I'd want something like this

{props.foo ? <>
  ## Foo is true!
  So you can rely on foo.
</> : <>
  ## Foo is false!
  So don't even think about using it.
</>}

...but that doesn't work of course, you get "## Foo is true! So you can rely on foo." without MDX interpretation.

Now, I do know various ways to do this with MDX/JSX, like (untested)

{props.foo
  ? <><h2>Foo is true!</h2> <p>So you can rely on foo.</p></>
  : <><h2>There's no foo here!</h2> <p>So don't even think about using it.</p></>}

But now within the conditional block we no longer have the benefit of MDX which is super sad. A different alternative is to make several MDX components, like

foo_true.mdx:

## Foo is true!
So you can rely on foo.

foo_false.mdx:

## There's no foo here!
So don't even think about using it.

page.mdx:

import FooTrue from "./foo_true.mdx";
import FooFalse from "./foo_false.mdx";

{props.foo ? <FooTrue/> : <FooFalse/>}

...but that leads to a proliferation of little files. Or, I could do this:

export function Maybe({ when, children }) {
  return when ? <>{children}</> : <></>; 
}

<Maybe when={props.foo}>
  ## Foo is true!
  So you can rely on foo.
</Maybe>

<Maybe when={!props.foo}>
  ## There's no foo here!
  So don't even think about using it.
</Maybe>

But that seems like I'm re-inventing an if-statement which must be wrong?? Also it's not great because both branches are processed regardless of the condition, which can lead to errors. And this seems like a very basic thing one might want to do in content, so I imagine I'm just missing some idiom here??

Other references

• This seems relevant, but lonnnng and I'm not sure where the dust settled? RFC: Interleaving Markdown in JSX #628
• Almost exactly my question, but is unanswered (except for a suggestion to do the many-component-files thing)
• A similar question, mentions MDX template literals? But I don't think those exist?

[wooorm]

Hi!

Right, so these are your options: a) write as JSX, b) move things to a component, c) some sort of <if>.

That seems like enough options to me.
The problem with a) you describe, namely loosing markdown, is solved by b)
The problem with b) you describe, namely little files, is solved by a) — if they are so little, you can write a couple tags

For c):

both branches are processed regardless of the condition

Everything is “processed”. Not entirely sure what you mean by that word. This approach c) is the only one that would be a good fit for not processing: if there are static conditions, then you can write a plugin to drop the non-matching branch.

---

Anyway, yeah, https://github.com/orgs/mdx-js/discussions/2276 holds up

[egnor]

Is there a standard plugin that implements <If> and similar utilities, avoiding the issue below? Not even sure exactly which type of plugin would be best for that?

everything is "processed"

Sorry I was imprecise, I meant something closer to "evaluated" I think. What I mean is that if I do something like this...

export function If({ when, children }) {
  return when ? <> {children} </> : <> </>;
}

<If when={foo}>
  # Hi! Foo is defined
  Its bar is {foo.bar}
</If>

...then if foo is null or undefined this results in an error at whatever point the outer component is instantiated, because the children are still fully instantiated and all substitutions evaluated for passing to the <If> component even though it's going to ignore them, and thus foo.bar is evaluated which is an error. The similar JSX code does not have this problem:

{foo ? <> <h1> Hi! Foo is defined </h1> <p> Its bar is {foo.bar} </p> </> : <> </> }

One can write code to dodge this but it's clunky, and "if thing is available, use thing, otherwise don't" is an extraordinarily common pattern.

Anyway, I politely disagree that the first two solutions (break out components, or use JSX) are acceptable for all use cases -- there are places where one really wants to preserve the flow of content while adding a conditional, but dropping to JSX is jarring and obnoxious -- but that's obviously subjective. Plugins are the usual answer for "I think this is important but you don't" so that's why I'm exploring this route...