fix(fields): 记录选择器筛选面板的 select 筛选项改从引用对象 schema 取 options (#3336) - #3421
Merged
Conversation
…tions (#3336) The lookup "Browse all records" picker derives a filter column from every typed picker column, but those carried no `options` — so the filter panel's `select` input rendered `col.options?.map(...)` over `undefined` and the dropdown opened EMPTY, leaving the column unfilterable. The same column's table CELLS had resolved their option labels since #3333. RecordPickerDialog now fills a `select` filter column's missing `options` from `fieldsMeta` (the referenced object's schema `fields` map) through `resolveSchemaOptions` — the same resolver, and the same i18n option translation, the cell descriptors use — so the filter dropdown and the cells cannot drift apart. Explicitly authored filter options still win (including the ones auto-derived from an `in`/`notIn` `lookup_filters` entry), and a schema field that declares no options keeps an empty dropdown: nothing is synthesised from the loaded page's raw stored values. LookupField is unchanged: it already passes `fieldsMeta`, and resolving the options in the dialog keeps ONE source for both faces of the widget instead of a second, filter-only derivation. Fixes #3336 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01GTRjn8xBqp75dk7kFupVRt
|
The latest updates on your projects. Learn more about Vercel for GitHub. |
Contributor
✅ Console Performance Budget
📦 Bundle Size Report
Size Limits
|
yinlianghui
marked this pull request as ready for review
August 6, 2026 02:39
This was referenced Aug 6, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #3336
问题
lookup「浏览全部记录」记录选择器的筛选面板里,由 typed picker column 派生出来的
select筛选项不带options,筛选面板的renderFilterInput渲染的是col.options?.map(...),于是 SelectContent 为空 —— 下拉展开什么都没有,这一列根本无法筛选。同一列的表格单元格自 #3333 起已经能解析选项 label(走
fieldsMeta+ 共享 i18n option 翻译),所以这是同一个控件的另一面:单元格对了,筛选输入框还是空的。定位复核(issue body 只是线索,逐条对 origin/main 核过)
packages/fields/src/widgets/LookupField.tsx:376-386filterColumnsuseMemo 仍然只 push{ field, label, type },不带 options —— 成立;packages/fields/src/widgets/RecordPickerDialog.tsxrenderFilterInput的 select 分支仍是col.options?.map(...)—— 成立;LookupField.tsx:1280已经把fieldsMeta={refObjectSchema?.fields}传给了 dialog,dialog 里有columnFieldDescriptors走translateOptions—— 可复用,成立。改法
把选项解析抽成
resolveSchemaOptions(meta, objectName, fieldName, translateOptions),单元格描述符和筛选列共用同一个 resolver:select且自身没有 options 时,从fieldsMeta[col.field].options取,并过同一条 i18n option 翻译路径。因此筛选下拉与表格单元格不可能对同一个选项给出不同的名字 —— 这是本 PR 的关键取舍:没有在
LookupField里再写一份"筛选专用"的派生逻辑(那样两边会各自漂移),LookupField本次零改动。刻意保留的两条边界(都有测试钉住):
lookup_filters的in/notIn自动派生出来的那一份)不会被 schema 的全量选项覆盖 —— 那会把作者刻意收窄的列表重新放宽;测试与反向验证(方向是先预判、后运行的)
新增
packages/fields/src/widgets/RecordPickerDialog.filterOptions.test.tsx(7 例)。把修改 stash 掉、只留测试跑了一遍,方向与预判完全一致:renderFilterBar拿到的筛选列带 schema options、内置筛选面板下拉里出现两个 option、选中后$filter落到project_phase: 'manufacturing'、i18n 平价用例、以及 LookupField → 筛选面板的端到端串联。失败信息分别是expected undefined to deeply equal [ …(2) ]和Unable to find role="option" and name "03 Manufacturing"。其中 i18n 平价用例是最吃重的一例:在 zh provider 下断言筛选项 label 与同字段单元格是同一个被翻译过的字符串。一份只读
meta.options、绕过 i18n 的"筛选专用"派生能通过前面几例,但过不了这一例。命令与结果(均在 worktree 仓库根跑 vitest,已确认目标文件名出现在 verbose 输出里):
npx vitest run --maxWorkers=2 packages/fields --reporter=dot→Test Files 60 passed (60) / Tests 924 passed (924)npx vitest run --maxWorkers=2 packages/plugin-detail packages/app-shell/.../AccessExplainPanel.test.tsx packages/app-shell/.../AssignedUsersSection.test.tsx→Test Files 52 passed (52) / Tests 453 passed (453)(按"规则消费半径"扫的下游:RelatedList / AccessExplainPanel / AssignedUsersSection 都是 RecordPickerDialog 的调用方)pnpm --workspace-concurrency=2 --filter @object-ui/fields type-check→ 通过(先pnpm --filter '@object-ui/fields^...' build建好依赖 dist,否则是假红)node scripts/check-control-bytes.mjs→ OK;eslint改动文件 → 0 errors已附 changeset(
.changeset/record-picker-filter-select-options.md,patch)。未触碰content/docs/releases/。Generated by Claude Code