Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix(ui): clearing value from relationship filter leaves stale query #11023

Merged
merged 2 commits into from
Feb 6, 2025

Conversation

jacobsfletch
Copy link
Member

When filtering the list view using conditions on a relationship field, clearing the value from the field would leave it in the query despite being removed from the component.

@jacobsfletch jacobsfletch changed the title fix(ui): list query stale after clearing relationship filters fix(ui): clearing relationship filter leaves stale query Feb 6, 2025
@jacobsfletch jacobsfletch changed the title fix(ui): clearing relationship filter leaves stale query fix(ui): clearing value from relationship filter leaves stale query Feb 6, 2025
@jacobsfletch jacobsfletch merged commit 7a73265 into main Feb 6, 2025
69 checks passed
@jacobsfletch jacobsfletch deleted the fix/clear-filter-from-query branch February 6, 2025 22:44
Copy link
Contributor

github-actions bot commented Feb 7, 2025

🚀 This is included in version v3.22.0

jacobsfletch added a commit that referenced this pull request Feb 11, 2025
#11080)

Fixes #9873. The relationship filter in the "where" builder renders
stale values when switching between fields or adding additional "and"
conditions. This was because the `RelationshipFilter` component was not
responding to changes in the `relationTo` prop and failing to reset
internal state when these events took place.

While it sounds like a simple fix, it was actually quite extensive. The
`RelationshipFilter` component was previously relying on a `useEffect`
that had a callback in its dependencies. This was causing the effect to
run uncontrollably using old references. To avoid this, we use the new
`useEffectEvent` approach which allows the underlying effect to run much
more precisely. Same with the `Condition` component that wraps it. We
now run callbacks directly within event handlers as much as possible,
and rely on `useEffectEvent` _only_ for debounced value changes.

This component was also unnecessarily complex...and still is to some
degree. Previously, it was maintaining two separate refs, one to track
the relationships that have yet to fully load, and another to track the
next pages of each relationship that need to load on the next run. These
have been combined into a single ref that tracks both simultaneously, as
this data is interrelated.

This change also does some much needed housekeeping to the
`WhereBuilder` by improving types, defaulting the operator field, etc.

Related: #11023 and #11032

Unrelated: finds a few more instances where the new `addListFilter`
helper from #11026 could be used. Also removes a few duplicative tests.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant