Skip to content

Filter: allow users to choose to match or ignore specific item properties #5063

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

Closed
benelan opened this issue Aug 1, 2022 · 5 comments
Closed
Assignees
Labels
4 - verified Issues that have been tested, confirmed as mitigated, and are ready to close. ArcGIS Maps SDK for JavaScript Issues logged by ArcGIS SDK for JavaScript team members. Calcite (dev) Issues logged by Calcite developers. enhancement Issues tied to a new feature or request. estimate - 5 A few days of work, definitely requires updates to tests. p - low Issue is non core or affecting less that 10% of people using the library

Comments

@benelan
Copy link
Member

benelan commented Aug 1, 2022

Description

Right now calcite-filter matches every property of the item's object. It would be great if we could create a new property that specifies either properties to ignore or the properties to match. The property type Array<string> so it would need to be set in JavaScript. Something like

filterElement.ignoreFields = ["OBJECTID", "address"]

or

filterElement.matchFields = ["city", "state", "county"]

thoughts on this @jcfranco?

Acceptance Criteria

A new property that either matches or ignores specific properties of filter's item objects.

Relevant Info

No response

Which Component

calcite-filter

Example Use Case

I was putting together a pagination sample for someone and noticed inconsistent filter results:
https://codepen.io/benelan/pen/qBoxdwv

I realized it was because I was adding a hex string color property for the card's thumbnail, which was also being matched. It would have been great to be able to do something like

filterElement.ignoreFields = ["color"]

or

filterElement.matchFields = ["NAME", "CITY", "STATE"]

You can work around the constraint by passing a subset of the items' properties to calcite-filter and then matching the item back to the full dataset with an id or something that does get provided to filter. But it seems like a useful option for people anyway, and relatively low effort on our end to remove certain properties before filtering.

@benelan benelan added enhancement Issues tied to a new feature or request. 0 - new New issues that need assignment. needs triage Planning workflow - pending design/dev review. labels Aug 1, 2022
@benelan benelan added the Calcite (dev) Issues logged by Calcite developers. label Jan 30, 2023
@geospatialem geospatialem added p - low Issue is non core or affecting less that 10% of people using the library estimate - 5 A few days of work, definitely requires updates to tests. needs milestone Planning workflow - pending milestone assignment, has priority and/or estimate. and removed needs triage Planning workflow - pending design/dev review. labels Nov 6, 2023
@geospatialem geospatialem added this to the 2024 July Priorities milestone Dec 6, 2023
@geospatialem geospatialem removed the needs milestone Planning workflow - pending milestone assignment, has priority and/or estimate. label Dec 6, 2023
@geospatialem geospatialem added the ArcGIS Maps SDK for JavaScript Issues logged by ArcGIS SDK for JavaScript team members. label May 17, 2024
@driskull
Copy link
Member

driskull commented May 31, 2024

I prefer having an allowList like filterElement.matchFields = ["NAME", "CITY", "STATE"] but that would be considered a breaking change since fields would need to be configured going forward if someone is using calcite-filter as a standalone component. We document filter so it could be.

Should this move to a breaking change release? Or do we want to go with a blockList instead?

@jcfranco
Copy link
Member

jcfranco commented Jun 5, 2024

We could also consider the default to match all unless the user sets the allow list. This would preserve the existing behavior, allow users to ignore certain fields and doesn't require users to set anything by default.

@driskull
Copy link
Member

driskull commented Jun 5, 2024

Sounds like a good plan

@driskull driskull self-assigned this Jun 7, 2024
@driskull driskull added 1 - assigned Issues that are assigned to a sprint and a team member. 2 - in development Issues that are actively being worked on. and removed 0 - new New issues that need assignment. 1 - assigned Issues that are assigned to a sprint and a team member. labels Jun 7, 2024
driskull added a commit that referenced this issue Jun 14, 2024
…ies (#9541)

**Related Issue:** #5063

## Summary

- add matchFields argument to filter utility
  - allows filtering fields at the first level of an object.
  - Nested object fields will not be filtered.
- Could be enhanced to do so in the future by enhancing `matchFields` to
be an object
- add filter utility spec tests (thank you co-pilot)
- add `matchFields` property to `filter` component
- add e2e tests for filter
@driskull driskull added 3 - installed Issues that have been merged to the "dev" branch and/or are ready for QA/QC. and removed 2 - in development Issues that are actively being worked on. labels Jun 14, 2024
Copy link
Contributor

Installed and assigned for verification.

@DitwanP
Copy link
Contributor

DitwanP commented Jun 18, 2024

🍡 Verified locally on dev

@DitwanP DitwanP closed this as completed Jun 18, 2024
@DitwanP DitwanP added 4 - verified Issues that have been tested, confirmed as mitigated, and are ready to close. and removed 3 - installed Issues that have been merged to the "dev" branch and/or are ready for QA/QC. labels Jun 18, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
4 - verified Issues that have been tested, confirmed as mitigated, and are ready to close. ArcGIS Maps SDK for JavaScript Issues logged by ArcGIS SDK for JavaScript team members. Calcite (dev) Issues logged by Calcite developers. enhancement Issues tied to a new feature or request. estimate - 5 A few days of work, definitely requires updates to tests. p - low Issue is non core or affecting less that 10% of people using the library
Projects
None yet
Development

No branches or pull requests

6 participants