Frontend Technical Spec

Technical Design Rules (Frontend)

Prerequisite Detection

Inspect package.json, the lockfile, TypeScript/build configuration, CI definitions, and representative components before applying a tool- or framework-specific rule. Treat React, Vite, Next.js, a state library, form library, or script as available only when repository evidence names it. Label surrounding-pattern conclusions as inferred. When a missing decision changes rendering architecture, compatibility, security, or verification, stop and name the exact evidence or user decision required.

Basic Technology Stack Policy

These rules apply when repository configuration confirms a TypeScript-based React application. Select architecture by mapping current requirements and constraints to component responsibilities, state ownership, server/client boundaries, and observable verification points.

Environment Variable Management and Security

Environment Variable Management

• Use the build tool's client-exposure mechanism: Browser code can read only values explicitly exposed by the configured bundler/framework; server-only environment access remains outside client bundles
• Centrally manage environment variables through configuration layer
• Parse exposed values at one typed configuration boundary before application use
• Give a value a default only when requirements define valid behavior for absence; otherwise fail startup/build validation with the variable name and expected format

// Build tool environment variables (public values only; client-exposed vars need the VITE_ prefix)
const config = {
  apiUrl: import.meta.env.VITE_API_URL || 'http://localhost:3000',
  appName: import.meta.env.VITE_APP_NAME || 'My App'
}

// Does not work in frontend
const apiUrl = process.env.API_URL

Security (Client-side Constraints)

• CRITICAL: All frontend code is public and visible in browser
• Keep secrets server-side: Client-exposed configuration contains public values only; a backend or trusted service owns API keys, tokens, and credentials
• Keep local .env files outside version control and provide non-secret example files for required variable names
• Log and return only fields approved for the current trust boundary; redact passwords, tokens, and personal data

Correct Approach for Secrets:

// Security risk: API key exposed in browser
const apiKey = import.meta.env.VITE_API_KEY
const response = await fetch(`https://api.example.com/data?key=${apiKey}`)

// Correct: Backend manages secrets, frontend accesses via proxy
const response = await fetch('/api/data') // Backend handles API key authentication

Architecture Design

Frontend Architecture Patterns

React Component Architecture:

• Function Components: Mandatory; class components allowed solely for Error Boundaries (no hook equivalent)
• Custom Hooks: For logic reuse and dependency injection
• Component Hierarchy: Atoms -> Molecules -> Organisms -> Templates -> Pages
• Props-driven: Components receive all necessary data via props
• Co-location: Place tests, styles, and related files alongside components

Select a component/state pattern using these rules:

• Keep state local when one component subtree owns every read and write
• Use Context when multiple descendants require the same low-frequency state and the provider boundary is explicit
• Use a server-state library only when the configured dependency exists and caching, deduplication, background refresh, or request lifecycle state is required
• Introduce an additional state-management dependency only when current requirements cannot be covered by local state, reducer state, existing Context, or the repository's established state mechanism

State Management Patterns:

• Local State: useState for component-specific state
• Context API: For sharing state across component tree (theme, auth, etc.)
• Custom Hooks: Encapsulate state logic and side effects
• Server State: React Query or SWR for API data caching

Unified Data Flow Principles