React
Apply the TypeScript Style Guide's React conventions in the context of the current task.
Workflow
- Inspect the consuming repository's React, framework, and state-management conventions.
- Let explicit repository conventions take precedence over this opinionated guidance.
- Apply, review, or explain only the guidance relevant to the task.
- State important tradeoffs when component or state design depends on application context.
Boundaries
- Keep TypeScript, React, and ESLint responsible for checks they can enforce automatically.
- Do not redesign unrelated components or state merely because this skill is active.
Related Guidance
Functions
For detailed function design guidance, use typescript-functions when it is available.
Appendix - React
Since React components and hooks are also functions, the respective function conventions apply.
Props To State
In general, avoid using props as initial state because the state will not update when the props change. This can lead to bugs that are hard to track, unintended side effects, and difficulty testing.
When there is truly a use case for using a prop as initial state, the prop must be prefixed with initial (e.g. initialProduct, initialSort etc.)
// ❌ Avoid using props to state
type FooProps = {
productName: string;
userId: string;
};
export const Foo = ({ productName, userId }: FooProps) => {
const [productName, setProductName] = useState(productName);
...
// ✅ Use prop prefix `initial` when there is a rationale for it
type FooProps = {
initialProductName: string;
userId: string;
};
export const Foo = ({ initialProductName, userId }: FooProps) => {
const [productName, setProductName] = useState(initialProductName);
...
Props Type
// ❌ Avoid using React.FC type
type FooProps = {
name: string;
score: number;
};
export const Foo: React.FC<FooProps> = ({ name, score }) => {
// ✅ Use props argument with type
type FooProps = {
name: string;
score: number;
};
export const Foo = ({ name, score }: FooProps) => {...
Component Types
Container
UI - Feature
UI - Design system
Store & Pass Data
Pass only the necessary props to child components rather than passing the entire object.
Utilize storing state in the URL, especially for filtering, sorting etc.
Don't sync URL state with local state.
Consider passing data simply through props, using the URL, or composing children. Use global state (Zustand, Context) as a last resort.
Use React compound components when components should belong and work together: menu, accordion, navigation, tabs, list, etc.
Always export compound components as:
// PriceList.tsx
const PriceListRoot = ({ children }) => <ul>{children}</ul>;
const PriceListItem = ({ title, amount }) => <li>Name: {name} - Amount: {amount}<li/>;
// ❌
export const PriceList = {
Container: PriceListRoot,
Item: PriceListItem,
};
// ❌
PriceList.Item = Item;
export default PriceList;
// ✅
export const PriceList = PriceListRoot as typeof PriceListRoot & {
Item: typeof PriceListItem;
};
PriceList.Item = PriceListItem;
// App.tsx
import { PriceList } from "./PriceList";
<PriceList>
<PriceList.Item title="Item 1" amount={8} />
<PriceList.Item title="Item 2" amount={12} />
</PriceList>;
UI components should show derived state and send events, nothing more (no business logic).
As in many programming languages, function arguments can be passed to the next function and on to the next etc.
React components are no different, so prop drilling should not become an issue.
If prop drilling truly becomes an issue as the app scales, try refactoring render methods or local state in parent components, or use composition.
Data fetching is only allowed in container components.
The use of a server-state library is encouraged (TanStack Query, Apollo Client etc.).
Use of client-state library for global state is discouraged.
Reconsider whether something should be truly global across the application, e.g. themeMode or Permissions, or whether it can be put in server state (e.g. user settings from the /me endpoint). If global state is still truly needed, use Zustand or Context.
1---2name: typescript-react3description: Apply, review, and explain React conventions from the TypeScript Style Guide. Use automatically for TypeScript and TSX tasks involving prop-derived state, prop typing, component responsibilities, data flow, compound components, or client and server state.4---5
6# React
7
8Apply the TypeScript Style Guide's React conventions in the context of the current task.
9
10## Workflow
11
121. Inspect the consuming repository's React, framework, and state-management conventions.
132. Let explicit repository conventions take precedence over this opinionated guidance.
143. Apply, review, or explain only the guidance relevant to the task.
154. State important tradeoffs when component or state design depends on application context.
16
17## Boundaries
18
19- Keep TypeScript, React, and ESLint responsible for checks they can enforce automatically.
20- Do not redesign unrelated components or state merely because this skill is active.
21
22## Related Guidance
23
24### Functions
25
26For detailed function design guidance, use `typescript-functions` when it is available.
27
28<!-- BEGIN CANONICAL GUIDE CONTENT -->
29
30## Appendix - React
31
32Since React components and hooks are also functions, the respective [function conventions](#functions) apply.
33
34### Props To State
35
36In general, avoid using props as initial state because the state will not update when the props change. This can lead to bugs that are hard to track, unintended side effects, and difficulty testing.
37When there is truly a use case for using a prop as initial state, the prop must be prefixed with `initial` (e.g. `initialProduct`, `initialSort` etc.)
38
39```tsx
40// ❌ Avoid using props to state
41type FooProps = {
42 productName: string;
43 userId: string;
44};
45
46export const Foo = ({ productName, userId }: FooProps) => {
47 const [productName, setProductName] = useState(productName);
48 ...
49
50// ✅ Use prop prefix `initial` when there is a rationale for it
51type FooProps = {
52 initialProductName: string;
53 userId: string;
54};
55
56export const Foo = ({ initialProductName, userId }: FooProps) => {
57 const [productName, setProductName] = useState(initialProductName);
58 ...
59```
60
61### Props Type
62
63```tsx
64// ❌ Avoid using React.FC type
65type FooProps = {
66 name: string;
67 score: number;
68};
69
70export const Foo: React.FC<FooProps> = ({ name, score }) => {
71
72// ✅ Use props argument with type
73type FooProps = {
74 name: string;
75 score: number;
76};
77
78export const Foo = ({ name, score }: FooProps) => {...
79```
80
81### Component Types
82
83#### Container
84
85- All container components have the suffix "Container" or "Page" `[ComponentName]Container|Page`. Use the "Page" suffix to indicate that a component is an actual web page.
86- Each feature has a container component (`AddUserContainer.tsx`, `EditProductContainer.tsx`, `ProductsPage.tsx` etc.)
87- Includes business logic.
88- API integration.
89- Structure:
90 ```
91 ProductsPage/
92 ├─ api/
93 │ └─ useGetProducts/
94 ├─ components/
95 │ └─ ProductItem/
96 ├─ utils/
97 │ └─ filterProductsByType/
98 └─ index.tsx
99 ```
100
101#### UI - Feature
102
103- Representational components that are designed to fulfill feature requirements.
104- Nested inside container component folder.
105- Should follow [function conventions](#functions) as much as possible.
106- No API integration.
107- Structure:
108 ```
109 ProductItem/
110 ├─ index.tsx
111 ├─ ProductItem.stories.tsx
112 └─ ProductItem.test.tsx
113 ```
114
115#### UI - Design system
116
117- Globally reusable or shared components used throughout the whole codebase.
118- Structure:
119 ```
120 Button/
121 ├─ index.tsx
122 ├─ Button.stories.tsx
123 └─ Button.test.tsx
124 ```
125
126### Store & Pass Data
127
128- Pass only the necessary props to child components rather than passing the entire object.
129- Utilize storing state in the URL, especially for filtering, sorting etc.
130- Don't sync URL state with local state.
131- Consider passing data simply through props, using the URL, or composing children. Use global state (Zustand, Context) as a last resort.
132- Use React compound components when components should belong and work together: `menu`, `accordion`, `navigation`, `tabs`, `list`, etc.
133 Always export compound components as:
134
135 ```tsx
136 // PriceList.tsx
137 const PriceListRoot = ({ children }) => <ul>{children}</ul>;
138 const PriceListItem = ({ title, amount }) => <li>Name: {name} - Amount: {amount}<li/>;
139
140 // ❌
141 export const PriceList = {
142 Container: PriceListRoot,
143 Item: PriceListItem,
144 };
145 // ❌
146 PriceList.Item = Item;
147 export default PriceList;
148
149 // ✅
150 export const PriceList = PriceListRoot as typeof PriceListRoot & {
151 Item: typeof PriceListItem;
152 };
153 PriceList.Item = PriceListItem;
154
155 // App.tsx
156 import { PriceList } from "./PriceList";
157
158 <PriceList>
159 <PriceList.Item title="Item 1" amount={8} />
160 <PriceList.Item title="Item 2" amount={12} />
161 </PriceList>;
162 ```
163
164- UI components should show derived state and send events, nothing more (no business logic).
165- As in many programming languages, function arguments can be passed to the next function and on to the next etc.
166 React components are no different, so prop drilling should not become an issue.
167 If prop drilling truly becomes an issue as the app scales, try refactoring render methods or local state in parent components, or use composition.
168- Data fetching is only allowed in container components.
169- The use of a server-state library is encouraged ([TanStack Query](https://tanstack.com/query/latest/docs/framework/react/overview), [Apollo Client](https://github.com/apollographql/apollo-client) etc.).
170- Use of client-state library for global state is discouraged.
171 Reconsider whether something should be truly global across the application, e.g. `themeMode` or `Permissions`, or whether it can be put in server state (e.g. user settings from the `/me` endpoint). If global state is still truly needed, use [Zustand](https://github.com/pmndrs/zustand) or [Context](https://react.dev/reference/react/createContext).
172
173<!-- END CANONICAL GUIDE CONTENT -->