@object-ui/components 17.3.0 → 17.6.0

package/README.md

@@ -27,7 +27,7 @@ pnpm shadcn:check
 pnpm shadcn:update button --backup
 ```
 
-**📚 See [SHADCN_SYNC.md](../../docs/SHADCN_SYNC.md) for the complete guide.**
+**📚 See [README_SHADCN_SYNC.md](./README_SHADCN_SYNC.md) for the complete guide.**
 
 ## Installation
 
@@ -38,49 +38,56 @@ npm install @object-ui/components @object-ui/react @object-ui/core
 **Peer Dependencies:**
 - `react` ^18.0.0 || ^19.0.0
 - `react-dom` ^18.0.0 || ^19.0.0
-- `tailwindcss` ^3.0.0
+- `tailwindcss` ^4.2.1
 
 ## Setup
 
-### 1. Configure Tailwind
+There is no `tailwind.config.js` step. This package is Tailwind 4, which is
+configured in CSS: it has no such file of its own, and consuming it does not need
+one on your side either.
 
-Add to your `tailwind.config.js`:
+### 1. Import Styles
 
-```js
-module.exports = {
-  content: [
-    './src/**/*.{js,jsx,ts,tsx}',
-    './node_modules/@object-ui/components/**/*.{js,ts,jsx,tsx}'
-  ],
-  // ... your config
-}
-```
-
-### 2. Import Styles
-
-Add to your main CSS file:
+Add to your main CSS file, after your own Tailwind entry:
 
 ```css
-@import '@object-ui/components/dist/style.css';
+@import 'tailwindcss';
+@import '@object-ui/components/style.css';
 ```
 
-### 3. Register Components
+`style.css` is the stylesheet this package compiles at build time from its own
+sources. It already carries every utility its components use **and** the theme
+tokens those utilities are built on — `bg-primary`, `border-input`, `ring-ring`
+and the rest of the Shadcn palette — so importing it is the whole of the styling
+setup.
+
+You do **not** add a `@source` line for `node_modules/@object-ui/components`.
+Pointing Tailwind at the published files generates the shape-only utilities a
+second time and still cannot produce the themed ones, because the `@theme` block
+they come from lives in this package's unpublished source. Your own Tailwind
+entry goes on generating the classes your own source uses, as it always did.
+
+### 2. Register Components
 
 ```tsx
-import { registerDefaultRenderers } from '@object-ui/components'
+import { initializeComponents } from '@object-ui/components'
 
-registerDefaultRenderers()
+initializeComponents()
 ```
 
+Importing the package already registers its components as a side effect;
+`initializeComponents()` is the explicit call for bundlers that would otherwise
+tree-shake that import away.
+
 ## Usage
 
 ### With SchemaRenderer
 
 ```tsx
 import { SchemaRenderer } from '@object-ui/react'
-import { registerDefaultRenderers } from '@object-ui/components'
+import { initializeComponents } from '@object-ui/components'
 
