# Design Improvement Recommendations

This document outlines suggested improvements for the IGP Fan Reference project to enhance maintainability, performance, and code quality.

## 1. Code Quality and Maintenance

### Centralize and Refactor Configuration
- **Hardcoded Strings and IDs**: Many strings (like storage keys, event names, and navigation paths) are hardcoded across the application. These should be moved to a central `Constants` or `Configuration` class.
- **Data Initialization**: In `WebsiteData.cs`, the page list is hardcoded with magic numbers for IDs. Consider moving this to a JSON configuration file that can be loaded at runtime.
- **Localization**: While the project has a `Localizations.resx` file, some UI strings (like descriptions in `WebsiteData.cs`) are still hardcoded. All user-facing text should be moved to resource files.

### Standardize Event Handling
- The project uses a manual `Action` subscription pattern in many services (e.g., `StorageService`, `TimingService`, `BuildOrderService`).
- **Recommendation**: Consider using standard C# events or a more robust Message Bus pattern (like `IMessenger` from CommunityToolkit.Mvvm) to reduce boilerplate and avoid memory leaks from missing unsubscriptions.

### Fix "TODO"s and Commented-Out Code
- Several files (e.g., `PageLayout.razor`, `TimingService.cs`) contain `TODO` comments or large blocks of commented-out code.
- **Recommendation**: Clean up these areas. If a feature (like Light Mode) is planned, track it in a backlog instead of leaving dead code in the UI.

## 2. Architecture and Design

### Dependency Injection Cleanup
- **Duplicated Service Registration**: In `Program.cs`, `HttpClient` is registered twice.
- **Service Lifetimes**: Most services are registered as `Scoped`. In Blazor WASM, `Scoped` and `Singleton` behave similarly, but using `Singleton` for stateless services (like `KeyService`) or services that truly span the entire session (like `StorageService`) makes the intent clearer.

### Decouple Logic from UI
- **Portals and Services**: The "Portal" pattern used for dialogs is good, but the services (like `EntityDialogService`) are directly coupled to the UI state.
- **Recommendation**: Ensure that game logic services (in `Services.Immortal`) remain pure and don't depend on UI-specific services unless absolutely necessary.

### Improve Type Safety
- Several methods use `int` or `string` for types that could be enums (e.g., `webPageType` in `NavigationService`, `IsPrivate` string in `WebPageModel`).
- **Recommendation**: Replace magic strings and numbers with strongly typed Enums to prevent runtime errors.

## 3. Performance and UX

### Optimize State Management
- `StorageService` calls `NotifyDataChanged()` frequently. If many components subscribe to this, it could lead to unnecessary re-renders.
- **Recommendation**: Implement more granular notifications or use a state management library if the application complexity grows.

### Move CSS to Isolated Files
- `App.razor` contains a large `<style>` block.
- **Recommendation**: Move these styles to `App.razor.css` (CSS isolation) or a global `app.css` to keep the Razor file focused on structure and logic.

## 4. Testing and Validation

### Expand Test Coverage
- **Unit Tests**: While Playwright E2E tests are present, there is a lack of unit tests for the complex calculation logic in `BuildOrderService` and `EconomyService`.
- **Recommendation**: Add a unit testing project (xUnit or NUnit) to verify the core algorithms independently of the UI.
- **CI/CD**: Ensure that tests are automatically run on every Pull Request to catch regressions early.
