Dynamic Content in MDX

This is where MDX stops being "fancy Markdown" and becomes something actually powerful. You can show/hide content based on conditions, loop over data, respond to clicks, and fetch live data — all inside your content files.

Let's cover the patterns you'll actually use.

Conditional Rendering

You need to show or hide things based on some condition. Since JSX only accepts expressions (not statements like if/else), you've got two main tools: ternaries and &&.

Ternary Operator

The ternary (condition ? ifTrue : ifFalse) is your go-to for "show this OR that":

Logical AND (&&) Operator

Use && when you only want to render something when a condition is true — no else needed:

Pitfall: Watch out for && with falsy values like 0. The expression {count && <Text />} renders 0 on screen when count is 0. Use {count > 0 && <Text />} instead.

Conditional Rendering with Components

Here's a tab switcher — a real pattern you'd use for "show install instructions for npm/yarn/pnpm":

Mapping Over Arrays

Turning arrays into rendered lists. You'll do this constantly.

Basic Mapping

Advanced Mapping with Transformations

You can filter, color-code, and transform data on the fly:

Grouping and Reducing

Group items by category using reduce, then render each group:

Dynamic Styling

Styles that change based on data or state:

Inline Dynamic Styles

Conditional Class Names

Build class strings dynamically based on state:

State-Driven Content

Components that change what they show based on user interaction:

Interactive Quiz

Expandable FAQ

Fetching Data

Pull in external data and display it dynamically:

Client-Side Data Fetching

Data Fetching with Loading States

Always show loading and error states. Never leave the user staring at nothing.

Template Patterns

Reusable patterns for common scenarios:

Responsive Data Table Template

Search and Filter Template

Interactive Examples

Live Counter with Multiple Controls

Color Picker with Preview

Practical Tips

<div className="tips">

Tip 1: Keep dynamic logic short in MDX files. If a component passes 50 lines, move it to a separate file and import it.

Tip 2: Always show loading and error states for data fetches. Users shouldn't stare at a blank screen.

Tip 3: Use useMemo for expensive computations (filtering, sorting large arrays) so they don't recalculate on every render.

Tip 4: Prefer controlled components (state-driven inputs) for predictable behavior.

Tip 5: Test dynamic components in isolation before embedding them in MDX. Storybook or a test page works great for this.

</div>

Common Pitfalls

1. Rendering 0 with && — {items.length && <List />} shows 0 when the array is empty. Use {items.length > 0 && <List />}.
2. Missing keys in mapped lists — Always provide unique key props. Using the array index is fine only for static lists.
3. Infinite useEffect loops — Object/array dependencies in useEffect cause re-runs. Memoize them or use primitive deps.
4. Fetching on every render — Put fetches inside useEffect with proper dependency arrays to control when they fire.
5. Server/client mismatch — Dynamic content that differs between server render and client hydration causes React warnings. Use useEffect for client-only logic.
6. Over-engineering — Not everything needs to be dynamic. If content rarely changes, static Markdown is simpler and faster.

Summary

Dynamic content is what makes MDX worth using over plain Markdown. You've got conditional rendering for show/hide logic, .map() for lists, useState for interactivity, and useEffect + fetch for live data. Combine these patterns and your MDX pages become actual applications — quizzes, dashboards, live previews, searchable lists. Just keep things simple and extract complex components to their own files.