361 lines
6.6 KiB
Markdown
361 lines
6.6 KiB
Markdown
# Frontend Refactoring & UI Standardization Prompt
|
||
|
||
Act as a world-class Senior Frontend Architect, UI Engineer, and Design System expert. Your objective is to refactor and standardize the entire frontend application to production-grade quality by following industry best practices, scalable architecture, and clean code principles.
|
||
|
||
## Primary Goal
|
||
|
||
Transform the existing application into a clean, maintainable, reusable, responsive, and highly consistent frontend without changing any business logic or existing functionality.
|
||
|
||
---
|
||
|
||
# 1. Frontend Architecture
|
||
|
||
Implement a scalable frontend architecture by following feature-based organization.
|
||
|
||
- Organize code into reusable modules.
|
||
- Separate business logic from UI.
|
||
- Keep components focused on a single responsibility.
|
||
- Avoid duplicated logic throughout the application.
|
||
- Create a clear folder structure.
|
||
- Use shared utilities wherever possible.
|
||
- Follow feature-first architecture instead of dumping everything into common folders.
|
||
|
||
---
|
||
|
||
# 2. Code Standards
|
||
|
||
Enforce strict coding standards throughout the project.
|
||
|
||
- No component should exceed **500 lines of code**.
|
||
- Prefer keeping components between **150–300 lines** whenever possible.
|
||
- Split large pages into smaller reusable components.
|
||
- Extract repeated JSX into reusable components.
|
||
- Extract repeated logic into custom hooks.
|
||
- Move API logic into service files.
|
||
- Move constants into dedicated constant files.
|
||
- Move validation into separate files.
|
||
- Move helper functions into utility files.
|
||
|
||
---
|
||
|
||
# 3. DRY Principles
|
||
|
||
Strictly follow the DRY (Don't Repeat Yourself) principle.
|
||
|
||
- Remove duplicated UI.
|
||
- Remove duplicated styles.
|
||
- Remove duplicated business logic.
|
||
- Remove duplicated API calls.
|
||
- Reuse existing components instead of recreating them.
|
||
- Centralize repeated logic.
|
||
|
||
---
|
||
|
||
# 4. Reusable Component Library
|
||
|
||
Create reusable components for all common UI patterns.
|
||
|
||
Examples include:
|
||
|
||
- Button
|
||
- Input
|
||
- Textarea
|
||
- Select
|
||
- Multi Select
|
||
- Search Input
|
||
- Date Picker
|
||
- Combobox
|
||
- Modal
|
||
- Drawer
|
||
- Dialog
|
||
- Confirmation Dialog
|
||
- Table
|
||
- Pagination
|
||
- Badge
|
||
- Card
|
||
- Empty State
|
||
- Loading State
|
||
- Skeleton
|
||
- Avatar
|
||
- Tooltip
|
||
- Popover
|
||
- Dropdown
|
||
- Tabs
|
||
- Accordion
|
||
- Alert
|
||
- Toast
|
||
- Breadcrumb
|
||
- Status Badge
|
||
- Section Header
|
||
- Form Field Wrapper
|
||
- Page Header
|
||
- Filter Panel
|
||
- Search Bar
|
||
- Action Buttons
|
||
- Data Cards
|
||
|
||
Every page should utilize these common components instead of creating new ones.
|
||
|
||
---
|
||
|
||
# 5. Typography System
|
||
|
||
Create a consistent typography system across the application.
|
||
|
||
Current typography appears oversized. Refine it to create a more professional enterprise UI.
|
||
|
||
Standardize:
|
||
|
||
- Font Family
|
||
- Font Size
|
||
- Font Weight
|
||
- Line Height
|
||
- Letter Spacing
|
||
|
||
Suggested scale:
|
||
|
||
- Page Title: 24px
|
||
- Section Title: 20px
|
||
- Card Title: 18px
|
||
- Table Header: 13px
|
||
- Body Text: 14px
|
||
- Secondary Text: 13px
|
||
- Labels: 13px
|
||
- Input Text: 14px
|
||
- Button Text: 14px
|
||
- Caption: 12px
|
||
|
||
Maintain consistent typography across all screens.
|
||
|
||
---
|
||
|
||
# 6. Spacing System
|
||
|
||
Implement a consistent spacing system.
|
||
|
||
Standardize:
|
||
|
||
- Padding
|
||
- Margin
|
||
- Gap
|
||
- Section spacing
|
||
- Card spacing
|
||
- Form spacing
|
||
|
||
Avoid random spacing values throughout the application.
|
||
|
||
---
|
||
|
||
# 7. Component Sizing
|
||
|
||
Reduce oversized UI elements to create a cleaner, more compact enterprise application.
|
||
|
||
Update:
|
||
|
||
- Popup sizes
|
||
- Modal widths
|
||
- Dialog heights
|
||
- Table row heights
|
||
- Table header heights
|
||
- Form fields
|
||
- Buttons
|
||
- Dropdowns
|
||
- Cards
|
||
- Navigation
|
||
- Sidebar spacing
|
||
|
||
The interface should feel lightweight, balanced, and visually polished.
|
||
|
||
---
|
||
|
||
# 8. Tables
|
||
|
||
Refactor all tables to follow consistent standards.
|
||
|
||
Ensure:
|
||
|
||
- Compact row height
|
||
- Consistent header styling
|
||
- Uniform padding
|
||
- Better column spacing
|
||
- Proper alignment
|
||
- Responsive behavior
|
||
- Sticky headers where appropriate
|
||
- Reusable table component
|
||
- Pagination component
|
||
- Empty state
|
||
- Loading state
|
||
- Sort indicators
|
||
- Filter integration
|
||
|
||
---
|
||
|
||
# 9. Modal & Popup Standards
|
||
|
||
Standardize all modals.
|
||
|
||
Requirements:
|
||
|
||
- Consistent width
|
||
- Consistent padding
|
||
- Consistent header
|
||
- Consistent footer
|
||
- Standard button placement
|
||
- Responsive behavior
|
||
- Smooth animations
|
||
- Proper scroll handling
|
||
- Keyboard accessibility
|
||
- Reusable modal component
|
||
|
||
Avoid oversized dialogs.
|
||
|
||
---
|
||
|
||
# 10. Form Standards
|
||
|
||
All forms should follow a single design system.
|
||
|
||
Maintain consistency for:
|
||
|
||
- Label placement
|
||
- Required indicators
|
||
- Validation messages
|
||
- Error states
|
||
- Success states
|
||
- Disabled states
|
||
- Placeholder styles
|
||
- Input heights
|
||
- Border radius
|
||
- Focus styles
|
||
|
||
---
|
||
|
||
# 11. Color System
|
||
|
||
Centralize all colors.
|
||
|
||
Do not hardcode colors.
|
||
|
||
Use semantic color tokens such as:
|
||
|
||
- Primary
|
||
- Secondary
|
||
- Success
|
||
- Warning
|
||
- Error
|
||
- Info
|
||
- Background
|
||
- Surface
|
||
- Border
|
||
- Text Primary
|
||
- Text Secondary
|
||
|
||
---
|
||
|
||
# 12. Responsive Standards
|
||
|
||
Ensure the application is fully responsive.
|
||
|
||
Optimize for:
|
||
|
||
- Mobile
|
||
- Tablet
|
||
- Laptop
|
||
- Desktop
|
||
- Large screens
|
||
|
||
No layout should break across screen sizes.
|
||
|
||
---
|
||
|
||
# 13. Performance
|
||
|
||
Improve frontend performance.
|
||
|
||
- Lazy load pages.
|
||
- Lazy load heavy components.
|
||
- Memoize expensive computations.
|
||
- Avoid unnecessary re-renders.
|
||
- Optimize bundle size.
|
||
- Remove unused code.
|
||
- Optimize images and icons.
|
||
|
||
---
|
||
|
||
# 14. Accessibility
|
||
|
||
Follow accessibility best practices.
|
||
|
||
- Keyboard navigation
|
||
- Proper ARIA attributes
|
||
- Focus management
|
||
- Color contrast
|
||
- Semantic HTML
|
||
- Screen reader support
|
||
|
||
---
|
||
|
||
# 15. Folder Structure
|
||
|
||
Maintain a clean folder structure.
|
||
|
||
- components/
|
||
- features/
|
||
- hooks/
|
||
- layouts/
|
||
- pages/
|
||
- services/
|
||
- utils/
|
||
- constants/
|
||
- contexts/
|
||
- types/
|
||
- assets/
|
||
- styles/
|
||
|
||
Every folder should have a clear responsibility.
|
||
|
||
---
|
||
|
||
# 16. Naming Conventions
|
||
|
||
Use consistent naming conventions.
|
||
|
||
- PascalCase for components
|
||
- camelCase for variables and functions
|
||
- UPPER_SNAKE_CASE for constants
|
||
- Feature-based file organization
|
||
|
||
Avoid ambiguous names.
|
||
|
||
---
|
||
|
||
# 17. Styling Standards
|
||
|
||
Use a consistent styling approach.
|
||
|
||
- Prefer Tailwind utility classes.
|
||
- Extract repeated class combinations into reusable components or utilities.
|
||
- Avoid inline styles unless absolutely necessary.
|
||
- Maintain consistent border radius, shadows, spacing, and transitions.
|
||
|
||
---
|
||
|
||
# 18. Final Deliverables
|
||
|
||
Refactor the entire application to ensure:
|
||
|
||
- Clean architecture
|
||
- Maintainable codebase
|
||
- Reusable components
|
||
- Consistent typography
|
||
- Compact and polished UI
|
||
- Smaller, balanced popups and tables
|
||
- Unified spacing system
|
||
- Enterprise-grade design system
|
||
- Fully responsive layouts
|
||
- Improved performance
|
||
- Better accessibility
|
||
- Strict adherence to SOLID, DRY, KISS, and Clean Code principles
|
||
|
||
Do not change any business logic or application behavior. The objective is to improve code quality, maintainability, scalability, and visual consistency while preserving all existing functionality.
|