-registerDefaultRenderers()
+initializeComponents()
 
 const schema = {
   type: 'card',
@@ -197,30 +204,23 @@ All components accept `className` for Tailwind classes:
 Register your own components:
 
 ```tsx
-import { registerRenderer } from '@object-ui/react'
+import { ComponentRegistry } from '@object-ui/core'
 import { Button } from '@object-ui/components'
 
-function CustomButton(props) {
+function CustomButton(props: Record<string, unknown>) {
   return <Button {...props} className="my-custom-style" />
 }
 
-registerRenderer('custom-button', CustomButton)
+ComponentRegistry.register('custom-button', CustomButton)
 ```
 
-## API Reference
-
-See [full documentation](https://objectui.org/api/components) for detailed API reference.
+`ComponentRegistry` is a process-level singleton exported by `@object-ui/core`;
+`SchemaRenderer` resolves every `type` against it, so a component registered
+here is renderable from schema anywhere in the app.
 
-<!-- release-metadata:v3.3.0 -->
-
-## Compatibility
+## API Reference
 
-- **React:** 18.x or 19.x
-- **Node.js:** ≥ 18
-- **TypeScript:** ≥ 5.0 (strict mode)
-- **`@objectstack/spec`:** ^3.3.0
-- **`@objectstack/client`:** ^3.3.0
-- **Tailwind CSS:** ≥ 3.4 (for packages with UI)
+See [full documentation](https://objectui.org/docs/components) for detailed API reference.
 
 ## Links
 

package/dist/custom/button-group.d.ts

@@ -1,5 +1,5 @@
 import { VariantProps } from 'class-variance-authority';
-import { Separator } from '../ui/separator';
+import { Separator } from '../ui/separator.js';
 declare const buttonGroupVariants: (props?: ({
     orientation?: "horizontal" | "vertical" | null | undefined;
 } & import('class-variance-authority/types').ClassProp) | undefined) => string;

package/dist/custom/character-count.d.ts

@@ -0,0 +1,56 @@
+import { default as React } from 'react';
+export interface CharacterCountProps {
+    /**
+     * Length of the text this surface is counting. The inline surface passes the
+     * committed value's length; the fullscreen dialog passes the DRAFT's, which
+     * is the number that is true of what the user is looking at.
+     */
+    length: number;
+    /**
+     * The declared cap. Callers render this component only when the field
+     * declares one, so it is non-optional here — a counter with no cap to count
+     * against has nothing to say and must not be mounted at all (an unconditional
+     * live region in every long-text field is the objectui#3408 defect back
+     * again).
+     */
+    maxLength: number;
+    /**
+     * The description node's `id`, minted by the host from `useId()`.
+     *
+     * The host MUST also name it in the edited control's `aria-describedby` —
+     * this component renders the sentence, only the host knows which element is
+     * being described, and a description nothing references is a node no screen
+     * reader will ever reach. That association is asserted from the OUTSIDE (the
+     * tests resolve `aria-describedby` and concatenate the referenced nodes' text,
+     * exactly as an assistive technology does) rather than trusted here.
+     *
+     * Two surfaces of one widget therefore need two ids: the dialog's draft and
+     * the inline value diverge the moment the user types in the dialog, so one
+     * shared id would point both controls at whichever sentence rendered last.
+     */
+    descriptionId: string;
+    /**
+     * Render node 3, the threshold-gated debounced `aria-live` status region.
+     *
+     * Required on purpose — see the component doc above. `false` removes the
+     * region from the DOM entirely (not merely empties it), which is the only
+     * form of "no live region" a test can tell apart from "a live region that
+     * happens to be silent right now".
+     */
+    announceNearLimit: boolean;
+    /**
+     * Classes for the visible digits. Required because placement is entirely the
+     * surface's business — inline pins them to the textarea's bottom-right
+     * corner, the dialog lays them out as a footer item — and a default borrowed
+     * from either one would position the other wrongly while looking deliberate.
+     */
+    className: string;
+    /**
+     * `data-testid` for the visible digits, namespaced per surface
+     * (`textarea-character-count`, `textarea-fullscreen-character-count`) so a
+     * test that finds digits can say WHICH surface it found them on. Same
+     * convention, same reason, as `FullscreenFieldEditor`'s `testIdPrefix`.
+     */
+    testId: string;
+}
+export declare function CharacterCount({ length, maxLength, descriptionId, announceNearLimit, className, testId, }: CharacterCountProps): React.JSX.Element;

package/dist/custom/config-field-renderer.d.ts

@@ -1,4 +1,4 @@
-import { ConfigField } from '../types/config-panel';
+import { ConfigField } from '../types/config-panel.js';
 /**
  * ObjectUI
  * Copyright (c) 2024-present ObjectStack Inc.

package/dist/custom/config-panel-renderer.d.ts

@@ -1,4 +1,4 @@
-import { ConfigPanelSchema } from '../types/config-panel';
+import { ConfigPanelSchema } from '../types/config-panel.js';
 /**
  * ObjectUI
  * Copyright (c) 2024-present ObjectStack Inc.
@@ -32,9 +32,9 @@ export interface ConfigPanelRendererProps {
     className?: string;
     /** Additional inline styles applied to the panel root (e.g. to override `--config-panel-width`). */
     style?: React.CSSProperties;
-    /** Label for save button (default: "Save") */
+    /** Label for save button (default: the locale pack's `common.save`) */
     saveLabel?: string;
-    /** Label for discard button (default: "Discard") */
+    /** Label for discard button (default: the locale pack's `common.discard`) */
     discardLabel?: string;
     /** Ref for the panel root element */
     panelRef?: React.Ref<HTMLDivElement>;

package/dist/custom/export-progress-dialog.d.ts

@@ -1,4 +1,4 @@
-import { UseExportJobReturn } from '../hooks/use-export-job';
+import { UseExportJobReturn } from '../hooks/use-export-job.js';
 /**
  * ObjectUI
  * Copyright (c) 2024-present ObjectStack Inc.

package/dist/custom/filter-builder.d.ts

@@ -42,7 +42,7 @@ export interface FilterBuilderProps {
             value: string;
             label: string;
         }>;
-        /** For lookup/master_detail/user/owner fields — referenced object name */
+        /** For lookup/master_detail/user fields — referenced object name */
         referenceTo?: string;
         /** Display field on the referenced object (defaults to "name") */
         displayField?: string;
@@ -53,6 +53,17 @@ export interface FilterBuilderProps {
     onChange?: (value: FilterGroup) => void;
     className?: string;
     showClearAll?: boolean;
+    /**
+     * Opt-in operator ids ({@link OPT_IN_OPERATORS}) this instance may offer, on
+     * top of the ones every FilterBuilder draws.
+     *
+     * The dropdown is shared by consumers that persist a filter into DIFFERENT
+     * dialects, and an operator one dialect can carry is not automatically
+     * storable in another — so whether an opt-in operator is offered is the
+     * consumer's answer, not this component's. See {@link OPT_IN_OPERATORS} for
+     * the measurement that made this a prop instead of one global list.
+     */
+    extraOperators?: readonly string[];
 }
 declare const defaultOperators: readonly [{
     readonly value: "equals";
@@ -63,6 +74,9 @@ declare const defaultOperators: readonly [{
 }, {
     readonly value: "contains";
     readonly label: "Contains";
+}, {
+    readonly value: "containsCaseInsensitive";
+    readonly label: "Contains (ignore case)";
 }, {
     readonly value: "notContains";
     readonly label: "Does not contain";
@@ -120,7 +134,8 @@ declare const defaultOperators: readonly [{
 }];
 /**
  * The FilterBuilder's own operator vocabulary — every id its dropdown can
- * hold, derived from the operators it actually renders.
+ * hold, derived from the operators it actually renders. Includes the opt-in
+ * ids: they are drawable, just not offered unconditionally.
  *
  * Exported because several translation tables map an external vocabulary
  * (the spec's `VIEW_FILTER_OPERATORS`, Mongo `$`-tokens) *onto* this one, and
@@ -129,10 +144,275 @@ declare const defaultOperators: readonly [{
  * rather than restating it, so adding an operator here is the only edit
  * needed to widen them.
  */
-export declare const FILTER_BUILDER_OPERATORS: ("endsWith" | "startsWith" | "in" | "after" | "equals" | "notEquals" | "contains" | "notContains" | "isEmpty" | "isNotEmpty" | "greaterThan" | "lessThan" | "greaterOrEqual" | "lessOrEqual" | "before" | "between" | "notIn" | "isNull" | "isNotNull" | "exists" | "notExists")[];
+export declare const FILTER_BUILDER_OPERATORS: ("endsWith" | "startsWith" | "in" | "after" | "equals" | "notEquals" | "contains" | "containsCaseInsensitive" | "notContains" | "isEmpty" | "isNotEmpty" | "greaterThan" | "lessThan" | "greaterOrEqual" | "lessOrEqual" | "before" | "between" | "notIn" | "isNull" | "isNotNull" | "exists" | "notExists")[];
 /** An operator id the FilterBuilder can render. */
 export type FilterBuilderOperator = (typeof defaultOperators)[number]['value'];
-declare function FilterBuilder({ fields, value, onChange, className, showClearAll, }: FilterBuilderProps): React.JSX.Element;
+/**
+ * Operator ids for which this builder renders NO value input — so "no value"
+ * is the row's FINISHED state, not an unfinished one (objectui#4744).
+ *
+ * This is the source of truth for that distinction, and it lives here because
+ * this component is the thing that decides it: `needsValueInput` below is
+ * defined as the complement of this set, so the two cannot say different
+ * things. Every consumer that has to tell a complete value-less row from a
+ * half-filled one reads it FROM here rather than restating it:
+ *
+ *   - `plugin-list`'s `convertFilterGroupToAST` — what the live grid QUERIES;
+ *   - `app-shell`'s `foldFilterGroupToSpecRules` — what a saved view PERSISTS
+ *     (its `VALUELESS_FILTER_OPERATORS` is this set plus the canonical spec
+ *     spellings, which only that layer sees).
+ *
+ * Placement is forced by the dependency graph — `app-shell` depends on
+ * `plugin-list` depends on this package, so this is the only module all three
+ * can reach — and it is also where the set belongs on the merits: the fact it
+ * states is a fact about what this dropdown draws.
+ *
+ * Why it exists at all: each consumer used to keep its own copy, and the
+ * live-grid copy listed only `isEmpty`/`isNotEmpty`. A fresh row is seeded
+ * `{ operator: 'equals', value: '' }` and the operator dropdown preserves
+ * `value`, so picking **Is null** as the first action left `value: ''` — the
+ * grid read that as an unfinished row, dropped it, and applied NO filter at
+ * all while the panel showed one. Silent, and every record came back.
+ *
+ * `exists` / `notExists` stay listed even though `OPT_IN_OPERATORS` withholds
+ * them from most consumers (objectui#4736): the builder still draws them
+ * value-less for `FilterConditionField`, which is exactly what this set
+ * describes. Whether a consumer can EXPRESS an operator is a separate
+ * question, answered by `OPT_IN_OPERATORS` and by each consumer's parity test.
+ */
+export declare const VALUELESS_FILTER_BUILDER_OPERATORS: ReadonlySet<string>;
+/**
+ * The SHAPE an operator's `value` must have — the question
+ * `ViewFilterRuleSchema` asks, asked here in the one place that decides what
+ * input the user is given (objectui#3958).
+ *
+ *   - `list` — membership over any arity, `[]` included (`in` / `not_in`).
+ *   - `pair` — exactly two bounds, in order (`between`).
+ *   - `scalar` — everything else, including the value-less operators above
+ *     (they draw no input at all, so their shape never reaches storage).
+ */
+export type FilterValueArity = "scalar" | "list" | "pair";
+/**
+ * Which value shape `operator` takes, in EITHER dialect.
+ *
+ * The argument is folded through the spec's own `normalizeFilterOperator`
+ * first, so the builder's camelCase dropdown ids (`notIn`) and the canonical
+ * spellings a stored rule carries (`not_in`) land on the same answer. That
+ * fold is the whole point: one vocabulary, declared upstream, consulted here —
+ * not a second local dialect that has to be kept in sync by hand.
+ *
+ * @internal exported for tests
+ */
+export declare function filterValueArity(operator: string): FilterValueArity;
+/**
+ * Re-shape a row's `value` for the operator it is being changed TO.
+ *
+ * Switching the operator dropdown used to update `operator` alone, so the
+ * value the previous family had produced simply survived the switch — a scalar
+ * `"acme"` (or the seed `""`) still sitting there under `in`, which is
+ * precisely the shape `ViewFilterRuleSchema` refuses. Re-shaping rather than
+ * blanking keeps what the user typed wherever it still means something:
+ *
+ *   - to `list`: a scalar becomes a one-element list (`"acme"` → `["acme"]`),
+ *     an empty scalar becomes `[]` — a real, spec-valid predicate;
+ *   - to `pair`: the first two entries become `[min, max]`, padded with `""`;
+ *     with nothing to carry it collapses to `[]`, which the write path reads
+ *     as "row not filled in yet" and drops, exactly as it drops an empty
+ *     scalar today;
+ *   - to `scalar`: the first entry of a list survives; the rest cannot, and
+ *     dropping them is the honest answer — `equals` compares against one value.
+ *
+ * @internal exported for tests
+ */
+export declare function reshapeFilterValue(value: FilterBuilderCondition["value"], nextOperator: string): FilterBuilderCondition["value"];
+/**
+ * The operator a row keeps after its FIELD is changed, given the operators the
+ * NEW field offers (objectui#4768).
+ *
+ * Each field type has its own operator bucket, and the buckets are not nested:
+ * a `select` column offers `in` / `notIn`, a `text` column does not. Changing
+ * the field used to write `{ field }` alone, so the row's operator survived
+ * into a bucket that no longer contains it — `in` on a text column. The Radix
+ * trigger then had nothing to render (its `SelectValue` matches against the
+ * `SelectItem`s actually mounted) and went BLANK, while the row went on
+ * filtering by an operator the user could no longer see or reach.
+ *
+ * So the two edits are one edit, exactly as `changeOperator` made the operator
+ * and its value shape one edit: an operator the new bucket still offers is the
+ * user's choice and is KEPT; one it does not is replaced by the bucket's first
+ * entry (`equals` for every bucket this builder draws), and the caller then
+ * re-shapes the value for that operator's family.
+ *
+ * Membership is decided CANONICALLY, through the spec's own
+ * `normalizeFilterOperator` — the same fold `filterValueArity` uses. A stored
+ * rule can reach this builder spelled `not_in` while the dropdown lists the
+ * alias `notIn`; those are one operator, so a select→lookup switch must not
+ * silently rewrite the author's operator to `equals` just because the two
+ * spellings differ. The fold is safe to compare through because it is
+ * INJECTIVE over this builder's vocabulary — all 22 ids in `defaultOperators`
+ * normalize to 22 distinct canonical operators, pinned in
+ * `filter-builder-field-switch-operator.test.tsx` — so no two OFFERED
+ * operators can ever collapse onto one another.
+ *
+ * @internal exported for tests
+ */
+export declare function reconcileOperatorForField(operator: string, offeredOperators: ReadonlyArray<{
+    value: string;
+}>): string;
+/**
+ * Re-TYPE a row's `value` for the field it is being changed TO — the type
+ * question, standing beside {@link reshapeFilterValue}'s shape question
+ * (objectui#4781).
+ *
+ * Changing a row's field used to carry the value through untouched whenever the
+ * shape did not have to change, which is right about the shape and wrong about
+ * the type: the value input is re-drawn from the NEW field's type, and an
+ * `<input type="number">` renders a non-numeric value as BLANK. So a `text`
+ * row filtered `equals "acme"`, pointed at a number column, showed an empty box
+ * while the row went on carrying `"acme"` — `foldFilterGroupToSpecRules`
+ * persisted it and the live grid queried `amount equals "acme"`. The same
+ * invisible-value shape objectui#4768 closed on the operator, one column over.
+ *
+ * Carry-if-possible, exactly as `reshapeFilterValue` carries what it can across
+ * a family change: `"42"` moved to a number column becomes `42` and survives;
+ * `"acme"` cannot be read as a number by any clean reading, so it clears to the
+ * family's empty shape — scalar `""`, list `[]`, pair `[]`. What a value can
+ * become is decided in one place, {@link convertScalarToFamily}.
+ *
+ * The arity is read from the operator through the same `filterValueArity` fold
+ * the rest of this component uses, because each shape clears differently:
+ *
+ *   - `scalar` — converted, or `""`.
+ *   - `list` — converted ENTRY BY ENTRY, keeping the ones that carry:
+ *     `["42", "acme"]` → `[42]`, and `[]` when none do. Reachable today only
+ *     between the two buckets that offer `in`/`notIn` (`select` ↔ `lookup`),
+ *     which are both text-family, so the conversion is the identity there; it
+ *     is written for the family the operator lands in rather than for today's
+ *     buckets, and pinned directly on this helper.
+ *   - `pair` — both bounds converted independently, an unconvertible bound
+ *     becoming `""` so the range keeps its two slots; both empty collapses to
+ *     `[]`, the "not filled in yet" shape `reshapeFilterValue` also produces
+ *     and the write path drops.
+ *
+ * @internal exported for tests
+ */
+export declare function retypeFilterValue(value: FilterBuilderCondition["value"], fieldType: string | undefined, operator: string): FilterBuilderCondition["value"];
+/** The shape of a `fields` entry that the option-domain helpers below read. */
+type OptionBearingField = {
+    type?: string;
+    options?: ReadonlyArray<{
+        value: string;
+        label: string;
+    }>;
+};
+/**
+ * Narrow a row's `value` to the option DOMAIN of the field it is being changed
+ * TO — the value-domain question, standing beside {@link retypeFilterValue}'s
+ * type question and {@link reshapeFilterValue}'s shape question
+ * (objectui#4874).
+ *
+ * objectui#4781 settled the TYPE half and deliberately stopped there: `select`
+ * and `lookup` are text-family, so `"acme"` is a value those columns can
+ * perfectly well HOLD. What it cannot be is one of the column's options — and
+ * the control drawn for those columns is a Radix Select, whose trigger renders
+ * only what one of its mounted `SelectItem`s carries. So a text row filtered
+ * `equals "acme"`, pointed at a picklist column of `won`/`lost`, showed a BLANK
+ * trigger while the row went on carrying `"acme"`:
+ * `foldFilterGroupToSpecRules` persisted it and the live grid queried
+ * `stage equals "acme"`. The third face of the same invisible value —
+ * objectui#4768 on the operator, objectui#4781 on the value's type, this one on
+ * its domain.
+ *
+ * Ruled 2026-08-17 as **A + C combined**, and the A half is this function:
+ * clear on non-membership, but ONLY where the option set is the column's whole
+ * domain ({@link hasStaticOptionDomain}). A remote/async column's value is
+ * returned untouched — clearing it would delete a perfectly valid lookup id on
+ * the strength of a local page that never claimed to be complete, and the C
+ * half (the render path's temporary option) is what keeps it visible instead.
+ * Option B — keep the value and tolerate it being invisible — stays rejected,
+ * as it was on objectui#4781.
+ *
+ * The empty shape a cleared value falls to is objectui#4781's, unchanged and
+ * read from the same `filterValueArity` fold:
+ *
+ *   - `scalar` — `""`.
+ *   - `list` — filtered ENTRY BY ENTRY, keeping the members: `["acme", "won"]`
+ *     → `["won"]`, and `[]` when none survive. Per-entry rather than
+ *     all-or-nothing because each entry is its own filter term, and one bad
+ *     term is no reason to throw away the user's good ones.
+ *   - `pair` — untouched; `between` is not option-driven.
+ *
+ * @internal exported for tests
+ */
+export declare function narrowFilterValueToOptions(value: FilterBuilderCondition["value"], field: OptionBearingField | undefined, operator: string): FilterBuilderCondition["value"];
+/**
+ * Is this row's value FINISHED for the operator it carries — the arity-aware
+ * reading of "the user has filled this in" (objectstack#8815).
+ *
+ * Both write paths used to ask this with one shape-blind predicate:
+ *
+ * ```ts
+ * value == null || value === '' || (Array.isArray(value) && value.length === 0)
+ * ```
+ *
+ * which is right for `scalar` and `list` and WRONG for `pair`. A `between` row
+ * with one bound typed is `["2024-01-01", ""]` — an array of length 2, so it
+ * read as complete, and both consumers carried it through. The live grid then
+ * queried a range with an empty upper bound and the server refused the whole
+ * view (`400 INVALID_FILTER`), which is the "该视图的查询被拒绝" the reporter
+ * hit; the saved-view path persisted the same half-range, so the refusal came
+ * back on every later read of that view.
+ *
+ * The spec cannot catch this on the way past — measured against
+ * `ViewFilterRuleSchema` on `@objectstack/spec` 17.0.0: `["2024-01-01", ""]` is
+ * ACCEPTED (it counts the two slots, not what is in them), while a scalar or a
+ * one-element array is refused. So the empty bound sails through authoring
+ * validation and only dies at query time, one layer too late to be actionable.
+ * That makes it the PRODUCER's job to not emit it — this component is what
+ * decides when a row is finished, exactly as it already decides which operators
+ * finish with no value at all ({@link VALUELESS_FILTER_BUILDER_OPERATORS}), and
+ * for the same reason: each consumer keeping its own copy is how the two came to
+ * disagree in the first place.
+ *
+ * The arity is read through the same `filterValueArity` fold the rest of this
+ * file uses, so a stored rule spelled canonically gets the same answer as the
+ * dropdown's own id.
+ *
+ * What each shape needs:
+ *
+ *   - `pair` — BOTH bounds present. A range missing an end is not a narrower
+ *     range, it is a query the server refuses.
+ *   - `list` — at least one entry; `[]` is the "nothing chosen yet" shape.
+ *   - `scalar` — anything that is not the unfilled shape.
+ *
+ * "Present" is {@link isValueUnset}, never `!bound` (objectui#4873): `0` is a
+ * real bound on a number column and `false` is a real value, and reading either
+ * as unfilled would drop a filter the user can see on screen.
+ *
+ * This answers the VALUE question only. Whether an operator wants a value at all
+ * stays with each caller, because the two layers see different vocabularies:
+ * `app-shell` also has to recognise the canonical spellings (`is_null`) that
+ * never reach this dropdown.
+ *
+ * @internal exported for tests
+ */
+export declare function isFilterValueComplete(operator: string, value: FilterBuilderCondition["value"] | undefined | null): boolean;
+/**
+ * The operators the dropdown offers for a field of `fieldType`, given the
+ * opt-in ids this instance was granted.
+ *
+ * A pure function rather than a closure so the selection rule — and above all
+ * the {@link OPT_IN_OPERATORS} gate, whose whole job is to keep an operator OFF
+ * the surfaces that cannot store it — is assertable without driving a Radix
+ * popover open in jsdom.
+ *
+ * @internal exported for tests
+ */
+export declare function operatorsForFieldType(fieldType: string | undefined, extraOperators?: readonly string[]): ReadonlyArray<{
+    value: string;
+    label: string;
+}>;
+declare function FilterBuilder({ fields, value, onChange, className, showClearAll, extraOperators, }: FilterBuilderProps): React.JSX.Element;
 declare namespace FilterBuilder {
     var displayName: string;
 }

package/dist/custom/fullscreen-editor.d.ts

@@ -0,0 +1,102 @@
+import { default as React } from 'react';
+/**
+ * The accessibility attributes the dialog's injected editor MUST carry, handed
+ * to `children` as its required fourth argument (objectui#4824 / #4832).
+ *
+ * Shaped as a spreadable set of real DOM attributes rather than the ids behind
+ * them, on purpose: `{...aria}` is the whole integration, so a host cannot get
+ * the composition subtly wrong, cannot name a node outside the dialog, and
+ * cannot compute its own `aria-invalid` from a prop it forgot to plumb — the
+ * three ways every one of the three surfaces got this wrong before.
+ */
+export interface FullscreenEditorAria {
+    /**
+     * The dialog title's text node — the field label (#3393) reused as the
+     * control's accessible name rather than a second, string-valued author for it.
+     */
+    'aria-labelledby': string;
+    /** Mirrors `error`, so the dialog cannot disagree with the inline control. */
+    'aria-invalid': boolean;
+    /**
+     * The dialog-local message node. A SINGLE id, present only when `error` is —
+     * `aria-errormessage` is exposed only alongside `aria-invalid="true"`, and
+     * this repo's toolchain does not accept an id list here.
+     */
+    'aria-errormessage'?: string;
+}
+export interface FullscreenEditorProps {
+    /**
+     * The committed value. Seeds the draft each time the dialog opens — read at
+     * open time, not held, so a value that changes underneath while the dialog is
+     * closed is picked up on the next open.
+     */
+    value: string;
+    /** Called once with the draft when the user confirms. Gated — see above. */
+    onCommit: (next: string) => void;
+    /** Field label — the dialog title and part of the toggle's accessible name. */
+    label?: string;
+    /**
+     * Namespace for this surface's fullscreen test ids:
+     * `<prefix>-fullscreen-toggle` / `-dialog` / `-save`. One form can contain a
+     * textarea AND a markdown field, so a single shared id would leave a test
+     * unable to say which surface it had found. The injected editor's own test id
+     * belongs to `children` for the same reason.
+     */
+    testIdPrefix: string;
+    /**
+     * The host field is shown plainly and is not editable. Renders NO affordance
+     * at all — see the `readOnly` / `disabled` section above for why this is not
+     * a disabled toggle.
+     *
+     * **Producers**: the form renderer's built-in `textarea` branch, which
+     * resolves it from the field's static `readonly` and from a `readonlyWhen`
+     * CEL rule. The registered widgets early-return a read-only display before
+     * they render this component, so they never pass it.
+     */
+    readOnly?: boolean;
+    /**
+     * The host field is not interactive. Disables the toggle, the "Done" button
+     * and the write-back, and is handed to `children` so the host's own editor
+     * renders inert too.
+     *
+     * **Producer**: the form renderer computes `disabled || fieldDisabled ||
+     * isSubmitting || optionGroupGated` and both forwards it to registered
+     * widgets and applies it on the built-in branch.
+     */
+    disabled?: boolean;
+    /**
+     * The field's validation message, or `undefined` when the field is valid.
+     *
+     * **Required, not optional** (objectui#4824). Every consumer already has it —
+     * the registered widgets take `error` off the widget props contract
+     * (objectui#3222), the built-in branch reads `fieldState.error?.message` — and
+     * an omitted `error` reproduces this issue exactly: a dialog that announces
+     * `aria-invalid="false"` while the same field's inline control announces
+     * `true`. A key the type system makes every call site answer cannot be
+     * forgotten by the next surface; an optional one was, three times.
+     *
+     * **Producers**: `TextAreaField`, `RichTextField`, and the form renderer's
+     * built-in `textarea` branch (which reads it off the PRE-strip props, exactly
+     * like `label` — `stripRendererOnlyProps` discards `error` for the DOM).
+     */
+    error: string | undefined;
+    /**
+     * The editor itself, rendered inside the dialog body against the draft. The
+     * host passes the SAME editor it renders inline.
+     *
+     * The third argument is this component's `disabled`, and the host is expected
+     * to put it on the control it renders: only the host knows which element its
+     * editor's disabled state belongs on. Ignoring it is not a write-back hole —
+     * `onCommit` is gated here regardless — but it does leave a control that looks
+     * editable while the field is not, so every in-repo host applies it.
+     *
+     * The fourth argument is the accessibility set this component owns — name and
+     * validation state — and it is spread onto the control the host renders. See
+     * `FullscreenEditorAria` and the section above for why it is computed here
+     * rather than by each host.
+     */
+    children: (draft: string, setDraft: (next: string) => void, disabled: boolean, aria: FullscreenEditorAria) => React.ReactNode;
+    /** Optional footer status for the draft (e.g. a character counter). */
+    footer?: (draft: string) => React.ReactNode;
+}
+export declare function FullscreenEditor({ value, onCommit, label, testIdPrefix, readOnly, disabled, error, children, footer, }: FullscreenEditorProps): React.JSX.Element | null;