|
| 1 | +# Configuration Architecture |
| 2 | + |
| 3 | +This document outlines the new modular configuration architecture for the Industry Core Hub Frontend. |
| 4 | + |
| 5 | +## Overview |
| 6 | + |
| 7 | +The configuration is now organized based on usage patterns: |
| 8 | + |
| 9 | +- **Shared Configuration**: Used by multiple features or the base application |
| 10 | +- **Feature-Specific Configuration**: Used by only one feature |
| 11 | + |
| 12 | +## Configuration Structure |
| 13 | + |
| 14 | +``` |
| 15 | +src/ |
| 16 | +├── config/ # Shared configuration |
| 17 | +│ ├── index.ts # Main config exports |
| 18 | +│ ├── types.ts # Shared types and interfaces |
| 19 | +│ └── base.ts # Base application configuration |
| 20 | +└── features/ |
| 21 | + ├── part-discovery/ |
| 22 | + │ └── config.ts # Part discovery specific config |
| 23 | + ├── catalog-management/ |
| 24 | + │ └── config.ts # Catalog management specific config |
| 25 | + ├── partner-management/ |
| 26 | + │ └── config.ts # Partner management specific config |
| 27 | + └── serialized-parts/ |
| 28 | + └── config.ts # Serialized parts specific config |
| 29 | +``` |
| 30 | + |
| 31 | +## Shared Configuration (`src/config/`) |
| 32 | + |
| 33 | +### Base Configuration (`base.ts`) |
| 34 | +- Application-wide settings |
| 35 | +- API base URL |
| 36 | +- Participant ID |
| 37 | +- Security configuration |
| 38 | +- Common utilities |
| 39 | + |
| 40 | +### Types (`types.ts`) |
| 41 | +- Shared interfaces and types |
| 42 | +- Re-exports from EnvironmentService |
| 43 | +- Base configuration interfaces |
| 44 | + |
| 45 | +## Feature-Specific Configuration |
| 46 | + |
| 47 | +Each feature module now contains its own `config.ts` file with: |
| 48 | + |
| 49 | +### API Configuration |
| 50 | +- Feature-specific endpoints |
| 51 | +- URL builders |
| 52 | +- Request/response configurations |
| 53 | + |
| 54 | +### Validation Rules |
| 55 | +- Form validation patterns |
| 56 | +- Business rules |
| 57 | +- Data constraints |
| 58 | + |
| 59 | +### UI Configuration |
| 60 | +- Table settings (page sizes, columns) |
| 61 | +- Form configurations |
| 62 | +- Component-specific settings |
| 63 | + |
| 64 | +### Feature-Specific Policies |
| 65 | +- Governance policies (Part Discovery) |
| 66 | +- DTR policies (Part Discovery) |
| 67 | +- Feature flags |
| 68 | + |
| 69 | +## Examples |
| 70 | + |
| 71 | +### Using Shared Configuration |
| 72 | +```typescript |
| 73 | +import { baseConfig, configUtils } from '../../config'; |
| 74 | + |
| 75 | +// Get base API URL |
| 76 | +const apiUrl = baseConfig.apiUrl; |
| 77 | + |
| 78 | +// Build full URL |
| 79 | +const fullUrl = configUtils.buildApiUrl('/my-endpoint'); |
| 80 | + |
| 81 | +// Check feature flag |
| 82 | +const isEnabled = configUtils.isFeatureEnabled('myFeature'); |
| 83 | +``` |
| 84 | + |
| 85 | +### Using Feature Configuration |
| 86 | +```typescript |
| 87 | +import { partDiscoveryConfig } from './config'; |
| 88 | + |
| 89 | +// Get feature-specific endpoint |
| 90 | +const url = partDiscoveryConfig.api.buildUrl('CATALOG_PART_MANAGEMENT'); |
| 91 | + |
| 92 | +// Get governance policies |
| 93 | +const policies = partDiscoveryConfig.governance.getDtrPoliciesConfig(); |
| 94 | + |
| 95 | +// Get pagination settings |
| 96 | +const pageSize = partDiscoveryConfig.pagination.defaultPageSize; |
| 97 | +``` |
| 98 | + |
| 99 | +## Migration Benefits |
| 100 | + |
| 101 | +1. **Modularity**: Each feature owns its configuration |
| 102 | +2. **Maintainability**: Easier to find and update feature-specific settings |
| 103 | +3. **Reusability**: Shared configuration prevents duplication |
| 104 | +4. **Type Safety**: Better TypeScript support with typed configurations |
| 105 | +5. **Performance**: Only load configuration needed by active features |
| 106 | + |
| 107 | +## Configuration Guidelines |
| 108 | + |
| 109 | +### When to Use Shared Configuration |
| 110 | +- Settings used by 2+ features |
| 111 | +- Application-wide defaults |
| 112 | +- Core infrastructure configuration |
| 113 | +- Common utilities and helpers |
| 114 | + |
| 115 | +### When to Use Feature Configuration |
| 116 | +- Settings specific to one feature |
| 117 | +- Feature-specific validation rules |
| 118 | +- Component-specific configurations |
| 119 | +- Feature flags and toggles |
| 120 | + |
| 121 | +### Adding New Configuration |
| 122 | + |
| 123 | +1. **For shared settings**: Add to `src/config/base.ts` |
| 124 | +2. **For feature settings**: Add to `src/features/{feature}/config.ts` |
| 125 | +3. **Update exports**: Ensure proper exports in index files |
| 126 | +4. **Document**: Update this file with new configuration options |
| 127 | + |
| 128 | +## Environment Variables |
| 129 | + |
| 130 | +Environment variables are still centralized in `EnvironmentService.ts` but are now consumed through the configuration modules: |
| 131 | + |
| 132 | +- `VITE_ICHUB_BACKEND_URL` → `baseConfig.apiUrl` |
| 133 | +- `VITE_PARTICIPANT_ID` → `baseConfig.participantId` |
| 134 | +- `VITE_GOVERNANCE_CONFIG` → `partDiscoveryConfig.governance` |
| 135 | +- Feature flags: `VITE_FEATURE_{NAME}_ENABLED` |
| 136 | + |
| 137 | +This approach maintains backward compatibility while providing a cleaner, more organized configuration architecture. |
0 commit comments