AmirReza Jamali
5ef0298840
- Added new ResetPasswordModalContent component for displaying generated passwords. - Integrated reset password functionality in the AdminsTable and CustomersTable components, allowing users to reset passwords for admins and customers. - Created useResetPasswordModalPresenter hook to manage password visibility and clipboard copying. - Updated API services and hooks to support reset password requests for both admins and customers. - Enhanced tooltip functionality for reset password actions in the tables.
25 lines
2.2 KiB
Markdown
25 lines
2.2 KiB
Markdown
@AGENTS.md
|
|
|
|
# Engineering Guidelines & Rules
|
|
|
|
## 1. Architecture & Component Structure
|
|
|
|
- **Strict Presenter/Container Pattern:** `.tsx` files must act strictly as view components containing _only_ JSX/TSX elements and styling markup.
|
|
- **Decoupled Logic:** Absolutely no business logic, state management, or side effects are allowed directly inside a `.tsx` file.
|
|
- **Hook-Based Presenters:** All logic, event handlers, and data fetching must live in a custom React hook (Presenter) located in a sibling file directly next to the `.tsx` file (e.g., `CreateAdmin.tsx` paired with `useCreateAdminPresenter.ts`).
|
|
- **Compound Components Pattern:** When building complex or configurable UI components (like forms, dropdowns, tables, or tabs), prefer the Compound Components pattern. Provide a main container component and context-connected sub-components (e.g., `<Form>`, `<Form.Input>`, `<Form.Submit>`) to allow flexible layout assembly while keeping the logic encapsulated.
|
|
|
|
## 2. Code Quality & DRY Principle
|
|
|
|
- **Zero Duplication:** Strict adherence to the DRY (Don't Repeat Yourself) principle.
|
|
- **Refactoring First:** If a piece of logic, utility, configuration, or UI structure is needed in more than one place, it must be extracted into a reusable helper, hook, or shared component. Do not allow even a single instance of copy-pasted or identical code structures.
|
|
|
|
## 3. Software Engineering Design
|
|
|
|
- **SOLID Principles:** All code written must strictly adhere to SOLID design principles:
|
|
- **Single Responsibility (SRP):** Each class, hook, or component must have exactly one reason to change (e.g., views only render, presenters only manage state/logic).
|
|
- **Open/Closed (OCP):** Software entities should be open for extension, but closed for modification.
|
|
- **Liskov Substitution (LSP):** Subtypes must be completely substitutable for their base types.
|
|
- **Interface Segregation (ISP):** Clients should not be forced to depend on interfaces they do not use. Keep hooks and component props lean and focused.
|
|
- **Dependency Inversion (DIP):** Depend on abstractions, not concretions. Pass dependencies (like API clients or services) into hooks or use context where appropriate rather than hardcoding them.
|