PowerSearch typeahead: label-only matching vs key — intentional? #3921
Unanswered
nynexman4464
asked this question in
Q&A
Replies: 1 comment
|
I think assumption here is that key is not user facing so perhaps end users might not know what the key is but the builder might know and use it for identification. We could attempt to match both key and label but it's unclear whether callsites would have key as something relatively human readable like we have internally. Perhaps matching just label with aliases is sufficient for now since there's not an easy way to exclude key from matching if we decide to add it. I'm definitely curious how people are treating these externally though. |
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Observation
usePowerSearchSourcematches user typeahead queries againstfield.labeland (via consumer-supplied)field.typeaheadAliases, not againstfield.key. Same for operators — matched byop.label, never byop.key.Concretely, in
packages/core/src/PowerSearch/usePowerSearchSource.ts:The intuition, and the uncertainty
Intuition:
keyis the source of truth (stable identifier, consumer-chosen, doesn't change with locale) andlabelis derived (display string, potentially translated). It's a little surprising that search compares against the derived string only.But
typeaheadAliasesalready exists as a hook for "additional strings that should match this field." I don't know the history here — maybe that's the intended escape hatch, and consumers who want key-based matching are expected to put their key in there. Or maybetypeaheadAliaseswas designed for something entirely different (synonyms, user-friendly shortcuts, etc.).Rather than propose a fix, I wanted to raise the shape here and see if anyone with context can chime in on whether this is intentional, what
typeaheadAliaseswas actually designed for, and whether there's a real gap or not.Surfaced during the PowerSearch i18n migration follow-up to #3765. The i18n work itself doesn't depend on this — flagging it separately.
All reactions