GenericFilter: restoring filter state from the URL fires a redundant data load when a condition operation differs - #5659
Open
Conversation
Restoring the filter state from URL query parameters fired a redundant intermediate data load: the binder applies the operation from the URL to the configuration's condition programmatically, and the operation-change listener that GroupFilter registers on its child conditions invoked apply() - and thus a data load - for a programmatic setOperation as well, unlike the value path, which has always been gated by isFromClient. A programmatic operation change no longer fires a load of its own; the caller applies the filter explicitly when a reload is intended. The tests that used the automatic load as an instrument now emulate the client-driven gesture. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
fractal3000
marked this pull request as draft
September 7, 2026 06:28
fractal3000
marked this pull request as ready for review
September 7, 2026 06:34
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
1 participant
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.
See #5655
Stacked on #5634 (base branch = its branch; GitHub will retarget this PR to
release_3_0when #5634 merges). Only the last commit belongs to this PR.Restoring the filter state from URL query parameters fires a redundant intermediate data load. Reproduction (Scenario 27 of the
filter-testproject attached to #5655): a configuration with an editable-operation condition, the user changes the operation (=→<>), then reloads the page or opens the bookmarked link — two data loads instead of one, the first by a half-restored state and discarded. For a 400 ms query a deep-link open pays roughly double.Cause:
GenericFilterUrlQueryParametersBinder.updatePropertyConditionapplies the operation from the URL programmatically, and the operation-change listener registered byGroupFilter.addinvokedapply()— and thusdataLoader.load()— for a programmaticsetOperationas well, unlike the value path, which has always been gated byisFromClient.Fix: the listener applies the filter on a client-driven change only. A programmatic
setOperationno longer fires a load of its own — consistent with a programmaticsetValue, which never did.Tests:
GenericFilterUrlRestoreLoadTest— a restore with a changed operation fires no load (fails without the fix); the tests that used the automatic load as an instrument (GenericFilterReNavigationTest,GenericFilterApplyAfterBaseChangeTest) now emulate the client-driven gesture viasetOperationInternal(op, true). Fullfacet.url_query_parameters.*andcomponent.genericfilter.*pass on top of #5634.Release note: an application that relied on a programmatic
PropertyFilter.setOperation(...)reloading the data must callapply()ordataLoader.load()explicitly.On
masterthe same fix arrives with the forward-port of this PR (it was deliberately kept out of #5658).🤖 Generated with Claude Code