Skip to content

Refactor FiltersService by extracting Filter model and centralising filter logic#506

Open
e1121208 wants to merge 2 commits intoCATcher-org:mainfrom
e1121208:extract-filter-model
Open

Refactor FiltersService by extracting Filter model and centralising filter logic#506
e1121208 wants to merge 2 commits intoCATcher-org:mainfrom
e1121208:extract-filter-model

Conversation

@e1121208
Copy link
Copy Markdown
Contributor

@e1121208 e1121208 commented Aug 14, 2025

Summary:

Fixes #405

Type of change:

  • 🎨 Code Refactoring

Changes Made:

  • Created filters.model.ts containing the Filter class and related types.
  • Moved immutable state management, cloning, serialisation, and deserialisation logic from FiltersService to Filter model.
  • Updated FiltersService to consume the Filter model instead of handling raw filter state.
  • Simplified preset view logic, URL synchronisation, and sanitisation of labels, milestones, and assignees in FiltersService.
  • Centralised all filter transformations, improving separation of concerns, maintainability, and testability.

Screenshots:

Functionality of WATcher still remains the same as observed below.
ScreenRecording2025-08-14at3 18 07PM-ezgif com-video-to-gif-converter

Proposed Commit Message:

Refactor filter model out of FiltersService and centralize filter logic

Previously, filter-related state and logic were tightly coupled inside FiltersService,
leading to a monolithic service that handled both URL serialization, preset views, and
direct filter state management. This made the service harder to maintain, test, and
extend, and mixed concerns of state management with data transformation.

Let’s extract the Filter class and related types (FilterProps, FilterUpdate)
into a dedicated model (filters.model.ts). The Filter class now encapsulates:
	•	Immutable state with .clone() for updates
	•	Serialization and deserialization from plain objects or query parameters
	•	Default instance creation via createDefault

FiltersService now consumes the Filter model instead of managing raw filter state,
simplifying preset view logic, URL synchronization, and sanitization of labels,
milestones, and assignees. All filter transformations are centralized in the Filter model,
improving separation of concerns, maintainability, and testability.

Checklist:

  • I have tested my changes thoroughly.
  • I have created tests for any new code files created in this PR or provided a link to a issue/PR that addresses this.
  • I have added or modified code comments to improve code readability where necessary.

Tan Wen Xuan added 2 commits August 14, 2025 15:45
Previously, filter-related state and logic were tightly coupled inside FiltersService,
leading to a monolithic service that handled both URL serialisation, preset views, and
direct filter state management. This made the service harder to maintain, test, and
extend, and mixed concerns of state management with data transformation.

Let’s extract the Filter class and related types (FilterProps, FilterUpdate)
into a dedicated model (filters.model.ts). The Filter class now encapsulates:
	•	Immutable state with .clone() for updates
	•	Serialisation and deserialisation from plain objects or query parameters
	•	Default instance creation via createDefault

FiltersService now consumes the Filter model instead of managing raw filter state,
simplifying preset view logic, URL synchronisation, and sanitisation of labels,
milestones, and assignees. All filter transformations are centralised in the Filter model,
improving separation of concerns, maintainability, and testability.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Extract the filter model from filters.service.ts into filter.model.ts

1 participant