feat: property filter custom operator support#4579
Conversation
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #4579 +/- ##
==========================================
- Coverage 97.43% 97.43% -0.01%
==========================================
Files 941 941
Lines 29692 29717 +25
Branches 10791 10801 +10
==========================================
+ Hits 28930 28954 +24
- Misses 715 756 +41
+ Partials 47 7 -40 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
gethinwebster
left a comment
gethinwebster
left a comment
There was a problem hiding this comment.
Also looks like there are some axe a11y violations on this page: ✕ #/light/property-filter/property-filter-editor-permutations?visualRefresh=false (1689 ms)
(and/or possibly "// Report if there are any occurrences of string "undefined" in HTML.", the failure outputs are a bit hard to read...)
You can test this locally by running npm start in one terminal, then npx jest -c jest.integ.config.js a11y in another, narrowing down which pages are tested by temporarily editing this file locally
components/src/__integ__/utils.ts
Line 9 in ff19e2c
| const operatorSet = new Set([defaultOperator, ...operators]); | ||
| return operatorOrder.filter(op => operatorSet.has(op)); | ||
| const knownOperators = knownOperatorOrder.filter(op => operatorSet.has(op)); | ||
| const customOperators = operators.filter(op => !(knownOperatorOrder as readonly string[]).includes(op)); |
There was a problem hiding this comment.
maybe we should use operatorSet instead of operators here: technically operators could have duplicates in it which we probably want to avoid
| return operatorOrder.filter(op => operatorSet.has(op)); | ||
| const operators = freeText.operators.map(op => (typeof op === 'string' ? op : op.operator)); | ||
| const operatorSet = new Set(operators); | ||
| const knownOperators = knownOperatorOrder.filter(op => operatorSet.has(op)); |
There was a problem hiding this comment.
as this joining/ordering isn't entirely straightforward and is repeated twice, would be good to refactor it into a helper
2 participants
Description
Adds end-to-end support for custom operators in the Property Filter component. Consumers can define their own operator strings with custom matching logic, display descriptions, and accessible labels.
Key changes:
getAllowedOperatorsnow preserves custom operators (appended after known operators in standard display order)getAllowedFreeTextOperatorsupdated to handle extended operator objects and preserve custom operatorsoperatorToDescriptionchecks customdescriptionbefore built-in i18n, allowing consumers to override predefined operator labels (e.g.>described as "After" for date properties)matchOperatorrequires word boundary after text-based operators to prevent false matches (e.g. "in" not matching "internal")getOperatorDescriptionaccessor toInternalFilteringPropertyDepends on: cloudscape-design/collection-hooks#151
Related links, issue #, if available: n/a
How has this been tested?
operatorToDescription(custom description override, fallback to i18n, unknown operators)getAllowedOperators(custom operators preserved, ordering, duplicates)matchOperator(text-based operator word boundary, case-insensitive matching, symbolic operators unaffected)parseText(text-based operators with space, case-insensitive, no false match on value prefix)/#/light/property-filter/property-filter-custom-operatorexercising all scenariosReview checklist
The following items are to be evaluated by the author(s) and the reviewer(s).
Correctness
CONTRIBUTING.md.CONTRIBUTING.md.Security
checkSafeUrlfunction.Testing
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.