Skip to content

Feature/optional bounds for filters #1546

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

Merged
merged 13 commits into from
May 17, 2024

Conversation

lukavdplas
Copy link
Contributor

@lukavdplas lukavdplas commented Apr 16, 2024

This makes the specification of upper and lower bound for the range filter and date filter optional (close #1535). If no upper or lower bound has been defined, the frontend will request the min/max values when rendering the filter component.

Summary of changes to the code:

  • Refactored the methods for handling aggregations in the searchService. aggregateSearch() is now as general as the name implies, and allows aggregations other than the terms type. dateHistogramSearch() is removed.
  • Added an abstract Aggregator class with subclasses for specific aggregation types. This class handles the translation to an elasticsearch query, and translation from an elasticsearch result.
  • Type definitions treated the results of terms and date_histogram aggregations as the same type, but they are not compatible. Changed the definitions so these are different return types.
  • The RangeFilter and DateFilter now accept undefined min/max values (i.e. no bound). If the corpus did not specify an upper/lower bound, these will be the initial values.
  • When the filter widget for the range/date filter is rendered, it will add a a finite upper/lower bound to the filter, if it doesn't have one already. This is done with an aggregation query.

@lukavdplas lukavdplas added frontend changes to the angular frontend backend changes to the django backend labels Apr 16, 2024
Copy link
Contributor

@JeltevanBoheemen JeltevanBoheemen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have to admit it's a bit of an end-of-the-day review, but the test coverage gives me the confidence to approve it anyway.

I especially like the models/aggregation.ts file!

Comment on lines 36 to 41
this.searchService.aggregateSearch(queryModel.corpus, queryModel, aggregator).then(result =>
this.options = _.sortBy(
result.map(x => ({ label: x.key, value: x.key, doc_count: x.doc_count })),
o => o.label
)
).catch(() => this.options = []);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would prefer meaningful variable names over x and o, or type annotations. The code is already quite difficult to read.

I know this is not in the scope of the PR, but just stood out to me now that it's presented to me :)

[range]="true" [min]="min" [max]="max"
(onChange)="sliderValue$.next($event.values)"></p-slider>
</div>
<ng-container *ngIf="min !== undefined && max !== undefined">
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I presume the *ngIf is to delay loading the component until after the min and max are set?
In that case we need to be sure that these are always set.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, you can't really make a slider otherwise. The same component should be requesting a min/max value.

@@ -0,0 +1,163 @@
import { CorpusField } from './corpus';
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

By god this is great.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not the import. The file.

@lukavdplas lukavdplas merged commit 0dbf382 into develop May 17, 2024
2 checks passed
@lukavdplas lukavdplas deleted the feature/optional-bounds-for-filters branch May 17, 2024 10:38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backend changes to the django backend frontend changes to the angular frontend
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Infer upper/lower for RangeFilter and DateFilter
2 participants