React Docs Voice & Style
Universal Rules
- Capitalize React terms when referring to the React concept in headings or as standalone concepts:
- Core: Hook, Effect, State, Context, Ref, Component, Fragment
- Concurrent: Transition, Action, Suspense
- Server: Server Component, Client Component, Server Function, Server Action
- Patterns: Error Boundary
- Canary: Activity, View Transition, Transition Type
- In prose: Use lowercase when paired with descriptors: "state variable", "state updates", "event handler". Capitalize when the concept stands alone or in headings: "State is isolated and private"
- General usage stays lowercase: "the page transitions", "takes an action"
- Product names: ESLint, TypeScript, JavaScript, Next.js (not lowercase)
- Bold for key concepts: state variable, event handler
- Italics for new terms being defined: event handlers
- Inline code for APIs:
useState, startTransition, <Suspense>
- Avoid: "simple", "easy", "just", time estimates
- Frame differences as "capabilities" not "advantages/disadvantages"
- Avoid passive voice and jargon
Tone by Page Type
| Type |
Tone |
Example |
| Learn |
Conversational |
"Here's what that looks like...", "You might be wondering..." |
| Reference |
Technical |
"Call useState at the top level...", "This Hook returns..." |
| Blog |
Accurate |
Focus on facts, not marketing |
Note: Pitfall and DeepDive components can use slightly more conversational phrasing ("You might wonder...", "It might be tempting...") even in Reference pages, since they're explanatory asides.
Avoiding Jargon
Pattern: Explain behavior first, then name it.
✅ "React waits until all code in event handlers runs before processing state updates. This is called batching."
❌ "React uses batching to process state updates atomically."
Terms to avoid or explain:
| Jargon |
Plain Language |
| atomic |
all-or-nothing, batched together |
| idempotent |
same inputs, same output |
| deterministic |
predictable, same result every time |
| memoize |
remember the result, skip recalculating |
| referentially transparent |
(avoid - describe the behavior) |
| invariant |
rule that must always be true |
| reify |
(avoid - describe what's being created) |
Allowed technical terms in Reference pages:
- "stale closures" - standard JS/React term, can be used in Caveats
- "stable identity" - React term for consistent object references across renders
- "reactive" - React term for values that trigger re-renders when changed
- These don't need explanation in Reference pages (readers are expected to know them)
Use established analogies sparingly—once when introducing a concept, not repeatedly:
| Concept |
Analogy |
| Components/React |
Kitchen (components as cooks, React as waiter) |
| Render phases |
Restaurant ordering (trigger/render/commit) |
| State batching |
Waiter collecting full order before going to kitchen |
| State behavior |
Snapshot/photograph in time |
| State storage |
React storing state "on a shelf" |
| State purpose |
Component's memory |
| Pure functions |
Recipes (same ingredients → same dish) |
| Pure functions |
Math formulas (y = 2x) |
| Props |
Adjustable "knobs" |
| Children prop |
"Hole" to be filled by parent |
| Keys |
File names in a folder |
| Curly braces in JSX |
"Window into JavaScript" |
| Declarative UI |
Taxi driver (destination, not turn-by-turn) |
| Imperative UI |
Turn-by-turn navigation |
| State structure |
Database normalization |
| Refs |
"Secret pocket" React doesn't track |
| Effects/Refs |
"Escape hatch" from React |
| Context |
CSS inheritance / "Teleportation" |
| Custom Hooks |
Design system |
Common Prose Patterns
Wrong vs Right code:
\`\`\`js
// 🚩 Don't mutate state:
obj.x = 10;
\`\`\`
\`\`\`js
// ✅ Replace with new object:
setObj({ ...obj, x: 10 });
\`\`\`
Table comparisons:
| passing a function | calling a function |
| `onClick={handleClick}` | `onClick={handleClick()}` |
Linking:
[Read about state](/learn/state-a-components-memory)
[See `useState` reference](/reference/react/useState)
Code Style
- Prefer JSX over createElement
- Use const/let, never var
- Prefer named function declarations for top-level functions
- Arrow functions for callbacks that need
this preservation
Version Documentation
When APIs change between versions:
Starting in React 19, render `<Context>` as a provider:
\`\`\`js
<SomeContext value={value}>{children}</SomeContext>
\`\`\`
In older versions:
\`\`\`js
<SomeContext.Provider value={value}>{children}</SomeContext.Provider>
\`\`\`
Patterns:
- "Starting in React 19..." for new APIs
- "In older versions of React..." for legacy patterns
1---2name: docs-voice3description: Use when writing any React documentation. Provides voice, tone, and style rules for all doc types.4---5
6# React Docs Voice & Style
7
8## Universal Rules
9
10- **Capitalize React terms** when referring to the React concept in headings or as standalone concepts:
11 - Core: Hook, Effect, State, Context, Ref, Component, Fragment
12 - Concurrent: Transition, Action, Suspense
13 - Server: Server Component, Client Component, Server Function, Server Action
14 - Patterns: Error Boundary
15 - Canary: Activity, View Transition, Transition Type
16 - **In prose:** Use lowercase when paired with descriptors: "state variable", "state updates", "event handler". Capitalize when the concept stands alone or in headings: "State is isolated and private"
17 - General usage stays lowercase: "the page transitions", "takes an action"
18- **Product names:** ESLint, TypeScript, JavaScript, Next.js (not lowercase)
19- **Bold** for key concepts: **state variable**, **event handler**
20- **Italics** for new terms being defined: *event handlers*
21- **Inline code** for APIs: `useState`, `startTransition`, `<Suspense>`
22- **Avoid:** "simple", "easy", "just", time estimates
23- Frame differences as "capabilities" not "advantages/disadvantages"
24- Avoid passive voice and jargon
25
26## Tone by Page Type
27
28| Type | Tone | Example |
29|------|------|---------|
30| Learn | Conversational | "Here's what that looks like...", "You might be wondering..." |
31| Reference | Technical | "Call `useState` at the top level...", "This Hook returns..." |
32| Blog | Accurate | Focus on facts, not marketing |
33
34**Note:** Pitfall and DeepDive components can use slightly more conversational phrasing ("You might wonder...", "It might be tempting...") even in Reference pages, since they're explanatory asides.
35
36## Avoiding Jargon
37
38**Pattern:** Explain behavior first, then name it.
39
40✅ "React waits until all code in event handlers runs before processing state updates. This is called *batching*."
41
42❌ "React uses batching to process state updates atomically."
43
44**Terms to avoid or explain:**
45| Jargon | Plain Language |
46|--------|----------------|
47| atomic | all-or-nothing, batched together |
48| idempotent | same inputs, same output |
49| deterministic | predictable, same result every time |
50| memoize | remember the result, skip recalculating |
51| referentially transparent | (avoid - describe the behavior) |
52| invariant | rule that must always be true |
53| reify | (avoid - describe what's being created) |
54
55**Allowed technical terms in Reference pages:**
56- "stale closures" - standard JS/React term, can be used in Caveats
57- "stable identity" - React term for consistent object references across renders
58- "reactive" - React term for values that trigger re-renders when changed
59- These don't need explanation in Reference pages (readers are expected to know them)
60
61**Use established analogies sparingly—once when introducing a concept, not repeatedly:**
62
63| Concept | Analogy |
64|---------|---------|
65| Components/React | Kitchen (components as cooks, React as waiter) |
66| Render phases | Restaurant ordering (trigger/render/commit) |
67| State batching | Waiter collecting full order before going to kitchen |
68| State behavior | Snapshot/photograph in time |
69| State storage | React storing state "on a shelf" |
70| State purpose | Component's memory |
71| Pure functions | Recipes (same ingredients → same dish) |
72| Pure functions | Math formulas (y = 2x) |
73| Props | Adjustable "knobs" |
74| Children prop | "Hole" to be filled by parent |
75| Keys | File names in a folder |
76| Curly braces in JSX | "Window into JavaScript" |
77| Declarative UI | Taxi driver (destination, not turn-by-turn) |
78| Imperative UI | Turn-by-turn navigation |
79| State structure | Database normalization |
80| Refs | "Secret pocket" React doesn't track |
81| Effects/Refs | "Escape hatch" from React |
82| Context | CSS inheritance / "Teleportation" |
83| Custom Hooks | Design system |
84
85## Common Prose Patterns
86
87**Wrong vs Right code:**
88```mdx
89\`\`\`js
90// 🚩 Don't mutate state:
91obj.x = 10;
92\`\`\`
93
94\`\`\`js
95// ✅ Replace with new object:
96setObj({ ...obj, x: 10 });
97\`\`\`
98```
99
100**Table comparisons:**
101```mdx
102| passing a function | calling a function |
103| `onClick={handleClick}` | `onClick={handleClick()}` |
104```
105
106**Linking:**
107```mdx
108[Read about state](/learn/state-a-components-memory)
109[See `useState` reference](/reference/react/useState)
110```
111
112## Code Style
113
114- Prefer JSX over createElement
115- Use const/let, never var
116- Prefer named function declarations for top-level functions
117- Arrow functions for callbacks that need `this` preservation
118
119## Version Documentation
120
121When APIs change between versions:
122
123```mdx
124Starting in React 19, render `<Context>` as a provider:
125\`\`\`js
126<SomeContext value={value}>{children}</SomeContext>
127\`\`\`
128
129In older versions:
130\`\`\`js
131<SomeContext.Provider value={value}>{children}</SomeContext.Provider>
132\`\`\`
133```
134
135Patterns:
136- "Starting in React 19..." for new APIs
137- "In older versions of React..." for legacy patterns