Eunjae LeeGitHubeunjae@cal.com <hey@eunjae.dev>cubic-dev-ai[bot] <191113872+cubic-dev-ai[bot]@users.noreply.github.com>Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com>cubic-dev-ai[bot] <191113872+cubic-dev-ai[bot]@users.noreply.github.com>* refactor: extract bookings list and calendar views with nuqs state management - Extract list-related code into BookingsListView component - Create empty BookingsCalendarView component for future implementation - Add nuqs query param state management for view toggle (defaults to list) - Update bookings-listing-view to conditionally render views - No visible changes to users (list view remains default) Co-Authored-By: eunjae@cal.com <hey@eunjae.dev> * refactor: move data fetching logic to parent component - Keep useFilterValue calls, trpc query, columns, flatData, bookingsToday, finalData, and table setup in parent component - BookingsListView now receives data as props instead of fetching it - This allows both list and calendar views to share the same data source Co-Authored-By: eunjae@cal.com <hey@eunjae.dev> * fix: add customView column back to render booking items The customView column was inadvertently removed during refactoring. This column is crucial as it renders the actual BookingListItem components, the "today" header, and the "next" header for the bookings list. Co-Authored-By: eunjae@cal.com <hey@eunjae.dev> * refactor: rename files for better clarity - Renamed bookings-listing-view.tsx → bookings-view.tsx (parent view) - Renamed bookings-list-view.tsx → BookingsList.tsx (list component) - Renamed bookings-calendar-view.tsx → BookingsCalendar.tsx (calendar component) - Moved list and calendar components from views/ to components/ directory - Updated all imports to reflect new structure This creates a clearer hierarchy where -view is the orchestrator and components are the renderers. Co-Authored-By: eunjae@cal.com <hey@eunjae.dev> * clean up implementation * clean up types * revert unnecessary changes * Update packages/features/data-table/GUIDE.md Co-authored-by: cubic-dev-ai[bot] <191113872+cubic-dev-ai[bot]@users.noreply.github.com> --------- Co-authored-by: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com> Co-authored-by: cubic-dev-ai[bot] <191113872+cubic-dev-ai[bot]@users.noreply.github.com>
Cal.com Development Guide for AI Agents
This directory contains comprehensive documentation for AI agents working on the Cal.com codebase.
Quick Navigation
- Commands - Build, test, and development commands
- Knowledge Base - Knowledge base & best practices
- Architecture Overview - System structure and patterns
Getting Started
Cal.com is a monorepo using Yarn workspaces and Turbo for build orchestration. The main application is in apps/web/ with shared packages in packages/.
Key Directories
apps/web/- Main Next.js applicationpackages/prisma/- Database schema and migrationspackages/trpc/- API layer using tRPCpackages/ui/- Shared UI componentspackages/features/- Feature-specific codepackages/app-store/- Third-party app integrations
Architecture Overview
Database Layer
- Prisma ORM with PostgreSQL
- Schema in
packages/prisma/schema.prisma - Always use
selectinstead ofincludefor better performance - Never expose
credential.keyfield in API responses
API Layer
- tRPC for type-safe APIs
- Routers in
packages/trpc/server/routers/ - Authentication handled via NextAuth.js
Frontend
- Next.js 13+ with App Router in some areas
- React 18 with TypeScript
- Tailwind CSS for styling
- Internationalization with
next-i18next
Common Patterns
Error Handling
- Use early returns to reduce nesting
- Throw descriptive errors with proper error codes
- Prefer composition over prop drilling
Performance
- Avoid O(n²) logic in backend code
- Minimize Day.js usage in performance-critical paths
- Use
selectqueries to only fetch needed data - Consider using
.utc()for Day.js operations
Security
- Never commit secrets or API keys
- Always validate input data
- Use proper authentication checks
- Never expose sensitive credential fields
Testing Strategy
- Unit tests with Vitest
- Integration tests for complex workflows
- E2E tests with Playwright
- Test files use
.test.tsor.spec.tsextensions
Pull Request Guidelines
For large PRs (>500 lines or >10 files):
- Split by feature boundaries
- Separate database migrations, backend logic, frontend components
- Create dependency chains that can be merged sequentially
- Pattern: Database → Backend → Frontend → Tests