CodivDocs

Status

<Math> is a stub component today. KaTeX integration is feature-flagged and adds ~60KB to the bundle, so it's deferred to Phase 9 (Polish) and gated behind a tenant config opt-in. Until then, the component renders the raw LaTeX in a monospace dashed-border box as a graceful fallback.

Target API (Phase 9)

Inline: <Math>{`E = mc^2`}</Math>

Block: <Math display>{`\\int_0^\\infty e^{-x^2} dx = \\frac{\\sqrt{\\pi}}{2}`}</Math>

E = mc^2 is the inline form.

\int_0^\infty e^{-x^2} dx = \frac{\sqrt{\pi}}{2}

The dashed border is the stub indicator — when Phase 9 ships, it will be replaced with proper KaTeX-rendered glyphs.

Why this is deferred

KaTeX is the smallest LaTeX renderer for the web (~60KB gzipped) but it's still a chunky dependency for a feature most docs sites don't use. Pulling it in unconditionally would tax every reader's bundle. The Phase 9 plan:

Add katex as an optional peer dependency
Lazy-import on first <Math> mount, same pattern as Mermaid (~150KB) — pages without math pay zero cost
Surface a tenant config flag features.math: true to opt in
Render via katex.render() with theme-token color overrides so equations match the page palette

This keeps bundle costs honest: math support exists, but only the tenants who need it pay for it.

v0 fallback

Today, the component:

Accepts the children (LaTeX source) and display (block vs inline) props — forward-compatible
Renders the raw LaTeX in a monospace dashed-border container so it's at least legible
Adds an aria-label so screen readers announce it as a "Math expression (LaTeX, not yet rendered)"

You can author Math components today and they'll upgrade to rendered glyphs when Phase 9 ships — no MDX changes needed.

Props

Prop	Type	Default	Description
`children`	`string`	required	LaTeX source
`display`	`boolean`	`false`	Block (centered, full-width) vs inline rendering