Match Maker Web

Problem Statement

Matching/dating platforms live or die on their frontend: a polished, reusable component system (avatars, cards, message bubbles, forms), clean auth flows, and an architecture that can absorb a real backend later without being rewritten. Most prototypes throw this together ad-hoc and collapse the moment the feature set grows.

Proposed Solution

Match Maker Web is a production-ready React frontend for connecting people through intelligent matching — built deliberately as a scalable, feature-based application with a reusable UI library, strict TypeScript, a full testing harness, and a clean API boundary so the backend can be plugged in without touching feature code.

Full Solution Details

• Reusable UI library — generic components (Avatar, Card, MessageBubble, form inputs) under ui/components, with an icon export layer.
• Auth feature — nested sub-features for login and signup with their own routes.
• Entrypoint — landing/home pages.
• Server-state ready — TanStack Query wired for async/server-state caching against a shared API client.
• Testing — mock data + factories in a dedicated testing/ folder, full Jest + React Testing Library setup.

Technical Documentation

React 18 + TypeScript 5.3 (strict) + Vite 5, React Router v6, TanStack Query v5, Tailwind 3.4. The architecture is feature-based with recursive nesting — a feature (auth) can itself contain sub-features (login, signup), each owning its routes — alongside shared/ (api, constants, types, utils), a ui/ component+icon layer, and a testing/ layer with mock factories. TypeScript path aliases (@web, @shared, @features, @ui) keep imports clean. Quality is enforced end-to-end: ESLint 8 + TypeScript-ESLint, Prettier 3, format-on-save VSCode config, and a build step that runs tsc type-checking before bundling. Tests use Jest 29 + RTL 14 + ts-jest + jsdom.

Tech Stack

React 18, TypeScript 5.3, Vite 5, React Router v6, TanStack Query v5, Tailwind CSS, react-icons; Jest 29, React Testing Library, ts-jest, jsdom; ESLint, Prettier.

System Design

src/
 ├── features/
 │     auth/  ──► features/{login, signup} (+ routes)   # recursive feature nesting
 │     entrypoint/ (landing/home)
 ├── shared/   api · constants · types · utils
 ├── ui/       components (Avatar, Card, MessageBubble, forms) · icons
 └── testing/  mocks + factories
   path aliases: @web @shared @features @ui
   build: tsc type-check → Vite production bundle

Smart Architectural Decisions

• Recursive feature nesting. Letting a feature own sub-features (auth → login/signup) keeps even compound flows self-contained, which is a more scalable take on Feature-Sliced Design than a flat feature list.
• API boundary first. A shared API client + TanStack Query layer means the UI is built against a typed contract, so a real backend slots in without rewriting components — "ready for backend integration" by design.
• Testing as a first-class folder. A dedicated testing/ layer with mock factories (not scattered fixtures) signals tests were planned, not bolted on.
• Strict quality gates. strict TS, ESLint+Prettier, and a type-checked build keep a UI-heavy codebase honest.

Impacts

A scalable, fully-typed, test-backed React frontend for a matching platform with a reusable component library — structured so the matching backend can be integrated cleanly later.

Demonstrated Skills

Scalable React architecture (recursive feature-based structure, path aliases); design-system/component-library thinking; TanStack Query server-state modeling against a typed API boundary; testing discipline (Jest + RTL + mock factories); strict TypeScript and tooling (ESLint/Prettier/typed builds); Tailwind UI.