@object-ui/fields 17.2.0 → 17.5.0

package/src/datetime-widgets.test.tsx

@@ -1,3 +1,4 @@
+import React from 'react';
 import { render, screen, fireEvent } from '@testing-library/react';
 import { describe, it, expect, vi } from 'vitest';
 import { DateField } from './widgets/DateField';
@@ -54,10 +55,15 @@ describe('Date/Time Widgets', () => {
         });
 
         it('calls onChange when value changes', () => {
-            const { container } = render(<DateTimeField {...baseProps} />);
+            const onChange = vi.fn();
+            const { container } = render(<DateTimeField {...baseProps} onChange={onChange} />);
             const input = container.querySelector('input[type="datetime-local"]') as HTMLInputElement;
             fireEvent.change(input, { target: { value: '2023-01-01T12:00' } });
-            expect(baseProps.onChange).toHaveBeenCalledWith('2023-01-01T12:00');
+            // The control speaks zone-less local wall clock; form state holds
+            // ISO, the shape the API hands back and `toDateTimeInputValue`
+            // reads (objectui#3127). Storing the naive string instead would put
+            // read and write on different timezone bases.
+            expect(onChange).toHaveBeenCalledWith(new Date('2023-01-01T12:00').toISOString());
         });
 
         it('renders formatted datetime in readonly mode', () => {
@@ -71,6 +77,92 @@ describe('Date/Time Widgets', () => {
         });
     });
 
