.cursorrules 5.6 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165
  1. ## 🧑‍💻 Development Guidelines
  2. This project follows **Next.js (App Router)** and is structured using **Feature-Sliced Design (FSD)** for modularity, scalability, and clear
  3. separation of concerns.
  4. Use this prompt and coding standards to ensure consistency across the codebase:
  5. ---
  6. ### 🔧 Code Style and Structure
  7. - Write concise, expressive, and idiomatic **TypeScript**
  8. - Use **functional programming** patterns (avoid classes and side effects)
  9. - Prefer **composition** over inheritance, and modularization over duplication
  10. - Organize each `feature/`, `entity/`, or `widget/` with:
  11. - model/ → logic (React Query, actions, hooks)
  12. - schema/ → Zod schemas for validation ui/ → client components (TSX)
  13. - lib/ → pure helper functions
  14. - types/ → interfaces & TS types
  15. - All external dependencies (**API**, `localStorage`, `Date`) must be **abstracted** in `shared/lib/`
  16. - Avoid direct calls to:
  17. - `fetch` → use actions or `shared/api/`
  18. - `new Date()` → use `shared/lib/date` abstraction
  19. - `localStorage` → wrap in `shared/lib/storage`
  20. ---
  21. ### 🧠 Naming Conventions
  22. - Use `kebab-case` for **directories** (e.g. `features/auth/signup`)
  23. - Use **named exports** (no default exports for components)
  24. - Use descriptive names with **auxiliary verbs** (e.g. `isLoading`, `hasError`, `canSubmit`)
  25. - Components:
  26. - Pure UI: `src/components/ui/`
  27. - Shared logic: `src/shared/lib/`
  28. - Composition: `src/widgets/`
  29. ---
  30. ### 📐 TypeScript Usage
  31. - Use `interface` over `type` for objects
  32. - Avoid `enum`; use `as const` object maps instead
  33. - Use `infer` and `z.infer<typeof schema>` for accurate form types
  34. - Types live in `types/` or colocated with usage
  35. ---
  36. ### 📦 Feature Architecture
  37. **Keep React component logic inside the relevant feature:**
  38. features/auth/signup/ ├── model/ → useSignUp.ts, signup.action.ts ├── schema/ → signup.schema.ts ├── ui/ → signup-form.tsx
  39. If reusable between many features (e.g. `User`, `Link`, `Session`), move logic to `entities/`.
  40. ---
  41. ### 🧪 Error Handling & Validation
  42. - Use **Zod** for schema validation
  43. - Prefer early returns & guard clauses
  44. - Use `ActionError` in server actions and handle them with `next-safe-action`
  45. - Wrap React components in `ErrorBoundary` (or `shared/ui/ErrorBoundaries.tsx`)
  46. - Display user-friendly errors via `toast()` or `<Alert />`
  47. ---
  48. ### 💅 UI & Styling
  49. - Use **Shadcn UI**, **Radix**, and **Tailwind CSS** with **mobile-first** responsive design
  50. - Design theme:
  51. - **Minimal**, professional with a **slightly playful touch**
  52. - Inspired by **Apple**, tailored to fitness coaches
  53. - Emphasize visuals: badges, progress bars, illustrations
  54. - Use `lucide-react` icons, subtle borders, hover feedback
  55. - Avoid drop shadows; prefer light borders and soft hover effects
  56. - Animations:
  57. - Elegant and performant (use `framer-motion` if needed)
  58. - Use `transition`, `duration-xxx`, and `ease-xxx` from Tailwind
  59. - UX Principles:
  60. - Clear hierarchy
  61. - Responsive: no overflow, no overlap
  62. - All buttons and interactive elements should provide feedback
  63. - Use @tailwind.config.ts for the theme.
  64. - **UI Stack**:
  65. - **Shadcn UI**, **Radix UI**, and **Tailwind CSS** (mobile-first approach)
  66. - Icons: **lucide-react**
  67. - **Design Language**:
  68. - 🎨 **Modern & minimalist**, inspired by **Apple’s design system**, with a **slightly more colorful palette**
  69. - Interface should be **clean**, **cohesive**, and **functional** without sacrificing features
  70. - Avoid drop shadows; prefer **subtle borders** where relevant
  71. - Ensure a **clear visual hierarchy** and **intuitive navigation**
  72. - **Interactive Components**:
  73. - Buttons and inputs must be **elegant**, with **subtle visual feedback** (hover, click, validation)
  74. - Use **addictive micro-interactions** sparingly to enhance engagement without clutter
  75. - **Animations**:
  76. - Use Tailwind’s built-in utilities: `transition`, `duration-xxx`, `ease-xxx` for basic transitions
  77. - Use `framer-motion` for advanced animations only if necessary
  78. - ✅ **Performance comes first**: animations must be smooth and lightweight
  79. - **Responsiveness**:
  80. - Fully responsive layout: **no overlapping**, **no overflow**
  81. - Consistent behavior across all devices, from mobile to desktop
  82. - **User Experience**:
  83. - All interactive elements must provide **clear visual feedback**
  84. - Interfaces should remain **simple to navigate**, even when **feature-rich**
  85. ---
  86. ### 🧱 Rendering & Performance
  87. - Favor **Server Components** (`RSC`) and SSR for pages and logic
  88. - Limit `'use client'` usage — only where needed:
  89. - form states, event listeners, animations
  90. - Wrap all client components in `<Suspense />` with fallback
  91. - Use dynamic import for non-critical UI (e.g. `Dialog`, `Chart`)
  92. - Optimize media:
  93. - Use **WebP** images with width/height
  94. - Enable lazy loading where possible
  95. ---
  96. ### 🔍 Data, Forms, Actions
  97. - Use `@tanstack/react-query` for client state
  98. - Use `next-safe-action` for server mutations and queries
  99. - All actions should:
  100. - Have clear schema (`schema/`)
  101. - Model expected errors with `ActionError`
  102. - Return typed output
  103. - Use the clientAction from `@/shared/api/safe-actions`
  104. - Use `Form`, `FormField`, `FormMessage` from Shadcn for all forms
  105. ---
  106. ### 🧭 Routing & Navigation
  107. - All routes defined in `app/`, avoid logic here
  108. - Use constants in `shared/constants/paths.ts`
  109. - For search parameters, use `nuqs` (`useQueryState`) — never manipulate `router.query` directly
  110. - Follow Next.js App Router standards for layouts and segments
  111. ---
  112. - [Feature-Sliced Design](https://feature-sliced.design/)
  113. - [Shadcn UI](https://ui.shadcn.com/)
  114. - [Zod](https://zod.dev/)