Known Issues

Note: Many of the following issues stem from the lack of clear project scope and full requirements early on, largely due to a tight timeline. As a result, some architectural decisions were made that no longer scale well with the current complexity of the application.

1. Filter State Management

Problem

The current implementation handles filter logic through URL parameters. This approach worked initially when the functionality and number of filters were minimal. However, as the app has grown in complexity, maintaining filters via URL has become error-prone and harder to manage.

Recommendation

Refactor the filter logic to use a centralized state management approach via Zustand. This will provide better control, cleaner state updates, and reduce the likelihood of bugs as filter interactions increase.

Reference: Consider updating the logic in web/src/hooks/units/useFilterUnitsFromURL.ts.

---

2. Filtered Data Persistence Logic

Problem

We’re currently handling filtered data processing entirely on the frontend, using a combination of hooks and pipes. While this was fine in the early stages, it’s becoming a bottleneck as the application scales. The logic is harder to follow and maintain, and it adds unnecessary load to the client.

Recommendation

If we integrate a backend, we should offload filtered data processing to it. Complex data manipulation belongs on the server, not the frontend—doing so will improve maintainability, reduce client-side computation, and lead to a more scalable architecture.