Frontend Code Standards

Opinionated code standards for building scalable, maintainable front-end applications with React, TypeScript, and Clean Architecture principles.

🎯 Token Budget Guide

Quick tasks (50-150 tokens):

• •Naming lookup → quick-ref/naming-cheatsheet.md
• •Simple validation → Pick specific rule from navigation below

Medium tasks (200-500 tokens):

• •New component → rules/react-naming.md + rules/react-component-structure.md
• •Helper function → rules/helper-function-patterns.md
• •TypeScript types → rules/typescript-best-practices.md

Complex tasks (500-1000 tokens):

• •Architecture refactor → rules/clean-architecture.md + rules/solid-principles.md
• •Performance optimization → rules/dom-performance.md + rules/caching-strategies.md
• •Clean Code review → rules/clean-code-principles.md + rules/solid-principles.md

🚀 Auto-Trigger Patterns

This skill should be loaded when:

• •Creating .tsx, .ts, .jsx, or .js files in a React project
• •User mentions: "component", "create", "refactor", "naming", "structure"
• •Code review or standards discussion
• •User mentions: "SOLID", "Clean Code", "Clean Architecture", "DDD"
• •Performance optimization tasks
• •User mentions: "TypeScript", "types", "interfaces"

File patterns that trigger specific rules:

• •*.tsx → Load react-naming.md + react-component-structure.md
• •Helper/utility files → Load helper-function-patterns.md
• •Domain/entity files → Load ddd-naming.md + clean-architecture.md
• •Performance issues → Load dom-performance.md + caching-strategies.md

Keywords: component, naming, convention, structure, SOLID, SRP, DRY, architecture, Clean Code, TypeScript, interface, type, helper, utility, performance, optimization

Navigate to specific topics:

📝 Naming Conventions

React Naming

→ See rules/react-naming.md

Use when:

• •Creating React components
• •Setting up hooks
• •Organizing component folders

Covers:

• •Component naming (PascalCase)
• •Hook naming (camelCase with 'use' prefix)
• •Feature directories (kebab-case)
• •Composite component folders

⚛️ React Component Structure

→ See rules/react-component-structure.md

Use when:

• •Creating React components
• •Refactoring component files
• •Deciding where to place helper functions

Covers:

• •Function declarations vs const (avoid React.FC)
• •Single Responsibility Principle
• •Component file organization
• •When to extract helpers vs keep them inline
• •Anti-patterns (god components, mixing concerns)

TypeScript Naming

→ See rules/typescript-naming.md

Use when:

• •Defining types and interfaces
• •Creating utility functions or classes

Covers:

• •Types and interfaces (PascalCase)
• •Functional vs class-based utilities
• •File naming for utilities

Domain-Driven Design Naming

→ See rules/ddd-naming.md

Use when:

• •Building domain layer (Clean Architecture)
• •Defining entities, value objects, aggregates
• •Creating repositories and use cases

Covers:

• •Entities and value objects (PascalCase)
• •Domain services and repositories
• •Aggregates and use cases
• •Ubiquitous language principles

📐 General Coding Standards

→ See rules/general-coding-standards.md

Use when:

• •Writing or reviewing any source code
• •Designing function signatures
• •Refactoring for readability

Covers:

• •Function design (naming, parameters, size)
• •Command-Query Separation
• •Control flow (early returns, avoiding deep nesting)
• •Code organization and style
• •Magic numbers, comments, variable scope

🛠️ Helper Function Patterns

→ See rules/helper-function-patterns.md

Use when:

• •Creating utility functions
• •Organizing formatters, validators, parsers, calculations
• •Deciding when to extract a helper

Covers:

• •Common helper categories (formatters, validators, parsers, guards)
• •Function design for helpers (pure functions, simple signatures)
• •Organization patterns (flat, categorized, barrel exports)
• •Testing helpers
• •Anti-patterns to avoid

🔷 TypeScript Best Practices

→ See rules/typescript-best-practices.md

Use when:

• •Writing TypeScript code
• •Choosing between type and interface
• •Deciding on type annotations

Covers:

• •Type safety (unknown vs any)
• •Type inference (when to skip return types)
• •Interface vs type guidelines
• •Utility types (Partial, Pick, Omit, etc.)
• •JSDoc documentation patterns

🧹 Clean Code Principles

→ See rules/clean-code-principles.md

Use when:

• •Writing any code
• •Creating functions
• •General refactoring

Covers:

• •Meaningful names (reveal intent)
• •Functions do one thing
• •Prefer exceptions over error codes
• •DRY (Don't Repeat Yourself)
• •Small functions (5-20 lines)
• •Avoid side effects (Command-Query Separation)

🔶 SOLID Principles

→ See rules/solid-principles.md

Use when:

• •Designing class hierarchies
• •Creating reusable components
• •Refactoring classes

Covers:

• •Single Responsibility Principle
• •Open/Closed Principle
• •Liskov Substitution Principle
• •Interface Segregation Principle
• •Dependency Inversion Principle

🏛️ Clean Architecture

→ See rules/clean-architecture.md

Use when:

• •Structuring application layers
• •Implementing domain-driven design
• •Separating business logic from frameworks

Covers:

• •Layer architecture (Entities, Use Cases, Adapters, Frameworks)
• •Dependency rules (dependencies point inward)
• •Framework independence
• •Testability patterns
• •Folder structure examples

⚡ JavaScript Performance

Performance optimization patterns for hot paths and frequently-executed code.

DOM & Browser

→ See rules/dom-performance.md

Use when working with DOM manipulation and browser APIs:

• •Layout thrashing prevention
• •Batching reads/writes

Caching Strategies

→ See rules/caching-strategies.md

Use when optimizing expensive operations:

• •Property access in loops
• •Repeated function calls
• •Storage API calls (localStorage, cookies)

Data Structures

→ See rules/data-structures.md

Use when choosing data structures for performance:

• •Index maps for repeated lookups
• •Set/Map for O(1) membership checks

Array Optimization

→ See rules/array-optimization.md

Use when working with arrays:

• •Combining multiple iterations
• •Early length checks for comparisons
• •Min/max without sorting
• •Immutable operations (toSorted)

Control Flow

→ See rules/control-flow-optimization.md

Use when optimizing function logic:

• •Early returns
• •RegExp hoisting
• •Guard clauses

Quick Reference

Naming Summary

Helper Categories

See helper-function-patterns.md for details.

Performance Quick Tips

DOM: Batch DOM reads/writes to avoid layout thrashing
Caching: Cache property access in loops, function results, storage APIs
Data Structures: Use Map/Set for O(1) lookups instead of Array.find()
Arrays: Combine iterations, check length before sorting, use toSorted()
Control Flow: Return early, hoist RegExp, use guard clauses