frontend-best-practices
Scannednpx machina-cli add skill lklimek/claudius/frontend-best-practices --openclawFiles (1)
SKILL.md
3.6 KB
Frontend Best Practices
Technical Standards
- Language: TypeScript with strict mode enabled
- Code Style: ESLint + Prettier, consistent with project config
- Type Safety: No
anytypes without explicit justification - Testing: Vitest or Jest with Testing Library, minimum 80% coverage
- Accessibility: axe-core automated checks, manual keyboard testing
- Performance: Lighthouse CI, bundle size budgets
- Documentation: One-line JSDoc for every public function; expand only for complex logic
Best Practices
- Semantic HTML elements over generic divs
- CSS custom properties for theming
- Component composition over prop drilling
- Lazy loading for code splitting
- Optimistic UI updates where appropriate
- Proper error boundaries and fallback UI
- Accessible forms with proper labels, error messages, focus management
- Progressive enhancement
Common Patterns
- State Management: React Context for simple state, Zustand/Jotai for complex; Redux only when justified
- Data Fetching: TanStack Query or SWR for server state, avoid raw useEffect
- Forms: React Hook Form or Formik with Zod/Yup schema validation
- Routing: Framework router (Next.js App Router, React Router, Vue Router)
- Styling: CSS Modules, Tailwind CSS, or styled-components — consistent with project
- Testing: Testing Library (query by role/label, not test IDs), MSW for API mocking
- Error Handling: Error boundaries per route/feature, toast for recoverable errors
Common Pitfalls
- Don't use
any— useunknownand narrow, or define proper types - Don't mutate state directly — return new references
- Don't fetch in useEffect without cleanup — use a data fetching library
- Don't skip
keyprops on lists or use array index as key for dynamic lists - Don't inline object/function literals in JSX props — causes re-renders
- Don't ignore
useEffectdependency arrays or suppress the lint rule - Don't use
dangerouslySetInnerHTMLwithout sanitization (XSS risk) - Don't store derived state — compute during render
- Don't forget
loading,error, andemptystates in data-driven components
Package.json
- Use
peerDependenciesfor shared framework deps in libraries - Keep
devDependenciesvsdependenciesaccurate - Audit with
npm auditorpnpm auditbefore releases
Design Quality
For high-fidelity UI work, invoke the frontend-design:frontend-design skill for design quality guidance.
Code Quality Tools
- Linting: ESLint with TypeScript plugin
- Formatting: Prettier
- Type Checking:
tsc --noEmit - Testing:
vitest run --coverage - Accessibility: eslint-plugin-jsx-a11y, axe-core
- Bundle Analysis: vite-plugin-visualizer or webpack-bundle-analyzer
Code Review Checklist
- TypeScript strict mode compliance, no unjustified
any - Component composition and prop management
- Accessibility: ARIA attributes, keyboard navigation, semantic HTML
- CSS/styling consistency and maintainability
- State management patterns appropriate to scope
- DRY compliance: duplicated components, repeated logic
- Naming clarity: components, hooks, utilities, types
- Performance: unnecessary re-renders, missing memoization, bundle size
- Test quality: component tests, user interaction tests, proper mocking
- Code brevity: flag code that can be expressed in fewer lines without losing clarity
Use FE-NNN prefix for all findings.
Source
git clone https://github.com/lklimek/claudius/blob/main/skills/frontend-best-practices/SKILL.mdView on GitHub Overview
Defines a TypeScript-first, accessibility-minded approach to building UI with React, Vue, or Svelte. It codifies standards for language, tooling, testing, performance, and documentation to improve consistency, quality, and maintainability across frontend code.
How This Skill Works
The skill enforces strict TypeScript (no implicit any), linting with ESLint/Prettier, and tests with Vitest or Jest (80%+ coverage). It also prescribes patterns for state management, data fetching, forms, routing, and styling, plus an architecture-friendly review checklist and automated accessibility checks.
When to Use It
- When starting a new frontend feature or component library
- During code reviews to enforce consistency and quality
- When refactoring for accessibility, performance, or maintainability
- Before releases to verify tooling, tests, and budgets
- When auditing an existing project for standardized practices
Quick Start
- Step 1: Enable TypeScript strict mode and align ESLint/Prettier with project config
- Step 2: Adopt patterns (Context or Zustand/Jotai for state, TanStack Query for server state, React Hook Form + Zod for forms) and implement semantic HTML
- Step 3: Set up automated accessibility checks (axe-core), tests (Vitest/Jest with Testing Library), and performance budgets (Lighthouse CI)
Best Practices
- Semantic HTML elements over generic divs
- CSS custom properties for theming
- Component composition over prop drilling
- Lazy loading for code splitting
- Accessible forms with proper labels, error handling, and focus management
Example Use Cases
- A React component written in TypeScript with strict mode, ESLint/Prettier, and no 'any'
- Replacing divs with semantic HTML and introducing CSS variables for theming across pages
- Using TanStack Query for data fetching instead of raw useEffect
- Adding axe-core automated checks and manual keyboard testing for accessibility
- Configuring Lighthouse CI and bundle size budgets before a release
Frequently Asked Questions
Add this skill to your agents