feat(SchemaForm): field-type-aware operators + values for view filter#2766
Merged
Merged
Conversation
Align the Studio view-config filter editor with the canonical @objectstack/spec ViewFilterRule operator vocabulary and reuse the runtime FilterBuilder (which already provides per-field-type operator lists, value inputs, and i18n) instead of raw repeater rows. - ResourceEditPage: resolve the source object from `data.object` so view filter rows get the object field catalog that drives operator/value widgets. - widgets.tsx FilterBuilderWidget: write the canonical operator vocabulary (greater_than, not_equals, before/after, …); reads still accept legacy shorthand/camelCase spellings from already-stored metadata and round-trip unknown operators instead of rewriting them. - Runtime operator->AST maps (ListView.mapOperator, UserFilters.specOperatorToAst) now accept the canonical long-form operators the builder writes, alongside the existing shorthand spellings. Depends on the paired @objectstack/spec change (ViewFilterRule operator enum + `widget: 'filter-builder'` on the view filter field) for the operator dropdown. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PwbhoMeqh33xFWq5M77QTJ
|
The latest updates on your projects. Learn more about Vercel for GitHub. |
Contributor
✅ Console Performance Budget
📦 Bundle Size Report
Size Limits
|
os-zhuang
marked this pull request as ready for review
July 21, 2026 00:56
This was referenced Jul 21, 2026
Closed
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.
Closes #2764.
Summary
Makes the Studio Edit View Config filter editor field-type-aware, by reusing the runtime
FilterBuilder(which already provides per-field-type operator lists, type-aware value inputs, and i18n) and aligning the stored operator vocabulary with the canonical@objectstack/specViewFilterRuleenum — rather than a parallel operator/value implementation.ResourceEditPage— resolve the source object fromdraft.data.object(view configs bind their object underdata), so filter rows get the object field catalog that drives operator/value widgets.widgets.tsx(FilterBuilderWidget) — write the canonical spec operators (greater_than,not_equals,before/after,is_empty, …). Reads still accept legacy shorthand/camelCase spellings (gt,eq,isNull) from already-stored metadata, and round-trip an unknown operator verbatim instead of silently rewriting it toequals.ListView.mapOperator,UserFilters.specOperatorToAst) — accept the canonical long-form operators the builder now writes, alongside the existing shorthand spellings, so stored canonical filters evaluate correctly.The actual routing of the view
filterfield to thefilter-builderwidget is done contract-first in the spec form (view.form.ts, in the paired framework PR) — matching howdataset/pageforms already pin it — so no renderer-side name heuristic is added here.Why not the previous attempt (#2760)
That PR built parallel per-row operator/value widgets that duplicated
FilterBuilder, wrote an operator vocabulary conflicting with whatFilterBuilderWidgetalready writes, madebetweenunreachable for date fields (branch-order bug), stored booleans as strings andinvalues as comma-joined strings, rendered a literal—in JSX, hardcoded English labels, and used over-broad/Value$///Operator$/widget detection. Reusing the existingFilterBuilderavoids all of it.Dependencies
Depends on objectstack-ai/objectstack#3373 (
ViewFilterRuleoperator enum +widget: 'filter-builder'on the view filter field). This PR is independently buildable — it does not import the unpublished spec helper — but the operator dropdown and the builder routing land once the spec change ships.Test plan
pnpm --filter @object-ui/plugin-list test— 9 files, 163 tests pass (coversListView.mapOperator+UserFilters.specOperatorToAst).pnpm --filter @object-ui/app-shell exec tsc --noEmit— clean (0 errors).🤖 Generated with Claude Code
https://claude.ai/code/session_01PwbhoMeqh33xFWq5M77QTJ
Generated by Claude Code