+    /**
+     * objectui#3127 — the record's stored ISO value reached the native control
+     * verbatim, and `<input type="date">` / `<input type="datetime-local">`
+     * reject anything but their one exact shape SILENTLY: the attribute lands
+     * in the DOM, `.value` reads back `''`, and the user sees an empty box on a
+     * field that has a value. `.value` (not `getAttribute('value')`) is
+     * therefore the only assertion that can see this bug at all.
+     */
+    describe('existing values round-trip through the native controls (#3127)', () => {
+        // The seeded showcase value. Whole minutes and no sub-second part, so
+        // the control (which has minute resolution) can represent it exactly
+        // and the round trip below is lossless in every timezone.
+        const storedIso = '2026-06-17T14:30:00.000Z';
+
+        it('DateTimeField shows a stored ISO instant instead of an empty box', () => {
+            const { container } = render(<DateTimeField {...baseProps} value={storedIso} />);
+            const input = container.querySelector('input[type="datetime-local"]') as HTMLInputElement;
+
+            expect(input.value).not.toBe('');
+            expect(input.value).toMatch(/^\d{4}-\d{2}-\d{2}T\d{2}:\d{2}$/);
+            // The shown wall clock denotes the SAME instant as the record —
+            // asserted this way so the test holds in every timezone, which a
+            // hardcoded "2026-06-17T22:30" would not.
+            expect(new Date(input.value).getTime()).toBe(new Date(storedIso).getTime());
+        });
+
+        it('DateTimeField writes back on the same basis it reads', () => {
+            // Read and write must share one timezone basis. Displaying local
+            // while storing the naive local string is the worse bug: the value
+            // would silently drift by the viewer's offset on every edit.
+            const onChange = vi.fn();
+            const { container } = render(
+                <DateTimeField {...baseProps} onChange={onChange} value={storedIso} />
+            );
+            const input = container.querySelector('input[type="datetime-local"]') as HTMLInputElement;
+
+            fireEvent.change(input, { target: { value: '2026-06-18T09:15' } });
+
+            const written = onChange.mock.calls[0][0];
+            // Zone-QUALIFIED, which the control's own output is not. Storing
+            // the raw `2026-06-18T09:15` is what puts the write on a different
+            // basis from the read: the server has no way to know whose 09:15
+            // it is, and resolves it to a different instant than the one the
+            // user picked.
+            expect(written).toMatch(/(Z|[+-]\d{2}:\d{2})$/);
+            expect(new Date(written).getTime()).toBe(new Date('2026-06-18T09:15').getTime());
+        });
+
+        it('DateTimeField returning to the shown minute restores the exact stored value', () => {
+            // Guards the drift this fix could otherwise introduce: if the two
+            // conversions disagreed by the viewer's UTC offset, navigating away
+            // from a value and back would land somewhere else, and every open →
+            // fiddle → undo would quietly move the record.
+            // Held in real state, because a `vi.fn()` onChange would leave the
+            // control pinned to its initial prop and React would swallow the
+            // second edit as a no-op — the test would pass without exercising
+            // anything.
+            const seen: string[] = [];
+            const Host = () => {
+                const [v, setV] = React.useState<string>(storedIso);
+                seen.push(v);
+                return <DateTimeField {...baseProps} value={v} onChange={setV as any} />;
+            };
+            const { container } = render(<Host />);
+            const input = container.querySelector('input[type="datetime-local"]') as HTMLInputElement;
+            const shown = input.value;
+
+            fireEvent.change(input, { target: { value: '2026-06-18T09:15' } });
+            fireEvent.change(input, { target: { value: shown } });
+
+            expect(seen[seen.length - 1]).toBe(storedIso);
+        });
+
+        it('DateField shows the stored calendar day, ISO-shaped or not', () => {
+            // Both spellings the API may hand back for a `date` field. The day
+            // must survive verbatim — re-parsing the bare form as UTC midnight
+            // would move it to the 16th west of Greenwich.
+            for (const stored of ['2026-06-17', '2026-06-17T00:00:00.000Z']) {
+                const { container, unmount } = render(<DateField {...baseProps} value={stored} />);
+                const input = container.querySelector('input[type="date"]') as HTMLInputElement;
+                expect(input.value).toBe('2026-06-17');
+                unmount();
+            }
+        });
+    });
+
     describe('TimeField', () => {
         it('renders time input in edit mode', () => {
             const { container } = render(<TimeField {...baseProps} />);

package/src/field-type-alias.multiple.test.ts

@@ -0,0 +1,81 @@
+/**
+ * ObjectUI
+ * Copyright (c) 2024-present ObjectStack Inc.
+ *
+ * This source code is licensed under the MIT license found in the
+ * LICENSE file in the root directory of this source tree.
+ */
+
+/**
+ * The widget id is a function of the (type, `multiple`) PAIR, not of the type
+ * string alone (objectui#3986).
+ *
+ * `mapFieldTypeToFormType` mapped `select` to `field:select` unconditionally,
+ * while `SelectField` delegated to `MultiSelectField` whenever the metadata said
+ * `multiple`. Three correct pieces, one gap between them: the component that
+ * RENDERED was `MultiSelectField`, but everything keyed on the widget id — above
+ * all the label-association declaration (`ComponentMeta.labelling`, resolved via
+ * `getMeta('select')`) — was still answering for the single-value combobox. The
+ * host label of a normal `{ type: 'select', multiple: true }` picklist therefore
+ * emitted a `for` at the chip row's wrapper `div`, where a `for` is inert.
+ *
+ * `select` cannot simply be declared `labelling: 'group'` instead: the
+ * single-value trigger IS labelable, and a bare `select` is a builtin the form
+ * renderer resolves without the registry at all (pinned in
+ * `form-group-label-association.test.ts`). The producer has to name the widget
+ * that renders, which is what this file pins.
+ *
+ * Metadata only — nothing renders here, so no widget module is loaded.
+ */
+
+import { describe, it, expect } from 'vitest';
+import { mapFieldTypeToFormType } from './field-type-alias';
+
+describe('select carries its arity in the widget id (objectui#3986)', () => {
+  it('maps select + multiple to the multi-value widget', () => {
+    // The one assertion that was `field:select` before this change.
+    expect(mapFieldTypeToFormType('select', { multiple: true })).toBe('field:multiselect');
+  });
+
+  it('keeps the single-value widget without multiple, and for multiple: false', () => {
+    // The guard direction: single-select must not move. Its trigger is a
+    // labelable `button[role=combobox]` and its `for` association works — taking
+    // that away would break a field that is fine to fix one that is not.
+    expect(mapFieldTypeToFormType('select')).toBe('field:select');
+    expect(mapFieldTypeToFormType('select', {})).toBe('field:select');
+    expect(mapFieldTypeToFormType('select', { multiple: false })).toBe('field:select');
+    expect(mapFieldTypeToFormType('select', { multiple: null })).toBe('field:select');
+  });
+
+  it('is idempotent for the type that is already inherently multi', () => {
+    // `multiselect` is a type in its own right; the arity override must not turn
+    // it into something else, whichever way the flag is set.
+    expect(mapFieldTypeToFormType('multiselect')).toBe('field:multiselect');
+    expect(mapFieldTypeToFormType('multiselect', { multiple: true })).toBe('field:multiselect');
+  });
+
+  /**
+   * The spec's multi-capable set is larger than the widget-moving set, and the
+   * difference is the whole reason this override is table-driven rather than a
+   * `config.multiple` branch sprinkled per type:
+   *
+   *   `MULTI_CAPABLE_TYPES` = select / lookup / file / image (+ `radio` on the
+   *   select branch, `user` storing like `lookup`)
+   *
+   * Every member except `select` renders BOTH arities inside one widget —
+   * `LookupField`, `FileField`, `ImageField` each read `multiple` themselves — so
+   * their widget id, and with it their `labelling` declaration, is correct for
+   * either arity. Moving them would point at widgets that do not exist.
+   */
+  const UNMOVED_MULTI_CAPABLE = ['lookup', 'master_detail', 'user', 'owner', 'file', 'image', 'radio'] as const;
+
+  it.each(UNMOVED_MULTI_CAPABLE)('%s resolves identically with and without multiple', (type) => {
+    expect(mapFieldTypeToFormType(type, { multiple: true })).toBe(mapFieldTypeToFormType(type));
+  });
+
+  it('does not invent a widget for an unknown type flagged multiple', () => {
+    // The fallback is unchanged: an unknown type is `field:text` at either arity,
+    // never `field:text-multiple`-anything.
+    expect(mapFieldTypeToFormType('something-unknown', { multiple: true })).toBe('field:text');
+  });
+});

package/src/field-type-alias.ts

@@ -6,15 +6,63 @@
  * LICENSE file in the root directory of this source tree.
  */
 
+/**
+ * The slice of a field definition the widget decision reads beyond `type`.
+ *
+ * Structural (not the spec `Field`) for the same reason the spec's own
+ * `ValueShapeFieldDef` is: every caller — object-schema metadata, a spec
+ * `FormFieldSchema` override, an action param def — can pass its own trimmed
+ * shape verbatim. `multiple` is the only key read; nothing else here is
+ * consulted, so a caller that has the whole metadata object may hand it over
+ * as-is.
+ */
+export interface FieldTypeMappingConfig {
+  /** `FieldSchema.multiple` — the field holds zero-or-more values. */
+  multiple?: boolean | null;
+}
+
+/**
+ * Field types whose `multiple: true` form is a DIFFERENT registered widget,
+ * rather than the same widget in another mode (objectui#3986).
+ *
+ * `select` is the only member, and the narrowness is measured, not assumed. The
+ * spec's `MULTI_CAPABLE_TYPES` is larger — select / lookup / file / image, with
+ * `radio` on the select branch and `user` storing like `lookup` — but every
+ * other member renders both arities INSIDE one widget: `LookupField`,
+ * `FileField` and `ImageField` each branch on `multiple` themselves, so their
+ * registry id, and with it their `labelling` declaration, is the same either
+ * way. A `select` declared `multiple: true` renders `MultiSelectField` instead:
+ * a different component, whose labelled surface is a chip row's container that
+ * a `<label for>` cannot address (it must be named by IDREF, which is what
+ * `field:multiselect`'s `labelling: 'group'` declares — objectui#3975/#3961).
+ *
+ * So the widget id has to carry the arity. When it did not, the host label was
+ * associated by the declaration registered under `select` — a single-value
+ * combobox that was NOT rendering — and the visible label of a normal
+ * `{ type: 'select', multiple: true }` picklist named nothing at all. One place
+ * decides which widget renders, so the declaration and the render cannot
+ * disagree again.
+ */
+const MULTI_VALUE_FORM_TYPES: Record<string, string> = {
+  select: 'field:multiselect',
+};
+
 /**
  * Map field type to form component type
- * 
+ *
  * @param fieldType - The ObjectQL field type identifier to convert
  * (for example: `"text"`, `"number"`, `"date"`, `"lookup"`).
+ * @param config - The rest of the field definition, for the types whose widget
+ * identity depends on more than the type string. Only `multiple` is read; see
+ * {@link MULTI_VALUE_FORM_TYPES}. Omitting it maps the single-value form, which
+ * is what every non-multi-capable type resolves to anyway.
  * @returns The normalized form field type string used in the form schema
  * (for example: `"input"`, `"textarea"`, `"date-picker"`, `"select"`).
  */
-export function mapFieldTypeToFormType(fieldType: string): string {
+export function mapFieldTypeToFormType(
+  fieldType: string,
+  config?: FieldTypeMappingConfig,
+): string {
   const typeMap: Record<string, string> = {
     // Text-based fields
     text: 'field:text',
@@ -96,5 +144,13 @@ export function mapFieldTypeToFormType(fieldType: string): string {
     auto_number: 'field:auto_number',
   };
 
+  // The arity override comes FIRST and is table-driven: only a type listed in
+  // `MULTI_VALUE_FORM_TYPES` has a second widget to move to, so `multiple` on
+  // any other type (a multi `lookup`, a multi `file`) resolves exactly as
+  // before and keeps reaching the widget that handles both arities itself.
+  if (config?.multiple && MULTI_VALUE_FORM_TYPES[fieldType]) {
+    return MULTI_VALUE_FORM_TYPES[fieldType];
+  }
+
   return typeMap[fieldType] || 'field:text';
 }

package/src/index.css

@@ -0,0 +1,44 @@
+/*
+ * Tailwind entry for `@object-ui/fields` — BUILD-TIME ONLY.
+ *
+ * Consumers never compile this file. They import the compiled artifact:
+ *
+ *   @import '@object-ui/components/style.css';
+ *   @import '@object-ui/fields/style.css';   <- ./dist/index.css, built from this
+ *
+ * The `@reference` below is what makes the "narrow" shape possible
+ * (objectui#4059): it gives this compilation `@object-ui/components`' theme
+ * tokens, its class-based `dark` variant and its `tailwindcss-animate` plugin
+ * WITHOUT emitting a single byte of them. So the sheet built from this entry
+ * carries utilities only — no preflight, no `@theme` `:root` block, no base
+ * layer. `@object-ui/components`' own stylesheet owns all of that, and
+ * `scripts/build-css.mjs` then subtracts every rule that sheet already ships.
+ *
+ * That is why the import ORDER above is not cosmetic: this sheet is a
+ * supplement to the components sheet, not a replacement for it.
+ *
+ * This file has no `@import 'tailwindcss'` on purpose — that would pull in
+ * preflight and re-emit the shared theme, which is exactly the ~160 kB
+ * duplication the narrow variant exists to avoid.
+ */
+@reference '../../components/src/index.css';
+
+/*
+ * `source(none)` is load-bearing, not tidiness. Tailwind's automatic source
+ * detection resolves against the PROCESS CWD, and `@reference` above pulls in
+ * components' entry, whose own `@import 'tailwindcss'` turns that detection on.
+ * Without `source(none)` the candidate set therefore depends on where the build
+ * was launched from: run from this package it scanned `packages/fields` and
+ * produced a 21 kB sheet, run from the repo root it scanned the whole workspace
+ * and produced a 287 kB one full of other packages' utilities. Same commit, same
+ * command, two different published artifacts.
+ *
+ * With it, the ONLY inputs are the explicit `@source` lines below, and the
+ * output is byte-identical from any working directory.
+ */
+@import 'tailwindcss/utilities.css' layer(utilities) source(none);
+
+/* Only shipped source: `*.test.tsx` never reaches a consumer, so utilities used
+   solely by tests must not be compiled into the published sheet. */
+@source './**/*.{ts,tsx}';
+@source not './**/*.test.{ts,tsx}';