Skip to content

Commit 43db439

Browse files
committed
[Chore] Add Agents.md to help coding agents
1 parent c66cd8c commit 43db439

File tree

1 file changed

+301
-0
lines changed

1 file changed

+301
-0
lines changed

.claude/Agents.md

Lines changed: 301 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,301 @@
1+
# React-Admin Agent Context
2+
3+
React-admin is a comprehensive frontend framework for building B2B and admin applications on top of REST/GraphQL APIs, using TypeScript, React, and Material UI. It's an open-source project maintained by Marmelab that provides a complete solution for B2B applications with data-driven interfaces.
4+
5+
## Architecture & Design Patterns
6+
7+
### Key Principles
8+
9+
- Designed for Single-Page Application (SPA) architecture
10+
- Provider-based abstraction for data fetching, auth, and i18n
11+
- "Batteries included but removable" - everything is replaceable
12+
- User Experience and Developer Experience are equally important
13+
- Backward compatibility prioritized over new features
14+
- Composition over Configuration - Use React patterns, not custom DSLs
15+
- Minimal API Surface - If it can be done in React, don't add to core
16+
- Standing on Giants' Shoulders - Use best-in-class libraries, don't reinvent the wheel
17+
18+
### Provider Pattern
19+
20+
React-admin uses adapters called "providers" for external integrations:
21+
22+
```typescript
23+
// Data Provider - abstracts API calls
24+
dataProvider.getList('posts', {
25+
pagination: { page: 1, perPage: 5 },
26+
sort: { field: 'title', order: 'ASC' },
27+
filter: { author_id: 12 }
28+
})
29+
30+
// Auth Provider - handles authentication
31+
authProvider.checkAuth()
32+
authProvider.login({ username, password })
33+
authProvider.getPermissions()
34+
35+
// i18n Provider - manages translations
36+
i18nProvider.translate('ra.action.save')
37+
```
38+
39+
### Hook-Based API
40+
41+
All functionality exposed through hooks following React patterns:
42+
43+
```typescript
44+
// Data hooks
45+
const { data, isLoading } = useGetList('posts', {
46+
pagination: { page: 1, perPage: 10 }
47+
});
48+
49+
// State management hooks
50+
const [filters, setFilters] = useFilterState();
51+
const [page, setPage] = usePaginationState();
52+
53+
// Auth hooks
54+
const { permissions } = usePermissions();
55+
const canAccess = useCanAccess({ resource: 'posts', action: 'edit' });
56+
```
57+
58+
### Headless Core
59+
60+
The `ra-core` package contains all logic without UI. UI components are in separate packages like `ra-ui-materialui`. This allows:
61+
62+
- Custom UIs using core hooks and controllers
63+
- Swapping UI libraries without changing core logic
64+
65+
### Controller-View Separation
66+
67+
- Controllers in `ra-core/src/controller/` handle business logic
68+
- Views in `ra-ui-materialui/src/` handle rendering
69+
- Controllers provide data and callbacks via hooks
70+
71+
### Context: Pull, Don’t Push
72+
73+
Communication between components can be challenging, especially in large React applications, where passing props down several levels can become cumbersome. React-admin addresses this issue using a pull model, where components expose props to their descendants via a context, and descendants can consume these props using custom hooks.
74+
75+
Whenever a react-admin component fetches data or defines a callback, it creates a context and places the data and callback in it.
76+
77+
## Codebase Organization
78+
79+
### Monorepo Structure
80+
81+
```
82+
react-admin/
83+
├── packages/ # Lerna-managed packages
84+
│ ├── ra-core/ # Core logic, hooks, controllers
85+
│ ├── ra-ui-materialui/ # Material UI components
86+
│ ├── react-admin/ # Main distribution package
87+
│ ├── ra-data-*/ # Data provider adapters
88+
│ ├── ra-i18n-*/ # i18n providers
89+
│ └── ra-language-*/ # Translation packages
90+
├── examples/ # Example applications
91+
│ ├── simple/ # E2E test app
92+
│ ├── demo/ # Full e-commerce demo
93+
│ ├── crm/ # CRM application
94+
│ └── tutorial/ # Tutorial app
95+
├── cypress/ # E2E test configuration
96+
├── docs/ # Jekyll documentation
97+
└── scripts/ # Build scripts
98+
```
99+
100+
### Key ra-core Directories
101+
102+
- `src/auth/` - Authentication and authorization (54 files)
103+
- `src/controller/` - CRUD controllers and state management
104+
- `src/dataProvider/` - Data fetching and caching logic (70 files)
105+
- `src/form/` - Form handling (31 files)
106+
- `src/routing/` - Navigation and routing (26 files)
107+
- `src/i18n/` - Internationalization (30 files)
108+
109+
### Package Dependencies
110+
111+
- **Core**: React 18.3+, TypeScript 5.8+, lodash 4.17+, inflection 3.0+
112+
- **Routing**: React Router 6.28+
113+
- **Data**: TanStack Query 5.90+ (React Query)
114+
- **Forms**: React Hook Form 7.53+
115+
- **UI Components**: Material UI 5.16+
116+
- **Testing**: Jest 29.5+, Testing Library, Storybook, Cypress
117+
118+
## Development Practices
119+
120+
### TypeScript Requirements
121+
122+
- **Strict mode enabled** - no implicit any
123+
- **Complete type exports** - all public APIs must be typed
124+
- **Generic types** for flexibility in data providers and resources
125+
- **JSDoc comments** for better IDE support
126+
127+
```typescript
128+
// GOOD - Properly typed with generics
129+
export const useGetOne = <RecordType extends RaRecord = any>(
130+
resource: string,
131+
options?: UseGetOneOptions<RecordType>
132+
): UseGetOneResult<RecordType> => { ... }
133+
134+
// BAD - Using any without constraint
135+
export const useGetOne = (resource: any, options?: any): any => { ... }
136+
```
137+
138+
### Component Patterns
139+
140+
1. **Composition over configuration** - Use React composition patterns
141+
2. **Smart defaults** - Components should work out-of-the-box
142+
3. **Controlled and uncontrolled** modes supported
143+
4. **Props pass-through** - Spread additional props to root element
144+
145+
```jsx
146+
// Component composition example
147+
export const MyField = ({ source, ...props }) => {
148+
const record = useRecordContext();
149+
return (
150+
<TextField
151+
{...props} // Pass through all additional props
152+
value={record?.[source]}
153+
/>
154+
);
155+
};
156+
```
157+
158+
### File Organization
159+
- **Feature-based structure** within packages (not type-based)
160+
- **Co-location** - Tests (`.spec.tsx`) and stories (`.stories.tsx`) next to components
161+
- **Index exports** - Each directory has an index.ts exporting public API
162+
- **Flat structure** within features - avoid unnecessary nesting
163+
164+
### Documentation
165+
166+
Every new feature or API change must be documented. The documentation consists of Markdown files located in the `/docs/` directory and built with Jekyll, one file per component or hook.
167+
168+
All documentation files must include:
169+
170+
- A brief description of the component or hook
171+
- Usage examples
172+
- List of props or parameters (required props first, then in alphabetical order)
173+
- Detailed usage for each prop/parameter (in alphabetical order)
174+
- Recipes and advanced usage examples if applicable
175+
176+
### Pre-commit Hooks
177+
178+
- Automatic test execution for modified files
179+
- Prettier formatting check
180+
- ESLint validation
181+
- TypeScript compilation
182+
183+
184+
### Development Workflow
185+
```bash
186+
# Initial setup
187+
make install # Install all dependencies
188+
189+
# After making changes
190+
make build # Build packages (TypeScript compilation)
191+
make test # run unit and e2e tests
192+
193+
# Before pushing changes
194+
make lint # Check code quality
195+
make prettier # Format code
196+
```
197+
198+
### Pull Request Process
199+
200+
1. **Target branch**: `next` for features, `master` for bug fixes
201+
2. **Required checks**:
202+
- All tests passing (`make test`)
203+
- Linting clean (`make lint`)
204+
- Prettier formatted (`make prettier`)
205+
- TypeScript compiles (`yarn typecheck`)
206+
207+
3. **Commit Messages**: Clear, descriptive messages focusing on "why"
208+
```
209+
fix: Prevent duplicate API calls in useGetList hook
210+
feat: Add support for custom row actions in Datagrid
211+
docs: Clarify dataProvider response format
212+
```
213+
214+
4. **Documentation**: Update relevant docs for API changes
215+
216+
### Common Make Commands
217+
```bash
218+
make # Show all available commands
219+
make install # Install dependencies
220+
make build # Build all packages (CJS + ESM)
221+
make watch # Development watch mode
222+
make test # Run all tests
223+
make lint # Check code quality
224+
make prettier # Format code
225+
make run-simple # Run simple example
226+
make run-demo # Run demo application
227+
```
228+
229+
### Performance Considerations
230+
231+
- Use `React.memo()` for expensive components
232+
- Leverage `useMemo()` and `useCallback()` appropriately
233+
- Implement pagination for large datasets
234+
- Use query caching via React Query
235+
236+
### Accessibility
237+
238+
- Follow WCAG guidelines
239+
- Ensure keyboard navigation works
240+
- Provide proper ARIA labels
241+
- Test with screen readers
242+
243+
### Browser Support
244+
- Modern browsers only (Chrome, Firefox, Safari, Edge)
245+
- No IE11 support
246+
- ES5 compilation target for compatibility
247+
248+
## Misc
249+
250+
- **Don't use `React.cloneElement()`** - it breaks composition
251+
- **Don't inspect children** - violates React patterns (exception: Datagrid)
252+
- **Don't add comments** when code is self-explanatory
253+
- **Don't add features** achievable in a few lines with pure React
254+
- **Don't skip tests** - they run automatically on commit
255+
- **Don't force push** to main/master branches
256+
257+
## Testing Requirements
258+
259+
All developments must include tests to ensure code quality and prevent regressions.
260+
261+
### Storybook
262+
263+
- **Location**: Stories alongside components as `*.stories.tsx`
264+
- **Coverage**: All components must have stories demonstrating usage for all props
265+
- **Mocking**: Use jest mocks sparingly, prefer integration tests
266+
- **Data**: Use mock data providers (e.g., FakeRest) for stories. Make realistic data scenarios as the stories are also used for screenshots and visual testing.
267+
268+
### Unit & Integration Testing (Jest)
269+
270+
- **Location**: Tests alongside source files as `*.spec.tsx`
271+
- **Test Cases**: Reuse the component's stories as test cases
272+
- **Assertions**: Use testing-library to render and assert on elements. Don't test implementation details or HTML attributes, use assertions based on user interactions and visible output.
273+
- **Commands**:
274+
```bash
275+
make test-unit # Run all unit and functional tests
276+
npx jest [pattern] # Run specific tests
277+
```
278+
279+
### E2E Testing (Cypress)
280+
281+
Kept minimal to critical user paths due to maintenance overhead.
282+
283+
- **Location**: `cypress/` directory
284+
- **Target**: Simple example app (`examples/simple/`)
285+
- **Coverage**: Critical user paths and interactions
286+
- **Commands**:
287+
288+
```bash
289+
make test-e2e # Run in CI mode
290+
# or for local testing with GUI:
291+
make run-simple # Start test app with vite
292+
make test-e2e-local # Run e2e tests with GUI
293+
```
294+
295+
### Static Analysis
296+
297+
```bash
298+
make lint # ESLint checks
299+
make prettier # Prettier formatting
300+
make build # TypeScript type checking
301+
```

0 commit comments

Comments
 (0)