react-standard
Skill0 starsChanged 4 months agoMITView on GitHub
Core frontend coding standards for React + TypeScript projects using MUI, TanStack libraries, i18next, and Zod. Use this whenever writing any new component, hook, service, type, or utility — or when reviewing existing code for consistency. Covers naming conventions, file structure, TypeScript patterns, i18n, error handling, and import aliases.
In this repository12 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- feature-architectureSkill
- frontend-auditSkill
- frontend-i18nSkill
- mui-themeSkill
- react-coreSkill
- table-mrtSkill
- tanstack-formSkill
- tanstack-querySkill
- tanstack-routerSkill
- flutter-clean-arch-getxSkill
- flutter-flavorsSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
18 rules. About 0 are common, 3 are distinctive, and 15 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈3
Distinctive · estimate
This author's own choices. Worth a look.
15
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 10
Always use useTranslation() for user-visible strings — never hardcode them.
- Distinctive: line 11
Use named exports, not default exports, for everything except route components.
- Very specific: line 28
Never use npm, yarn, or pnpm.
- Very specific: line 52
All files are .ts or .tsx.
- Very specific: line 53
Prefer type over interface for data shapes.
- Very specific: line 54
Avoid any. Use unknown at system boundaries.
- Very specific: line 56
Never as any unless wrapping a known incompatibility (e.g., TanStack Form generics).
- Very specific: line 70
Use path alias @/ for absolute imports from src/:
- Very specific: line 77
Prefer relative imports for intra-feature files.
- Very specific: line 81
Always use useTranslation() — never hardcode user-visible strings.
- Distinctive: line 110
Write no comments unless the WHY is non-obvious.
- Very specific: line 129
Use sx prop for one-off styles.
- Very specific: line 130
Prefer MUI responsive breakpoints: { xs: ..., sm: ..., md: ...
- Very specific: line 131
Use elevation={0} with border on Cards for flat design.
- Very specific: line 132
Use Container maxWidth="xl" for page-level containers.
- Very specific: line 138
MUI Grid must use the
sizeprop: Never put breakpoint props directly on <Grid> (xs, sm, md, lg, xl). - Very specific: line 140
Import from @mui/material — MUI v9 unified Grid, no separate Grid2 import:
- Distinctive: line 164
Prefer shared components over re-implementing:
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Frontend Coding Standards
Core Invariants (always enforced — never violate)
- Always use
useTranslation()for user-visible strings — never hardcode them. - Use named exports, not default exports, for everything except route components.
- Route files live only in
src/routes/— never create route files insidefeatures/. - Use
bunfor all package installation — nevernpm,yarn, orpnpm. - Use MUI Grid
sizeprop for column sizing — neverxs/sm/md/lg/xlprops directly on Grid.
Package Manager
This project uses bun exclusively. Always use bun for all package operations:
bun add <package> # install a dependency
bun add -d <package> # install a dev dependency
bun install # install all dependencies from lockfile
bun run <script> # run a package.json script
bunx <cli> # run a package binary without installing globallyNever use npm, yarn, or pnpm.
Tech Stack
| Concern | Library |
| UI | MUI v9 (Material UI) |
| Tables | material-react-table v3 (via shared DataTable wrapper) |
| Styling engine | @emotion/react + @emotion/styled (required MUI peer deps) |
| Routing | TanStack Router (file-based) |
| Data fetching | TanStack Query v5 |
| Forms | TanStack Form v1 |
| Validation | Zod v4 |
| i18n | i18next + react-i18next |
| HTTP | Axios (shared instance from @/core/api/axios.config) |
| Date | Day.js (via MUI LocalizationProvider with AdapterDayjs) |
MUI v9 requires both
@emotion/reactand@emotion/styledas peer dependencies. Always install them together:bun add @mui/material @emotion/react @emotion/styled
TypeScript
- All files are
.tsor.tsx. No.js. - Prefer
typeoverinterfacefor data shapes; useinterfaceonly when extension is needed. - Avoid
any. Useunknownat system boundaries; narrow before use. - Export types from the feature's
types/index.tsor alongside the component. - Never
as anyunless wrapping a known incompatibility (e.g., TanStack Form generics).
Naming Conventions
- Components: PascalCase (
ElectricityList,SectionCard) - Hooks: camelCase prefixed with
use(useElectricities,useCreateElectricity) - Services: camelCase object exported as const (
electricityService) - Types: PascalCase (
Electricity,ElectricityFilterParams) - Constants: SCREAMING_SNAKE_CASE for values, PascalCase for option arrays (
ELECTRICITY_ENDPOINTS,USER_USING_TYPES) - Files: kebab-case (
electricity.service.ts,useElectricities.ts) - Route files: live in
src/routes/_layout/section/feature/only — kebab-case directories,index.tsxfor list,create.tsxfor create,$paramId/index.tsxfor detail,$paramId/edit.tsxfor edit
Imports
Use path alias @/ for absolute imports from src/:
import { DataTable } from '@/shared/components/DataTable'
import { useSnackbar } from '@/core/context/SnackbarContext'
import { electricityService } from '../services'Prefer relative imports for intra-feature files; use @/ for cross-feature or shared.
i18n
Always use useTranslation() — never hardcode user-visible strings.
const { t } = useTranslation()
// Usage
t('electricities.code')
t('common.save')Translations live in the i18n config. Key structure: featureName.keyName or common.keyName.
Error Handling
- API errors surface via
useSnackbar()(showSuccess,showError). - Translate API errors with
useAPIErrorTranslator()→translateError(error). - Form submit errors show inline via
onErrorofuseMutation.
const { showSuccess, showError } = useSnackbar()
const { translateError } = useAPIErrorTranslator()
mutation.mutate(data, {
onSuccess: () => showSuccess(t('feature.updateSuccess')),
onError: (error) => showError(translateError(error)),
})Comments
Write no comments unless the WHY is non-obvious. Self-documenting names are preferred.
Component Shape
Functional components only. Named exports (not default exports) for everything except route components which can be inline functions.
// Named export - preferred
export function ElectricityList({ data, isLoading }: ElectricityListProps) { ... }
// Props interface above component
interface ElectricityListProps {
data?: Electricity[]
isLoading?: boolean
}MUI Usage
- Use
sxprop for one-off styles; avoid inlinestyle. - Prefer MUI responsive breakpoints:
{ xs: ..., sm: ..., md: ... }. - Use
elevation={0}withborderon Cards for flat design. - Use
Container maxWidth="xl"for page-level containers.
MUI Grid
MUI v9: Grid2 is deprecated and removed. It has been merged into Grid. Always import Grid from @mui/material.
MUI Grid must use the size prop. Never put breakpoint props directly on <Grid> (xs, sm, md, lg, xl). Never use the legacy item prop. Never import or use Grid2.
Import from @mui/material — MUI v9 unified Grid, no separate Grid2 import:
import { Grid } from '@mui/material'| Wrong | Correct |
<Grid xs={12} md={6}> | <Grid size={{ xs: 12, md: 6 }}> |
<Grid item xs={12} md={6}> | <Grid size={{ xs: 12, md: 6 }}> |
import Grid2 from '@mui/material/Grid2' | import { Grid } from '@mui/material' |
<Grid md={10}> | <Grid size={{ md: 10 }}> or <Grid size={10}> |
Container rows stay unchanged:
<Grid container spacing={3}>
<Grid size={{ xs: 12, md: 6 }}>...</Grid>
<Grid size={12}>...</Grid>
</Grid>Shared Components
Prefer shared components over re-implementing:
DataTable— MRT wrapper for all data tablesSectionCard— Card with icon + title for detail pagesInfoRow— label/value pair inside SectionCardOrganizationFilter— org hierarchy filter UIConfirmDialog/useConfirmDialog— confirmation modals- Form components via
useAppForm(see frontend-tanstack-form skill)
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

