fix(OneFilterPicker): track nested filter keys when options load async

[factmarc10010]

Problem

A nested in filter exposed its child filter keys only when its options were a literal array. Any filter that loads its options from a function (or a source) resolved to no nested keys, so the picker treated the parent as empty everywhere it is summarised outside the option list:

Where	Symptom
FilterList	Parent gets no active dot when only a child is selected — the reported bug
InFilter	Child selections missing from the "N selected" count and the select-all indeterminate state
InFilter	Parent's clear / select-all toggle leaves the child values behind
OneFilterPicker.removeFilterValue	Removing the parent chip orphans the child values: chip gone, list still filtered
getClearedFiltersValue	Same call — masked today only when the child key is also declared as its own filter

Repro in the product: People → Filters → Workplace, select only a work area under an office. The office row gets its dot (that path reads the already-loaded options), the Workplace entry in the filter list does not.

Fix

The nested keys have to be knowable without the options at hand, because the filter list and the chips render before the filter is ever opened — and still render that way after a reload with filters in the URL.

• New optional nestedFilterKeys on the in-filter options, declaring the child keys up front. Authoritative and always available, including for source-backed options.
• collectNestedFilterKeys now takes the whole schema, so when options is not a literal array it can also fall back to the options a previous load already resolved.
• Inside InFilter the keys additionally union with the currently loaded options, so they pick up children that were still unresolved when the schema was read.

Consumers with literal arrays keep working untouched; nestedFilterKeys is only needed for async/source options.

options: {
  cache: true,
  nestedFilterKeys: ["workArea"],
  options: loadWorkplaces,
}

Testing

packages/react/src/patterns/OneFilterPicker/__test__/nestedAsyncOptions.test.tsx — nested filter with async options, covering the four behaviours above end to end. All four fail on main.

.../InFilter/components/__tests__/option-utils.test.ts — unit coverage for the three key sources (declared, literal, resolved-from-cache) and their merge.

The existing nested tests all use literal arrays, which is why this slipped through.

Ref: https://factorialmakers.atlassian.net/browse/FCT-61539

[github-actions]

🔍 Review policy: Code change

Default rule: any other change needs one approval from f0-devs (rule 4).

Required approvals

Team	Why	Status
@factorialco/f0-devs	Every code change needs a dev approval	⏳ pending

How this was decided

• PRs touching only sds/ modules require their owners and nothing else.
• Otherwise, docs-only changes (*.md, *.mdx, *.stories.tsx, anything in __stories__/) → one f0-general approval.
• Otherwise, feat: titles → one f0-devs and one f0-designers approval. Not a feature? Fix the title prefix.
• Anything else → one f0-devs approval.
• Add the needs-design-review label to also request a design approval on any PR.
• Creating a new sds/ module (new package.yml) additionally requires an f0-general approval.

Policy source: ownership/review-policy.ts · Team members: ownership/teams.yml

[github-actions]

✅ No untranslated copy added

Every user-visible string in this PR comes from the i18n layer. Codebase total unchanged at 133.

[github-actions]

✅ No New Circular Dependencies

No new circular dependencies detected. Current count: 0

[github-actions]

✅ Storybook docs — no pages lost

Every page reachable on main is still reachable here.

Links point at this PR's Storybook build — browse the full Storybook.

Snapshot of the Storybook index (docs pages + stories) compared against main. Non-blocking.

[github-actions]

📦 Alpha Package Version Published

Use pnpm i github:factorialco/f0#npm/alpha-pr-5270 to install the package

Use pnpm i github:factorialco/f0#e0daadf69001b577eb01cb31bcd99e0d71f2aeeb to install this specific commit

[github-actions]

🔍 Visual review for your branch is published 🔍

Here are the links to:

• the Visual Review Page

• the latest build on chromatic

• the full storybook

[github-actions]

♿ Accessibility (axe) — components changed in this PR

✅ No a11y issues in the stories this PR changed.

_{Scope: only stories in the files/component folders this PR changed. It can't yet flag downstream ripple from shared-code/token changes, or diff against main (planned: base-vs-head delta).}

[github-actions]

✅ No breaking public API changes

No public exports were removed, renamed, or had existing props/types changed in a breaking way compared to main.

Comparing f0, experimental and ai against main. Adding components, types, or optional props is safe. This check is non-blocking.

⚠️ Could not analyze component-status (no-base) — a build may have failed; results may be incomplete.

[github-actions]

Coverage Report for packages/react

Status	Category	Percentage	Covered / Total
🔵	Lines	69.02%	29130 / 42205
🔵	Statements	67.97%	30815 / 45332
🔵	Functions	61.87%	6955 / 11240
🔵	Branches	61.66%	21816 / 35376

File Coverage

File	Stmts	Branches	Functions	Lines	Uncovered Lines
Changed Files
packages/react/src/patterns/OneFilterPicker/OneFilterPicker.tsx	97.22%	89.36%	95.23%	98.5%	235, 355
packages/react/src/patterns/OneFilterPicker/components/FilterList.tsx	100%	94.44%	100%	100%
packages/react/src/patterns/OneFilterPicker/filterTypes/InFilter/InFilter.tsx	91.3%	84%	88.88%	92.13%	130, 146, 201-210, 264, 269-270
packages/react/src/patterns/OneFilterPicker/filterTypes/InFilter/types.ts	100%	100%	100%	100%
packages/react/src/patterns/OneFilterPicker/filterTypes/InFilter/useLoadOptions.ts	72.41%	43.9%	86.66%	73.21%	77-83, 95, 151, 155, 167-169, 180-190
packages/react/src/patterns/OneFilterPicker/filterTypes/InFilter/components/option-utils.ts	82.75%	83.33%	83.33%	84%	14-19, 35
packages/react/src/patterns/OneFilterPicker/internal/getClearedFiltersValue.ts	0%	0%	0%	0%	8-27

Generated in workflow #17540 for commit 5a088df by the Vitest Coverage Report Action

[albertpmz]

Nice work, let's check this issue below

[albertpmz]

This fallback doesn't fire where it's needed. With async options and no nestedFilterKeys, the dot stays off after the options load and only appears on a later mount: nestedKeysMap in FilterList.tsx is a useMemo keyed on definition, so the cache filling later never invalidates it. Same filter, two behaviors, depending on history the user can't see. It also makes render impure, since this reads a mutable module-level Map during render.

Suggest dropping the fallback and letting nestedFilterKeys be the single answer for non-literal options. It's deterministic and already carries the fix on its own: all four integration tests pass on the declared keys alone.

Heads up that option-utils.test.ts:76 can't catch this. It calls loadOptions(getCacheKey(schema), ...) with the same object and asserts the read back, so it covers the Map round-trip, not the component path.