Repository navigation
finding: the pre-objectstack#10235 sortability compatibility floor is now duplicated across three files, with its deletion tracked only in source comments #6456
Description
Observation filed while implementing #6108. Not a defect today — a scheduled deletion with nothing tracking it.
What exists
Every consumer of the served per-column sortability projection carries the same compatibility branch: when readObjectSortability(schema) returns undefined — no sortability key was served at all — the consumer falls back to reading UNMATERIALIZED_FIELD_TYPES / isUnmaterializedFieldType off the field's type. undefined means "no signal was served", not "nothing is sortable", so the branch is correct and necessary today.
At 27f9d10f6 there are four copies of it:
| File | Site |
|---|---|
packages/plugin-grid/src/ObjectGrid.tsx |
withSortability (landed by #5729) |
packages/plugin-list/src/ListView.tsx |
the toolbar sort picker's platformSortable (#6108) |
packages/plugin-detail/src/RelatedList.tsx |
withheldFromServerSort, serving both sort entry points (#6108) |
(three files, four call sites — RelatedList's single predicate feeds the embedded table's headers and the data-list sort-button row.)
Why it is worth a card
ObjectGrid's comment already says what the plan is, and #6108 copied that sentence into the two new sites verbatim:
This branch is a compatibility floor, not a second judge: the moment a backend serves the signal it is unreachable, and it is meant to be deleted when the supported floor passes that release.
So there is a planned, coordinated deletion across three files, whose trigger is a backend-support-floor decision, recorded only in source comments. Nothing schedules it, and nothing will notice when the trigger arrives. Deleting it also retires the last consumer of isUnmaterializedFieldType on the sort axis, which is the point at which "virtual ⇒ unsortable" stops being re-derivable in this repo at all.
Not urgent, and explicitly NOT a request to delete the branch now — the floor is load-bearing while any supported backend predates objectstack-ai/objectstack#10235. This is a placeholder so the cleanup is triaged when the floor moves, rather than rediscovered.
Refs: #6108 · #5729 · #3950 · objectstack-ai/objectstack#10235
Generated by Claude Code
Activity
objectstack-fleet commentedon Sep 24, 2026
关闭
not_planned—— 维护者同意:兼容分支正确、运行时没有代价,删掉它对用户没有任何变化;删除计划已写在三处代码注释里分诊席(
session_01Tw7jnJinGHvoGSi8aFkhPJ,objectstack 座位贴 #6015),2026-09-24T14:07Z。objectui 清理第九批(#8587 的挂起卡一次性清点):本席读了卡面(本卡有 1 条评论,本席的读取权限看不到),并在本地 main(62597c5)和 objectstack main(3b5607019f)上重新核对,把建议报给维护者。维护者答:「第⑨批 同意」。本卡说的是什么
后端从 objectstack#10235 起下发每一列能否排序的信息。三个前端组件在收不到这个信息时,会退回按字段类型判断。卡片是个占位:等后端最低支持版本越过那个版本后,三处兼容分支一起删掉。
本席实测
ObjectGrid.tsx:3959、ListView.tsx:3517、RelatedList.tsx:1725。三处注释都写着"后端最低支持版本越过后删除"。@objectstack/rest17.2.0 发布;objectstack 的包是统一版本号(.changeset/config.json的fixed组包含@objectstack/rest)。为什么关
这段兼容分支只在后端没下发排序信息时才会走到,运行时没有代价。删掉它对用户没有任何可见变化,删除计划也已经写在代码里。
什么时候重开
正式声明后端最低支持版本不低于 17.2 时(那时三处一起删,并同时删掉排序这条线上对
isUnmaterializedFieldType的最后一处使用);或者这段分支引出实际问题时。标签:摘
pm:on-hold;以not_planned关闭。Generated by Claude Code