Add Applied Filters Tracking to Filterable Engine#34
Merged
Conversation
…and applied methods
…in Filterable API
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This pull request introduces a complete mechanism for recording all filters that were actually applied during the filtering lifecycle.
The feature ensures that only filters that passed validation, logic checks, and execution are stored, allowing consumers of the engine to reliably inspect the final filtering state.
Key Features Added:
• Applied Filters Registry
A dedicated internal structure for collecting and exposing the filters that were successfully applied, including their field, operator, value, and any relevant context.
• Integration With Engine Execution Flow
Filters are added to the registry only after passing through payload parsing, value sanitization, clause building, and successful execution via the
commitpipeline.• Public Accessor
A clean API for retrieving the applied filters from outside the engine.
This enables features such as debugging, analytics, UI filter visualization, or caching keys based on final applied filters.
• Non-intrusive Design
The tracking system does not change the behavior of any existing engines or filters.
It works automatically under the hood and integrates seamlessly with strict/permissive modes as well as skipping logic.
• Unit Tests Included
Tests verify:
– applied filters are recorded correctly
– skipped or invalid filters are not added
– structure of stored filters remains consistent
– behavior works across typical engine execution scenarios
Why This Matters:
Tracking applied filters opens the door to more powerful features like user-facing filter summaries, debugging tools, API responses with filter metadata, and smarter caching strategies.