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

Editor: Add a search filters summary component #1037

Open
wants to merge 17 commits into
base: me-date-filter
Choose a base branch
from

Conversation

tkohr
Copy link
Collaborator

@tkohr tkohr commented Nov 13, 2024

Description

This PR introduces components to display currently selected search filter values in a zone below the search filters.

To-dos:

  • format date
  • format user
  • finish UI
  • tests

Screenshots

image

Quality Assurance Checklist

  • Commit history is devoid of any merge commits and readable to facilitate reviews
  • If new logic ⚙️ is introduced: unit tests were added
  • If new user stories 🤏 are introduced: E2E tests were added
  • If new UI components 🕹️ are introduced: corresponding stories in Storybook were created
  • If breaking changes 🪚 are introduced: add the breaking change label
  • If bugs 🐞 are fixed: add the backport <release branch> label
  • The documentation website 📚 has received the love it deserves

Copy link
Contributor

github-actions bot commented Nov 13, 2024

Affected libs: api-repository, feature-catalog, feature-record, feature-router, feature-editor, feature-search, feature-map, feature-dataviz, feature-auth, common-domain, api-metadata-converter, ui-search, common-fixtures, ui-elements, feature-notifications, ui-catalog, util-shared, ui-widgets, ui-inputs, ui-layout, ui-map, ui-dataviz,
Affected apps: metadata-editor, datahub, demo, webcomponents, map-viewer, search, datafeeder, metadata-converter, data-platform,

  • 🚀 Build and deploy storybook and demo on GitHub Pages
  • 📦 Build and push affected docker images

Copy link
Contributor

github-actions bot commented Nov 13, 2024

📷 Screenshots are here!

@jahow jahow added this to the 2.4.0 milestone Nov 14, 2024
Copy link
Collaborator

@jahow jahow left a comment

Choose a reason for hiding this comment

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

Thanks! I did put some comments on what's already there, I'm not 100% sure what is the best way, let me know if you have better ideas!

Comment on lines 72 to 82
const currentFieldValues: (FieldValue | DateRange)[] = await firstValueFrom(
this.fieldValues$
)
const updatedFieldValues = currentFieldValues.filter(
(value: string | DateRange) => value !== fieldValue
)
this.fieldsService
.buildFiltersFromFieldValues({
[this.fieldName]: updatedFieldValues as FieldValue[],
})
.subscribe((filters) => this.searchService.updateFilters(filters))
Copy link
Collaborator

Choose a reason for hiding this comment

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

how about directly modifying the current filters instead of going from filters to values and then values to filters? simply deleting the corresponding key in the filters should be enough

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I must be thinking too complicated, but what would this look like? An additional method in the service or facade to delete one filter by its key? Also, date ranges don't use their value as a key in the object.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Ok I looked into it and honestly I couldn't find a better way, so I think your approach makes sense. It ends up being verbose because we need to alternate between the "filters" model and the "values" model, but I guess this is something we cannot avoid...

Comment on lines 16 to 20
@Input() searchFields: string[] = []

searchFilterActive$ = this.searchFacade.searchFilters$.pipe(
map((filters) => this.hasNonEmptyValues(filters))
)
Copy link
Collaborator

Choose a reason for hiding this comment

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

I'm wondering if instead of taking a list of filters as input we can simply listen for the search filters and show everyone of them. This means that if another filter (which does not appear in the advanced filters above) is active then it will also show up. What do you think?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I gave it a try, but had some difficulties with the fact that the field names do not always correspond to the ES field names in the filters. I'm also wondering if it is not more intuitive from a user perspective to only display the summary badges for the filters visible in the filter component above. For example, on the myRecords page the filter { owner: user.id } should always be present.

Comment on lines 42 to 43
marker('search.filters.summaryLabel.user')
marker('search.filters.summaryLabel.changeDate')
Copy link
Collaborator

Choose a reason for hiding this comment

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

how about marking labels for all fields? It might make more sense taken from outside I think. Another approach would be to use the field normal label if a summaryLabel is not available.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Right, I'll add more translations for this, I think.

Copy link
Collaborator Author

@tkohr tkohr Nov 21, 2024

Choose a reason for hiding this comment

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

Finally, I've added a fallback in 6b01ea9 to use the filters label, as we don't have the exact wording for more filter summary labels yet. Can be tested by adding any other filter to the allRecords component, for example.

@tkohr
Copy link
Collaborator Author

tkohr commented Nov 14, 2024

Thanks for the suggestions @jahow, I'll have a look how to refactor things this way.

Copy link
Collaborator

@jahow jahow left a comment

Choose a reason for hiding this comment

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

Thank you, this looks really good! Just a few final comments but it works well in the app and I think the implementation makes a lot of sense now.

Comment on lines 95 to 96
case 'userInfo':
return { value, label: formatUserInfo(value) }
Copy link
Collaborator

Choose a reason for hiding this comment

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

I think that instead of adding a very specific field type here we can simply look at the field name; if it is user then use this logic :)

Comment on lines 404 to 405
getType(): FieldType {
return 'userInfo'
Copy link
Collaborator

Choose a reason for hiding this comment

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

see comment above about not introducing a new field type

"
>
<mat-icon class="material-symbols-outlined leading-[1.1]">close</mat-icon>
<mat-icon class="material-symbols-outlined">close</mat-icon>
Copy link
Collaborator

Choose a reason for hiding this comment

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

hmm, we should't have mat-icons anymore :)

@tkohr tkohr marked this pull request as ready for review November 26, 2024 10:47
treat dates in local timezone in app and without time in URL
Copy link
Collaborator

@Angi-Kinas Angi-Kinas left a comment

Choose a reason for hiding this comment

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

Thank you @tkohr, this will improve the usability of the filters quite a lot!

The code looks good to me.
While testing I had some behaviors that we might need to have a look at:

  • If we use user= as a query param, we get an empty badge
    image

  • If we do the same with changeDate, we see an empty search filters summary component with the "reset" button
    image

And as mentioned to you before, the filters are only working as expected on "Metadata records" but not on "My Records". I think this is more important than the issues mentioned above. When this is fixed, you can merge from my side 🚀

@@ -42,8 +44,8 @@ export function expandQueryParams(
} else if (isDateUrl(value)) {
const [start, end] = value.split('..')
expanded[key] = {
...(start && { start: new Date(start) }),
...(end && { end: new Date(end) }),
...(start && { start: new Date(`${start}T00:00:00`) }),
Copy link
Collaborator

Choose a reason for hiding this comment

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

I guess T00:00:00 stands for the time... Is the time necessary here?

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.

3 participants