Production: component-decision-logging.vercel.app
Component Decision Log is deployed on Vercel from the main branch. The production deployment currently runs in safe preview mode without Firebase environment variables, which allows reviewers to explore the registry, component detail pages, protected form shell, validation flow, and local mock-backed data architecture without private credentials.
Component Decision Log is a frontend architecture portfolio project designed to show how reusable UI components can be documented, governed, reviewed, and evolved across engineering teams.
The project demonstrates:
- Typed domain modeling for component records, props, state, API contracts, accessibility notes, and architecture decisions
- Searchable and filterable component registry
- Component detail routes with decision history and contract documentation
- Multi-step component creation form
- React Hook Form and Zod validation
- TanStack Query query and mutation architecture
- Mock-to-Firestore data bridge
- Firebase Auth gate shell with safe local preview behavior
- Firestore seed script structure
- Jest and React Testing Library coverage
- GitHub Actions CI for linting, typechecking, testing, and production builds
- GSAP reveal animations with reduced-motion support
- Mobile-first responsive layouts and accessibility-focused UI primitives
The goal is to present the kind of frontend engineering maturity expected in production design-system, platform, and mobile/web architecture work.
| Area | Status |
|---|---|
| Vercel production deployment | Complete |
| GitHub Actions CI | Complete |
| Mock-backed component registry | Complete |
| Component detail routes | Complete |
| Multi-step component form | Complete |
| React Query data layer | Complete |
| Firebase client setup | Complete |
| Firebase Auth shell | Complete |
| Firestore bridge | Complete |
| Firestore seed script | Complete |
| GSAP animation layer | Complete |
| Mobile/accessibility pass | Complete |
| Live Firebase project configuration | Deferred |
| Edit existing component workflow | Future enhancement |
| Component analytics dashboard | Future enhancement |
The current production deployment intentionally uses mock-backed data so the application remains reviewable without exposing private Firebase credentials. Firebase and Firestore integration points are already structured and can be enabled by adding the appropriate environment variables.
Modern engineering teams often make important component-level decisions in scattered places: pull requests, Slack threads, design docs, Jira tickets, and tribal knowledge. This project centralizes those decisions into a searchable, structured decision log.
The goal is to demonstrate production-minded frontend engineering through:
- Strong TypeScript modeling
- Accessible UI patterns
- Search and filtering
- Data fetching architecture
- Firebase-backed persistence
- Auth-gated workflows
- Form validation
- Skeleton loading states
- Responsive layouts
- Automated testing
- GitHub Actions CI
- Professional documentation
Screenshots will be added after the final production visual pass.
Planned screenshots:
| View | Purpose |
|---|---|
| Command Center | Shows the project concept and visual direction |
| Component Registry | Shows search, filtering, status, and component governance |
| Component Detail Page | Shows props, state, API contracts, decisions, and accessibility notes |
| New Component Form | Shows the multi-step creation and validation workflow |
| Local Preview Auth Gate | Shows safe Firebase fallback behavior |
- Dashboard overview
- Searchable component registry
- Component status, category, owner, and platform metadata
- Component detail pages
- Props and state documentation
- API contract documentation
- Decision log timeline
- Related components panel
- Accessibility notes section
- Add/edit component form
- Zod validation
- Responsive design
- Skeleton loading states
- Firebase Authentication
- Firestore-backed component records
- TanStack Query data fetching and cache invalidation
- Settings/export view
- GitHub Actions CI workflow
- Jest unit tests
- React Testing Library component tests
- GSAP animation polish
- Vercel deployment
| Technology | Purpose |
|---|---|
| Next.js App Router | Application routing and page structure |
| TypeScript | Strict type safety and domain modeling |
| TailwindCSS | Responsive styling and design system |
| Firebase Auth | Authentication gate |
| Firestore | Component decision data persistence |
| TanStack Query | Data fetching, caching, and mutation management |
| React Hook Form | Form state management |
| Zod | Runtime validation and typed schemas |
| Jest | Unit testing |
| React Testing Library | Component behavior testing |
| GitHub Actions | CI pipeline |
| GSAP | Professional animation polish |
| Vercel | Deployment |
This project is intentionally built with quality gates that mirror production frontend workflows.
| Quality Gate | Status |
|---|---|
| TypeScript strict modeling | In progress |
| Accessible UI primitives | In progress |
| Form validation with Zod | Added |
| Unit tests | Added |
| Component rendering tests | Added |
| GitHub Actions CI | Added |
| Responsive layouts | In progress |
| Skeleton and empty states | Added |
| Firebase Auth | Planned |
| Firestore persistence | Planned |
| TanStack Query data layer | Planned |
| Vercel deployment | Planned |
Component Decision Log uses a Purple / Black / Turquoise visual system.
The UI should feel:
- Premium
- Architect-level
- Enterprise-product ready
- Smooth but not overanimated
- Distinct from previous Orange / Black / Gold portfolio projects
This project is intentionally structured to show frontend engineering discipline.
- Keep UI primitives separate from feature-specific components
- Keep data access isolated from page components
- Use typed domain models before introducing Firestore
- Prefer semantic HTML and accessible interactions
- Validate form data with schemas
- Use testable utility functions for filtering/search behavior
- Treat the README as a living architecture document
The registry reads through TanStack Query hooks rather than importing data directly into UI components. This keeps the rendering layer decoupled from the persistence layer.
Registry UI
→ TanStack Query
→ Component query hooks
→ Firestore when configured
→ Mock data fallback when not configured
## Planned Folder Structure
```txt
src
app
/(auth)
/(dashboard)
layout.tsx
page.tsx
globals.css
components
layout
ui
component-log
forms
features
auth
components
lib
firebase
query
utils
data
mock-components.ts
tests
setup.tsThe main domain object is a ComponentRecord.
Each component record will include:
- Name
- Slug
- Summary
- Category
- Status
- Owner
- Platform
- Tags
- Props
- State
- API contract
- Decision history
- Related components
- Accessibility notes
- Created and updated timestamps
Accessibility is a core requirement, not an afterthought.
This project will include:
- Semantic page landmarks
- Skip link
- Proper heading hierarchy
- Visible focus states
- Keyboard-accessible navigation
- Labeled form controls
- Accessible validation errors
- Status labels that do not rely on color alone
- Reduced motion support
- Screen-reader-friendly loading and empty states
Component Decision Log is structured to support Firebase Auth and Firestore persistence while still allowing the project to run safely in local development, CI, and portfolio review environments without private Firebase credentials.
The app uses Firebase for:
| Area | Purpose |
|---|---|
| Firebase Auth | Protecting create/edit workflows |
| Firestore | Persisting component records |
| Firebase Admin SDK | Optional seed script for populating Firestore |
| Environment variables | Keeping credentials out of source control |
The Firebase client is initialized lazily so the app does not crash during CI or local preview when Firebase environment variables are missing.
When Firebase environment variables are not configured, protected routes remain visible in a safe preview mode.
For example:
/components/newwill show a local-preview notice and still render the form. This allows reviewers to inspect the full form experience without needing access to private Firebase credentials.
When Firebase is configured, the same route becomes auth-gated and requires Google sign-in before users can manage component records.
Create a local environment file:
cp .env.example .env.localThen add your Firebase web app values:
NEXT_PUBLIC_FIREBASE_API_KEY=
NEXT_PUBLIC_FIREBASE_AUTH_DOMAIN=
NEXT_PUBLIC_FIREBASE_PROJECT_ID=
NEXT_PUBLIC_FIREBASE_STORAGE_BUCKET=
NEXT_PUBLIC_FIREBASE_MESSAGING_SENDER_ID=
NEXT_PUBLIC_FIREBASE_APP_ID=These values are intentionally prefixed with NEXT_PUBLIC_ because they are used by the browser-side Firebase client.
Private environment files are ignored by Git:
.env.local
.env.seed.localThe repository only commits safe templates:
.env.example
.env.seed.exampleTo seed Firestore with the included mock component records, create:
cp .env.seed.example .env.seed.localThen configure:
FIREBASE_PROJECT_ID=
FIREBASE_SERVICE_ACCOUNT_BASE64=
COMPONENT_SEED_COLLECTION=componentsFIREBASE_SERVICE_ACCOUNT_BASE64 should contain a base64-encoded Firebase service account JSON file. The raw service account file should never be committed.
Component records currently move through a mock-to-Firestore bridge.
Component Registry UI
→ TanStack Query
→ Component query hooks
→ Firestore when configured
→ Mock data fallback when not configuredForm submission follows the same pattern:
Component Form
→ React Hook Form
→ Zod validation
→ ComponentRecord creation
→ TanStack Query mutation
→ Firestore save when configured
→ Local preview success when not configured
→ Query cache updateThis keeps UI components decoupled from the persistence layer. The registry and form do not need to know whether records are coming from mock data or Firestore.
The primary Firestore collection is:
componentsEach document stores a ComponentRecord with fields such as:
id
name
slug
summary
status
category
platform
owner
props
state
apiContract
decisions
relatedComponentIds
accessibilityNotes
createdAt
updatedAtAfter Firebase Admin credentials are configured, seed Firestore with:
npm run seed:componentsThe seed script writes the current mock component records into the configured Firestore collection using merge behavior, so existing documents with the same IDs can be updated safely.
This project includes a growing automated test suite focused on business logic, validation behavior, and user-visible component rendering.
Current test coverage includes:
- Component search and filtering utilities
- Component status, category, and platform formatting
- Component slug lookup
- Zod schema validation
- Form helper utilities
- Conversion between form values and component records
- Component status badge rendering
- Component card rendering
- Accessible text, links, headings, and status labels
Testing tools:
| Tool | Purpose |
|---|---|
| Jest | Unit and component test runner |
| React Testing Library | User-centered component testing |
| jest-dom | DOM-specific assertions |
Run tests:
npm run testRun coverage:
npm run test:coverageThis project uses GitHub Actions to run an automated quality pipeline on pushes and pull requests targeting main.
The CI workflow runs:
npm ci
npm run lint
npm run typecheck
npm run test -- --runInBand
npm run buildThe goal is to ensure that every change passes linting, TypeScript validation, automated tests, and a production build before being considered stable.
CI workflow file:
.github/workflows/ci.ymlInstall dependencies:
npm installRun the development server:
npm run devOpen the app:
http://localhost:3000- Scaffold Next.js project
- Establish README
- Configure strict TypeScript expectations
- Create theme foundation
- Build app shell
- Dashboard view
- Component list view
- Component detail view
- Settings/export view
- Skeleton and empty states
- Component types
- Mock data
- Search utilities
- Filter utilities
- Multi-step add/edit form
- React Hook Form setup
- Zod schema validation
- Accessible error states
- TanStack Query provider
- Firebase setup
- Firestore reads
- Firestore mutations
- Cache invalidation
- Firebase Auth
- Login view
- Auth guard
- Protected dashboard routes
- Jest setup
- React Testing Library setup
- Unit tests
- Component tests
- GitHub Actions CI
- GSAP motion polish
- Reduced motion handling
- README screenshots
- Vercel deployment
- Final lessons learned section
This section will be completed as the project evolves.
Planned reflection topics:
- Modeling frontend architecture decisions as data
- Designing accessible internal tools
- Managing form complexity with schemas
- Integrating Firestore with React Query
- Balancing animation polish with usability
- Building a CI-backed portfolio project
Current status: Initial setup in progress.