What's wrong
Every new filter on the opportunity list has to be added by hand in six different files. Nothing in the type system catches a missed one, so forgetting a step doesn't fail the build, it just silently doesn't work at runtime. I hit this adding the skills filter in #936, and @arturasmckwcz asked me to backlog it.
What needs to happen
One config where a filter is defined once, so adding the next one is a single entry instead of six edits in six files.
The six sites a new filter has to touch.
- Opportunities/Filters/types.ts — add the key to OpportunityCardsFilter
- Opportunities/Filters/constants.ts — add the empty default
- Opportunities.tsx — createFilterFromOption entry
- Opportunities/Filters/helpers.ts — the filter block, the return, and the flat array
- Opportunities/Filters/FiltersContent.tsx — destructure plus one more AccordionFilter
- Opportunities/helpers.ts — serialize and deserialize
What I tried
I tried it on #936 and reverted it. OpportunityCardsFilter keys search, district, language and availability off QueryParamsKeys, but activity and skill off EntityTableName. The two consumers want different key types:
- generateNestedFilterControlItems wants keyof OpportunityCardsFilter
- createFilterFromOption wants keyof ApiOptionLists
So one config value can't satisfy both while the interface mixes the two enums. I didn't find a way around it without changing the filter type itself, which felt out of scope for PR #936
Question: should this cover Volunteers and Agents too?
Volunteers/helpers.ts and Agents/helpers.ts have the same shape of hand-written blocks. Should the config cover all three lists, or just Opportunities for now?
Refs #936
What's wrong
Every new filter on the opportunity list has to be added by hand in six different files. Nothing in the type system catches a missed one, so forgetting a step doesn't fail the build, it just silently doesn't work at runtime. I hit this adding the skills filter in #936, and @arturasmckwcz asked me to backlog it.
What needs to happen
One config where a filter is defined once, so adding the next one is a single entry instead of six edits in six files.
The six sites a new filter has to touch.
What I tried
I tried it on #936 and reverted it. OpportunityCardsFilter keys search, district, language and availability off QueryParamsKeys, but activity and skill off EntityTableName. The two consumers want different key types:
So one config value can't satisfy both while the interface mixes the two enums. I didn't find a way around it without changing the filter type itself, which felt out of scope for PR #936
Question: should this cover Volunteers and Agents too?
Volunteers/helpers.ts and Agents/helpers.ts have the same shape of hand-written blocks. Should the config cover all three lists, or just Opportunities for now?
Refs #936