Frontend Architecture
Relevant source files
The following files were used as context for generating this wiki page:
Introduction
The lexwebapp frontend architecture is a modern, modular React application designed for scalability, maintainability, and high performance. It was transitioned from a monolithic "God Component" structure (the original ChatLayout) into a clean architecture based on separation of concerns. The system utilizes React Router for navigation, a centralized Service Layer for API interactions, and a robust state management strategy combining React Query for server state and Zustand for local persistence.
The architecture is organized into distinct layers: Routing & Layout, Service Layer, State Management, and a custom UI Component Library. This structure ensures type-safety across the application using TypeScript and provides a consistent user experience through a dedicated design system.
Sources: lexwebapp/COMPLETE_REFACTORING_SUMMARY.md:1-50, lexwebapp/REFACTORING_SUMMARY.md:5-20
Architectural Overview
The application follows a hierarchical structure where providers wrap the main routing logic, which then distributes concerns into specific layouts and feature-based pages.
This diagram illustrates the component hierarchy and data flow from the root App component through the authentication and layout layers to individual feature pages.
Sources: lexwebapp/COMPLETE_REFACTORING_SUMMARY.md:175-200, lexwebapp/REFACTORING_SUMMARY.md:38-60
Core Layers
1. Routing and Navigation
The architecture utilizes react-router-dom for URL-based navigation, replacing previous state-based view switching. This enables deep linking, browser history support, and SEO improvements.
- Router Configuration: Centralized in
router/index.tsx. - Auth Guard: A wrapper component (
AuthGuard.tsx) that protects routes and redirects unauthenticated users to/login. - Main Layout: A structural component (
MainLayout.tsx) containing common UI elements like the Sidebar and Header.
Sources: lexwebapp/REFACTORING_SUMMARY.md:10-35, lexwebapp/MIGRATION_GUIDE.md:10-40
2. Service Layer
The Service Layer centralizes all API logic, abstracting the details of HTTP requests from the UI components. It uses an abstract BaseService to provide common functionality such as error handling and response parsing.
| Service | Purpose | Key Methods |
|---|---|---|
| LegalService | AI legal advice and court search | getLegalAdvice, searchCourtCases |
| AuthService | User authentication and profiles | getMe, updateProfile, logout |
| BillingService | Financial transactions and balance | getBalance, createStripePayment |
| ClientService | Client data management | getClients, createClient, sendMessage |
Sources: lexwebapp/SERVICE_LAYER_GUIDE.md:10-60, lexwebapp/PHASE3_SUMMARY.md:110-150
3. State Management
The application employs a dual-state strategy to handle different types of data:
- Server State (React Query): Handles all asynchronous data fetching, caching, and synchronization with the backend. It provides 20+ query hooks for legal, auth, and billing data.
- Client State (Zustand): Manages local application state and persistence via
localStorage.chatStore: Manages message history.uiStore: Handles UI preferences (e.g., sidebar collapse).settingsStore: Stores user-specific settings.
Sources: lexwebapp/COMPLETE_REFACTORING_SUMMARY.md:80-110, lexwebapp/PHASE3_SUMMARY.md:210-230
Sequence diagram showing the flow of data from the UI through the Service Layer to the Backend.
Sources: lexwebapp/SERVICE_LAYER_GUIDE.md:230-260
UI Component Library (UI Kit)
The frontend includes a custom design system based on Tailwind CSS and Framer Motion. This library ensures visual consistency and accessibility (WCAG 2.1 AA compliant) across the platform.
Design Tokens
Design tokens are centralized in constants/design-tokens.ts, defining:
- Colors: Primary, success, error, and semantic palettes.
- Spacing: An 8px base scale.
- Typography: Font families, weights, and sizes.
Primary Components
| Component | Key Features |
|---|---|
| Button | 5 variants, 3 sizes, loading states, icon support. |
| Input | 3 variants, validation error states, icon support. |
| Card | Elevated, outlined, and default variants with header/footer composition. |
| Modal | 5 sizes, focus trap, animated transitions, backdrop lock. |
| Badge | Status indicators with dot variants (success, info, warning, error). |
Sources: lexwebapp/UI_KIT_GUIDE.md:1-100, lexwebapp/PHASE5_SUMMARY.md:10-80
Data Models and Type System
The application uses a strict TypeScript type system to ensure data integrity from the API to the UI.
Class diagram of core domain models used across services and components.
Sources: lexwebapp/PHASE3_SUMMARY.md:155-175, lexwebapp/SERVICE_LAYER_GUIDE.md:120-140
Build and Deployment
The project uses Vite for development and production builds. The deployment process is containerized using Docker, with multi-stage builds that produce optimized static assets served via Nginx.
- Build Time: Approximately 2.93s.
- Environment Support: Separate configurations for development, staging, and production.
- Vite Features: Code splitting, tree shaking, and hot module replacement (HMR).
Sources: lexwebapp/COMPLETE_REFACTORING_SUMMARY.md:140-160, lexwebapp/PHASE5_SUMMARY.md:230-245
Summary
The lexwebapp frontend architecture represents a shift toward modern web standards, prioritizing modularity and type safety. By decoupling UI from business logic through the Service Layer and leveraging React Query for efficient data management, the platform achieves high performance and maintainability. The inclusion of a robust UI Kit and comprehensive documentation ensures that the application can scale effectively as new legal features are added.