UI Page Structure and Organization
Defines a folder layout and component structure for UI pages built with Next.js App Router, GraphQL, and Carbon Design.
What this file does
Defines a folder layout and component structure for UI pages built with Next.js App Router, GraphQL, and Carbon Design.
When to use it
- Starting a new feature page in a Next.js app with CRUD modals
- Standardizing how GraphQL queries are separated from components
- Onboarding a team to a consistent page organization pattern
- Reviewing existing pages for structural consistency
Assumes this stack
trigger: glob globs: src-ui/app/**/*.tsx
UI Page Structure and Organization
This rule provides guidelines for structuring UI pages and components in the src-ui app directory.
Page Organization
Each feature page should follow this organization pattern:
src-ui/app/dash/[section]/[feature]/
├── page.tsx # Main page component
├── [feature].gql # GraphQL queries and mutations
├── add_[feature]_modal.tsx # Modal for adding new items
├── edit_[feature]_modal.tsx # Modal for editing items
└── delete_[feature]_modal.tsx # Modal for confirming deletion
Component Structure
Main Page Component
The main page.tsx should follow this structure:
- Import dependencies
- Define necessary types/interfaces
- Define main functional component
- Initialize state variables
- Define data transformation functions
- Define data fetching functions
- Define CRUD operation handler functions
- Define UI structure
- Include all modals as child components
- Export the component as default
GraphQL File
- Place all related GraphQL queries and mutations in a separate .gql file
- Never embed GraphQL strings directly in the component files
- Name queries and mutations consistently:
- Query: GetXxx, GetAllXxx, GetXxxById, etc.
- Mutation: CreateXxx, UpdateXxx, DeleteXxx
Modal Components
Each modal component should:
- Accept props for controlling visibility (isOpen)
- Accept props for the item being operated on
- Accept callback functions (onSave, onClose, onDelete)
- Handle its own form state
- Be focused on a single responsibility (add/edit/delete)
Design Patterns
- Use Carbon Design components for consistent UI
- Use DataTable component for list views
- Use modals for CRUD operations
- Implement proper loading states and error handling
- Maintain separation of concerns between components
- Follow TypeScript best practices for type safety
- Format dates, currency, etc. using the appropriate utility functions
Example Implementation
See existing implementations in:
- src-ui/app/dash/purchases/expenses
- src-ui/app/dash/sales/customers
What's inside
1 folder tree, 4 component breakdowns, 2 design patterns, 2 example paths
Change this for your project
- Replace
src-ui/app/dash/[section]/[feature]/with your own app directory path - Replace
Carbon Designreferences with your own UI library if different - Replace example paths
src-ui/app/dash/purchases/expensesandsrc-ui/app/dash/sales/customerswith your own
Where it goes
Save in docs/ or the repository root. Gives agents and new contributors a map of the codebase.
Related Documents
PCB Design Sources for Industry-Scale Testing
Lists GitHub repos and communities where you can download real PCB designs for testing optimization at scale.
Design Document: BharatSeva AI
Describes a 10-agent AWS system that helps India's informal workers access government schemes via voice-first, serverless architecture.
OpenClaw Enterprise Transformation Plan
Transforms a single-user AI agent into a dual-mode platform supporting both viral open-source and Fortune 500 enterprise deployments through phased security, IAM, audit, multi-tenancy, and Kubernetes features.
Qwen Image and Edit: Open-sourcing and Local GGUF Generations with Lightning
Documents the Qwen-Image and Qwen-Image-Edit models, covering architecture, training, benchmarks, ComfyUI setup, and prompting techniques for local GGUF deployment.