nextjs-react-tailwind-cursorrules-prompt-file

• You are an expert in TypeScript, Node.js, Next.js App Router, React, Shadcn UI, and Tailwind and Framer Motion.

• Code Style and Structure

  • Write concise, technical TypeScript code with accurate examples.
  • Use functional and declarative programming patterns; avoid classes.
  • Prefer iteration and modularization over code duplication.
  • Use descriptive variable names with auxiliary verbs (e.g., isLoading, hasError).
  • Structure files: exported component, subcomponents, helpers, static content, types.

• Naming Conventions

  • All components should go in src/components and be named like new-component.tsx
  • Use lowercase with dashes for directories (e.g., components/auth-wizard).
  • Favor named exports for components.

• TypeScript Usage

  • Use TypeScript for all code; prefer interfaces over types.
  • Avoid enums; use maps instead.
  • Use functional components with TypeScript interfaces.

• Syntax and Formatting

  • Use the "function" keyword for pure functions.
  • Avoid unnecessary curly braces in conditionals; use concise syntax for simple statements.
  • Use declarative JSX.

• UI and Styling

  • Use Shadcn UI, and Tailwind for components and styling.
  • Implement responsive design with Tailwind CSS; use a mobile-first approach.

• Performance Optimization

  • Minimize 'use client', 'useEffect', and 'setState'; favor React Server Components (RSC).
  • Wrap client components in Suspense with fallback.
  • Use dynamic loading for non-critical components.
  • Optimize images: use WebP format, include size data, implement lazy loading.

• Key Conventions

  • Use 'nuqs' for URL search parameter state management.
  • Optimize Web Vitals (LCP, CLS, FID).
  • Limit 'use client':
    • Favor server components and Next.js SSR.
    • Use only for Web API access in small components.
    • Avoid for data fetching or state management.
  • Follow Next.js docs for Data Fetching, Rendering, and Routing.
  • While creating placeholder images as a part of your seed data, use local fixtures or a stable project-approved image source instead of deprecated placeholder services.
  • Place both the /app and /components folders under a /src directory. This organization offers several benefits:
    • It helps maintain a clean and organized project structure.
    • It allows for easier navigation and management of components and pages.
    • It adheres to common industry standards, making it easier for other developers to understand and contribute to the project.
    • It provides a clear separation between application logic (in /src/app) and UI components (in /src/components), improving code readability and reusability.
    • It simplifies the process of creating new pages and components, as you can easily find the corresponding files in the /src directory.
    • It makes the project more modular and easier to scale as the application grows.
    • It adheres to the principle of separation of concerns, where different aspects of the application are handled by different directories.

Components Organization

Within the /src/components folder, consider organizing components by type or feature:

By Type: Group components like forms, buttons, layout elements, etc.

By Feature: For larger applications, group components related to specific features or domains

For example:

/src/components ├── /ui │ ├── /Button │ ├── /Modal │ └── /Card ├── /forms │ ├── /TextField │ └── /Select └── /layout ├── /Navbar └── /Footer

• Private Components: For components used only within specific pages, you can create a _components folder within the relevant /app subdirectory.

• Shared Components: The /src/components folder should contain reusable components used across multiple pages or features.

• Modular Approach: As your project grows, consider adopting a more modular structure, where each feature or domain has its own folder containing components, hooks, and utilities specific to that feature.