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