Mentor Filter Service
Component Detail
Description
Encapsulates filtering logic for mentor search criteria including availability status and specialization tags. Translates UI filter state into query parameters consumed by the mentor location service and list fallback view.
mentor-filter-service
Summaries
The Mentor Filter Service empowers coordinators to quickly narrow down the pool of available mentors by availability status and area of specialization, significantly reducing the cognitive load of finding the right match during time-sensitive situations. By providing a clean, consistent filtering experience shared across both the map view and the list fallback view, it ensures coordinators interact with a unified set of criteria regardless of how they choose to browse mentors. This consistency reduces training overhead, minimizes user errors, and contributes directly to faster mentor-to-student matching — a core metric of platform effectiveness. Its reusability across features also reduces development cost for future views that require mentor search.
Mentor Filter Service is a low-complexity, shared component with no external dependencies, making it one of the lowest-risk deliverables in the mentor location feature set. Because it is shared across the map view and list fallback view, it should be developed and signed off early so both consuming features can integrate against a stable interface. The main scheduling consideration is ensuring the MentorFilterCriteria model is finalized before dependent services (Mentor Location Service, list view) begin their integration work, as late changes to the criteria structure will require coordinated updates across multiple components. Testing requirements are straightforward: validate each filter combination, confirm the default no-filter state returns correctly, and verify isFiltered accurately reflects active criteria.
No deployment complexity.
Mentor Filter Service is a stateless utility class in the mobile execution context with no dependencies, making it straightforward to unit test in isolation. The buildCriteria method translates raw UI selections (nullable AvailabilityStatus, List of specialization strings) into a strongly typed MentorFilterCriteria value object consumed by both Mentor Location Service and any list-based fallback view. Keep this service purely functional — no side effects, no state storage — to preserve its reusability. The isFiltered helper enables the UI to conditionally show a 'clear filters' affordance without duplicating the logic in widgets.
resetCriteria should return a canonical default instance (const constructor preferred) to enable equality checks and avoid unnecessary rebuilds in Riverpod consumers. Ensure MentorFilterCriteria implements equality and hashCode for reliable state comparison in BLoC/Riverpod change detection.
Responsibilities
- Build filter criteria objects from UI selections
- Validate filter parameter combinations
- Provide default (no-filter) criteria state
Interfaces
buildCriteria(AvailabilityStatus? availability, List<String> specializations) → MentorFilterCriteria
resetCriteria() → MentorFilterCriteria
isFiltered(MentorFilterCriteria criteria) → bool