# Modular Request Flow Architecture - Implementation Summary
## Overview
This document summarizes the implementation of a modular, plug-and-play architecture for handling different request flow types (CUSTOM and DEALER_CLAIM) in the application.
## What Was Implemented
### 1. Request Type Detection Utilities (`src/utils/requestTypeUtils.ts`)
Created centralized utilities for detecting and handling different request types:
- `isCustomRequest(request)` - Checks if a request is a custom request
- `isDealerClaimRequest(request)` - Checks if a request is a dealer claim request
- `getRequestFlowType(request)` - Returns the flow type ('CUSTOM' | 'DEALER_CLAIM')
- `getRequestDetailRoute(requestId, request?)` - Gets the appropriate route for request detail
- `getCreateRequestRoute(flowType)` - Gets the route for creating a new request
### 2. Global Navigation Utility (`src/utils/requestNavigation.ts`)
Created a single point of navigation logic for all request-related routes:
- `navigateToRequest(options)` - Main navigation function that handles:
- Draft requests (routes to edit)
- Different flow types
- Status-based routing
- `navigateToCreateRequest(navigate, flowType)` - Navigate to create request based on flow type
- `createRequestNavigationHandler(navigate)` - Factory function for creating navigation handlers
### 3. Modular Flow Structure (`src/flows/`)
Created a modular folder structure for different request flows:
```
src/flows/
├── custom/
│ └── index.ts # Exports Custom flow components
├── dealer-claim/
│ └── index.ts # Exports Dealer Claim flow components
├── shared/
│ └── components/ # Shared components (for future use)
└── index.ts # Flow registry and utilities
```
**Flow Registry** (`src/flows/index.ts`):
- `FlowRegistry` - Maps flow types to their modules
- `getFlowModule(flowType)` - Gets the flow module for a type
- `getOverviewTab(flowType)` - Gets the appropriate overview tab component
- `getWorkflowTab(flowType)` - Gets the appropriate workflow tab component
### 4. Updated RequestDetail Component
Modified `src/pages/RequestDetail/RequestDetail.tsx` to:
- Use flow type detection instead of hardcoded checks
- Dynamically load appropriate components based on flow type
- Support plug-and-play architecture for different flows
**Key Changes**:
- Replaced `isClaimManagementRequest()` with `getRequestFlowType()`
- Uses `getOverviewTab()` and `getWorkflowTab()` to get flow-specific components
- Maintains backward compatibility with existing components
### 5. Updated Navigation Throughout App
Updated all request card click handlers to use the global navigation utility:
**Files Updated**:
- `src/App.tsx` - Main `handleViewRequest` function
- `src/pages/ApproverPerformance/components/ApproverPerformanceRequestList.tsx`
- `src/pages/DetailedReports/DetailedReports.tsx`
All navigation now goes through `navigateToRequest()` for consistency.
## How to Use
### For Developers
### 1. Navigating to a Request
```typescript
import { navigateToRequest } from '@/utils/requestNavigation';
// In a component with navigate function
navigateToRequest({
requestId: 'REQ-123',
requestTitle: 'My Request',
status: 'pending',
request: requestObject, // Optional: helps determine flow type
navigate: navigate,
});
```
### 2. Getting Flow-Specific Components
```typescript
import { getOverviewTab, getWorkflowTab } from '@/flows';
import { getRequestFlowType } from '@/utils/requestTypeUtils';
const flowType = getRequestFlowType(request);
const OverviewTab = getOverviewTab(flowType);
const WorkflowTab = getWorkflowTab(flowType);
// Use in JSX
```
### 3. Detecting Request Type
```typescript
import {
getRequestFlowType,
isCustomRequest,
isDealerClaimRequest
} from '@/utils/requestTypeUtils';
// Check specific type
if (isDealerClaimRequest(request)) {
// Handle dealer claim specific logic
}
// Get flow type
const flowType = getRequestFlowType(request); // 'CUSTOM' | 'DEALER_CLAIM'
```
## Adding a New Flow Type
To add a new flow type (e.g., "VENDOR_PAYMENT"):
### Step 1: Update Type Definitions
```typescript
// src/utils/requestTypeUtils.ts
export type RequestFlowType = 'CUSTOM' | 'DEALER_CLAIM' | 'VENDOR_PAYMENT';
export function isVendorPaymentRequest(request: any): boolean {
// Add detection logic
return request.workflowType === 'VENDOR_PAYMENT';
}
export function getRequestFlowType(request: any): RequestFlowType {
if (isVendorPaymentRequest(request)) return 'VENDOR_PAYMENT';
if (isDealerClaimRequest(request)) return 'DEALER_CLAIM';
return 'CUSTOM';
}
```
### Step 2: Create Flow Folder
```
src/flows/vendor-payment/
└── index.ts
```
```typescript
// src/flows/vendor-payment/index.ts
export { VendorPaymentOverviewTab } from '@/pages/RequestDetail/components/tabs/VendorPaymentOverviewTab';
export { VendorPaymentWorkflowTab } from '@/pages/RequestDetail/components/tabs/VendorPaymentWorkflowTab';
```
### Step 3: Update Flow Registry
```typescript
// src/flows/index.ts
import * as VendorPaymentFlow from './vendor-payment';
export const FlowRegistry = {
CUSTOM: CustomFlow,
DEALER_CLAIM: DealerClaimFlow,
VENDOR_PAYMENT: VendorPaymentFlow,
} as const;
export function getOverviewTab(flowType: RequestFlowType) {
switch (flowType) {
case 'VENDOR_PAYMENT':
return VendorPaymentFlow.VendorPaymentOverviewTab;
// ... existing cases
}
}
```
### Step 4: Create Components
Create the flow-specific components in `src/pages/RequestDetail/components/tabs/`:
- `VendorPaymentOverviewTab.tsx`
- `VendorPaymentWorkflowTab.tsx`
## Benefits
1. **Modularity**: Each flow type is isolated in its own folder
2. **Maintainability**: Changes to one flow don't affect others
3. **Scalability**: Easy to add new flow types
4. **Consistency**: Single navigation utility ensures consistent routing
5. **Type Safety**: TypeScript ensures correct usage
6. **Reusability**: Shared components can be used across flows
## Migration Notes
### Backward Compatibility
- All existing code continues to work
- `isClaimManagementRequest()` still works (now uses `isDealerClaimRequest()` internally)
- Existing components are preserved and work as before
### Breaking Changes
None. This is a non-breaking enhancement.
## Testing
To test the new architecture:
1. **Test Custom Requests**:
- Create a custom request
- Navigate to its detail page
- Verify correct components are loaded
2. **Test Dealer Claim Requests**:
- Create a dealer claim request
- Navigate to its detail page
- Verify dealer claim-specific components are loaded
3. **Test Navigation**:
- Click request cards from various pages
- Verify navigation works correctly
- Test draft requests (should route to edit)
## Future Enhancements
- [ ] Add flow-specific validation rules
- [ ] Add flow-specific API endpoints
- [ ] Add flow-specific permissions
- [ ] Add flow-specific analytics
- [ ] Add flow-specific notifications
- [ ] Create shared request card component
- [ ] Add flow-specific creation wizards
## Files Created
1. `src/utils/requestTypeUtils.ts` - Request type detection utilities
2. `src/utils/requestNavigation.ts` - Global navigation utility
3. `src/flows/custom/index.ts` - Custom flow exports
4. `src/flows/dealer-claim/index.ts` - Dealer claim flow exports
5. `src/flows/index.ts` - Flow registry
6. `src/flows/shared/components/index.ts` - Shared components placeholder
7. `src/flows/README.md` - Flow architecture documentation
## Files Modified
1. `src/pages/RequestDetail/RequestDetail.tsx` - Uses flow registry
2. `src/App.tsx` - Uses navigation utility
3. `src/pages/ApproverPerformance/components/ApproverPerformanceRequestList.tsx` - Uses navigation utility
4. `src/pages/DetailedReports/DetailedReports.tsx` - Uses navigation utility
## Conclusion
The modular architecture is now in place and ready for use. The system supports plug-and-play flow types, making it easy to add new request types in the future while maintaining clean separation of concerns.