Best Practices
These guidelines keep the codebase consistent and maintainable as the team and project grow.
Code quality
- Write TypeScript with strict mode enabled. Avoid
anyunless you have a documented reason. - Use named exports for components and functions. Default exports are reserved for pages.
- Keep files under 300 lines. If a file grows larger, split it into focused modules.
- Co-locate related code: place a component's types, helpers, and tests near the component file.
Naming conventions
| Item | Convention | Example |
|---|---|---|
| Components | PascalCase | TaskCard.tsx |
| Utilities | camelCase | formatDate.ts |
| Convex functions | camelCase | listByProject.ts |
| CSS variables | kebab-case | --color-primary |
| Environment vars | UPPER_SNAKE | CONVEX_URL |
| Directories | kebab-case | schema-design/ |
Pull request workflow
- Create a branch from
mainusing the pattern<type>/<short-description>(e.g.,feat/task-list). - Keep PRs small — aim for fewer than 400 changed lines.
- Write a summary in the PR body that explains why, not just what.
- Request at least one reviewer. Address feedback with new commits, not force-pushes.
- Squash-merge into
mainonce approved.
Commit messages
- Use present tense: "Add task list" not "Added task list".
- Start with a verb:
Add,Fix,Update,Remove,Refactor. - Keep the first line under 72 characters.
Add real-time task list with optimistic updates
Introduces a TaskList component that subscribes to tasks via useQuery
and applies optimistic updates on create and delete.
Testing standards
- Write unit tests for utility functions and Convex query/mutation logic.
- Use React Testing Library for component tests; avoid testing implementation details.
- Name test files with
.test.tsor.test.tsxsuffixes alongside the source file.
Documentation requirements
- Every new page or feature should have a corresponding MDX doc in
app/docs/. - Update the sidebar navigation when adding new doc pages.
- Include at least one code example per doc page.
Accessibility
- All interactive elements must be keyboard accessible.
- Use semantic HTML (
<nav>,<main>,<section>) over generic<div>wrappers. - shadcn/ui components are built on Radix, which provides ARIA roles by default — do not strip them.