@lumiose/ui 0.1.1 → 0.1.3

package/dist/toggle-group/toggle-group.tsx

@@ -11,6 +11,7 @@ import {
 } from "../toggle/context.ts";
 import type { ToggleGroupElement } from "./toggle-group.script.ts";
 import toggleGroupScript from "./toggle-group.script.ts?client";
+import { batched } from "../batched.ts";
 
 declare module "lumiose/jsx-runtime" {
   namespace JSX {
@@ -39,7 +40,10 @@ type ElementProps = {
  * `aria-labelledby`. `bind:value={signal}` stands in for `value` and `onValueChange`.
  */
 export interface ToggleGroupProps extends Omit<ElementProps, "children"> {
-  /** Presses the toggles with these values when it changes. Pair it with `onValueChange`. */
+  /**
+   * The pressed toggles. Pair it with `onValueChange`, which updates it: the toggles show `value`
+   * again after each press, so one that `onValueChange` does not take is undone.
+   */
   value?: string[];
   /** The toggles pressed at first, when `value` is left out. */
   defaultValue?: string[];
@@ -104,11 +108,19 @@ export function ToggleGroup({
         multiple={multiple}
         data-orientation={orientation ?? "horizontal"}
         data-loop-focus={loopFocus === false ? "false" : undefined}
-        on:valuechange={() => {
-          const next = element()!.value;
+        on:valuechange={batched(() => {
+          const host = element()!;
+          const next = host.value;
           values.set(next);
           onValueChange?.(next);
-        }}
+          // Controlled: when the callback leaves `value` as it was, the toggles show it again, as
+          // in Base UI (TASK-538). A changed `value` equals the element's, which then does nothing.
+          const held = value;
+          if (held !== undefined) {
+            values.set(held);
+            host.value = held;
+          }
+        })}
       >
         {children}
       </lu-toggle-group>

package/dist/toolbar/toolbar.tsx

@@ -14,6 +14,7 @@ import { Separator, type SeparatorProps } from "../separator/separator.tsx";
 import { ToolbarContext, type ToolbarContextValue } from "./context.ts";
 import type { ToolbarElement } from "./toolbar.script.ts";
 import toolbarScript from "./toolbar.script.ts?client";
+import { notInside } from "../not-inside.ts";
 
 declare module "lumiose/jsx-runtime" {
   namespace JSX {
@@ -63,7 +64,7 @@ export type ToolbarSeparatorProps = SeparatorProps;
 
 function useToolbar(part: string): ToolbarContextValue {
   const context = useContext(ToolbarContext);
-  if (!context) throw new Error(`Toolbar.${part} must be inside <Toolbar.Root>.`);
+  if (!context) throw notInside(`Toolbar.${part}`, "<Toolbar.Root>");
   return context;
 }
 

package/dist/tooltip/tooltip.tsx

@@ -8,6 +8,8 @@
 import { createContext, effect, ref, useContext, useId } from "lumiose";
 import { anchorName, placement, withStyle, type PlacementProps } from "../placement/placement.ts";
 import tooltipScript from "./tooltip.script.ts?client";
+import { batched } from "../batched.ts";
+import { notInside } from "../not-inside.ts";
 
 /**
  * `Tooltip.Root` renders no element: it holds the ids its parts share. `bind:open={signal}`
@@ -61,7 +63,7 @@ const TooltipContext = createContext<TooltipContextValue>();
 
 function useTooltip(): TooltipContextValue {
   const context = useContext(TooltipContext);
-  if (!context) throw new Error("Tooltip parts must be inside <Tooltip.Root>.");
+  if (!context) throw notInside("Tooltip parts", "<Tooltip.Root>");
   return context;
 }
 
@@ -128,7 +130,9 @@ function Popup({
       }}
       id={tooltip.popupId}
       popover="hint"
-      on:toggle={(event: ToggleEvent) => tooltip.props.onOpenChange?.(event.newState === "open")}
+      on:toggle={batched((event: ToggleEvent) =>
+        tooltip.props.onOpenChange?.(event.newState === "open"),
+      )}
     >
       {children}
     </span>

package/docs/README.md

@@ -2,9 +2,8 @@
 
 > `@lumiose/ui`: accessible, unstyled UI primitives built on native elements (`<dialog>`, popover, invoker commands, CSS anchor positioning), server-rendered without hydration. Style them with your own CSS or the optional default theme.
 
-**Status:** in development. `@lumiose/ui` keeps its own 0.x versions, apart from the version all
-other Lumiose packages share, and is not on npm yet: today it is used from this repository's
-workspace. The goal for its 1.0 is parity with [Base UI](https://base-ui.com)'s components; the
+**Status:** in development. `@lumiose/ui` is on npm and keeps its own 0.x versions, apart from
+the version all other Lumiose packages share. The goal for its 1.0 is parity with [Base UI](https://base-ui.com)'s components; the
 table below lists them as they land.
 
 These pages ship in the package, in `node_modules/@lumiose/ui/docs`, so they match the installed
@@ -32,12 +31,19 @@ Anatomy, API, Example, Styling, Keyboard and focus, Without JavaScript, Browser
   runtime.
 - **Parts.** Each component is a set of parts named as in Base UI (`Dialog.Root`,
   `Dialog.Trigger`, `Dialog.Popup`, …). Every part that renders an element takes that element's
-  props (`class`, `style`, `aria-*`, events) and passes them through.
+  props (`class`, `style`, `aria-*`, events) and passes them through. A part finds its `Root`
+  through context, so a `Root` and its parts render on the same side of an island boundary, even
+  where the JSX nests them. A part the page passes to an island as a slot (children or a JSX prop)
+  renders in the page, outside the `Root` the island renders, and the server throws "Combobox
+  parts must be inside <Combobox.Root>"; an island inside a `Root` the page renders does not see
+  that `Root` either. Pass the data as props and render the `Root` and its parts inside the
+  island ([Islands](https://itsjavi.com/lumiose/docs/concepts/islands/)).
 - **Signals.** A component's state is a prop and a callback: `open` with `onOpenChange`, `checked`
   with `onCheckedChange`, `value` with `onValueChange`. Pass a signal's value and write it back in
   the callback to keep both in sync, or leave both out and the element keeps its own state. Custom
   elements report changes with lowercase DOM events, like native ones: `openchange`,
-  `checkedchange` and `change`.
+  `checkedchange` and `change`. The callbacks run inside `batch()`, as event handlers do: what
+  they write renders together, and the DOM is current as soon as the event returns.
 - **Keyboard contracts.** Every component follows its WAI-ARIA Authoring Practices pattern, and
   its end-to-end tests check the keyboard paths.
 - **WCAG 2.2 AA.** Every component meets it: the components own semantics, keyboard and
@@ -70,7 +76,7 @@ custom properties, named as in shadcn/ui, are listed in [Theming](theming.md#the
 | [Tooltip](tooltip.md)                 | Available: native hint popover, opened by its script                                      |
 | [Menu](menu.md)                       | Available: popover menu, opens without JavaScript                                         |
 | [Combobox](combobox.md)               | Available: `<lu-combobox>`, a form control that filters its options                       |
-| [Select](select.md)                   | Available: native `<select>`, customizable where supported, no script                     |
+| [Select](select.md)                   | Available: native `<select>`, customizable where supported, no script but for `label`s    |
 | [Tabs](tabs.md)                       | Available: server HTML with the full state, `<lu-tabs>` adds the keys                     |
 | [Field](field.md)                     | Available: label, description, errors; native validation in the field                     |
 | [Fieldset](fieldset.md)               | Available: native `<fieldset>` and `<legend>`, no script                                  |
@@ -165,7 +171,10 @@ errors are yours.
 `@lumiose/ui` is opt-in, so its size is reported apart from the runtime's caps:
 `pnpm --filter @lumiose/ui size` prints, per component, the JavaScript a server-rendered page loads
 for its custom elements, the JavaScript an island that uses it loads, and its CSS (minified, gzip
-and brotli).
+and brotli). The scripts load as separate modules, in islands too: each component's script, and
+the modules several scripts share (the dismissal model, the placement fallback, the hover timing),
+each a file of its own, as an app's build splits them. The sizes on the component pages are those
+files' brotli sizes added up.
 
 ## Related
 

package/docs/accordion.md

@@ -187,8 +187,9 @@ closed item are HTML features: an accordion in a server-rendered page works befo
 loads, and with none. Disabled triggers ignore the pointer through CSS. `value`, `onValueChange`
 and `bind:value` need the component to run in an island.
 
-A page that renders an `Accordion` loads a 1 kB (brotli) module once, without the Lumiose runtime;
-islands bundle it. It defines `<lu-accordion>`, which adds the arrow keys, Home and End, and sets
+A page that renders an `Accordion` loads its script once, with the panel and animation modules it
+shares with Collapsible: 1.3 kB (brotli) without the Lumiose runtime; an island loads the same
+modules. It defines `<lu-accordion>`, which adds the arrow keys, Home and End, and sets
 the panels' animation hooks (shared with [Collapsible](collapsible.md)); a disabled trigger does
 not toggle, also from the keyboard.
 

package/docs/autocomplete.md

@@ -1,6 +1,6 @@
 # Autocomplete
 
-> A text input with suggestions, for text that may be anything (a search, a tag, an address): the WAI-ARIA combobox pattern with list autocomplete, after Base UI's Autocomplete. Unlike a [Combobox](combobox.md), the text is the value: the input has the name and submits what is typed, and choosing a suggestion only fills it in. It runs on the Combobox's element (`<lu-combobox free>`, 5.0 kB) and parts, on server-rendered pages and in islands; `bind:value` keeps a signal in sync. Filtering, inline completion, groups, an empty state and a status.
+> A text input with suggestions, for text that may be anything (a search, a tag, an address): the WAI-ARIA combobox pattern with list autocomplete, after Base UI's Autocomplete. Unlike a [Combobox](combobox.md), the text is the value: the input has the name and submits what is typed, and choosing a suggestion only fills it in. It runs on the Combobox's element (`<lu-combobox free>`, 5.8 kB) and parts, on server-rendered pages and in islands; `bind:value` keeps a signal in sync. Filtering, inline completion, groups, an empty state and a status.
 
 ```ts
 import { Autocomplete } from "@lumiose/ui"; // or "@lumiose/ui/autocomplete"
@@ -145,7 +145,7 @@ Focus stays in the input: the highlight moves through `aria-activedescendant`.
 ## Without JavaScript, and the element's script
 
 The input is a native text field with the name: typing, `required`, submission and reset work with
-no script; the suggestions need it. `<lu-combobox>`'s script (5.0 kB brotli, shared with Combobox)
+no script; the suggestions need it. `<lu-combobox>`'s script (5.8 kB brotli, shared with Combobox)
 filters and opens them, moves the highlight, fills in a choice (firing `input` and `change` on the
 input) and runs inline completion.
 

package/docs/avatar.md

@@ -180,8 +180,8 @@ when it fails) and hides its fallback, from sight and from assistive technology,
 the avatar twice; an avatar without an image shows its fallback.
 `onLoadingStatusChange` needs the component to run in an island.
 
-A page that renders an `Avatar` loads a 0.5 kB (brotli) script, without the Lumiose runtime;
-islands bundle it. `<lu-avatar>` reads the image's state when it connects (a cached image shows
+A page that renders an `Avatar` loads a 0.5 kB (brotli) script, without the Lumiose runtime; an
+island loads the same module. `<lu-avatar>` reads the image's state when it connects (a cached image shows
 at once), then follows its `load` and `error` events and changes to its `src` and `srcset`. An
 image that is complete without a size (an SVG without intrinsic dimensions, or a broken image) is
 told apart with `decode()`.

package/docs/checkbox-group.md

@@ -3,7 +3,7 @@
 > A group of checkboxes with one value, the list of the checked ones, after Base UI's CheckboxGroup: a native `<fieldset>` whose checkboxes share a name, so the form submits each checked value and a disabled group disables them all, without JavaScript. A parent checkbox checks them all and shows checked, mixed or unchecked as they are; `bind:value` keeps a signal in sync.
 
 ```ts
-import { CheckboxGroup, Checkbox, Fieldset } from "@lumiose/ui"; // or "@lumiose/ui/checkbox-group"
+import { CheckboxGroup, Checkbox, Fieldset } from "@lumiose/ui"; // or "@lumiose/ui/checkbox-group", "@lumiose/ui/checkbox" and "@lumiose/ui/fieldset"
 import "@lumiose/ui/themes/default.css"; // optional: the default theme
 ```
 

package/docs/checkbox.md

@@ -112,7 +112,7 @@ A native checkbox: toggling, submission, `required`, reset and `disabled` (its o
 work with no script.
 
 A page that renders a Checkbox, Checkbox Group, Radio Group or Switch loads one 1.0 kB (brotli)
-script once, without the Lumiose runtime; islands bundle it. It turns server HTML's
+script once, without the Lumiose runtime; an island loads the same module. It turns server HTML's
 `data-indeterminate` into the `indeterminate` property (which has no attribute), makes read-only
 inputs ignore clicks, Space and the label, runs the parent checkbox of a group and a [Radio
 Group](radio-group.md)'s arrow keys, and adds an

package/docs/collapsible.md

@@ -1,6 +1,6 @@
 # Collapsible
 
-> A panel that its trigger shows and hides: a native `<details>` whose `<summary>` is the trigger, so it works in server HTML with no JavaScript, keeps the browser's keyboard handling, and opens when find-in-page or a link lands inside it. A 0.7 kB script adds Base UI's animation hooks. `bind:open` (or `open` and `onOpenChange`) keeps a signal in sync in islands.
+> A panel that its trigger shows and hides: a native `<details>` whose `<summary>` is the trigger, so it works in server HTML with no JavaScript, keeps the browser's keyboard handling, and opens when find-in-page or a link lands inside it. A 0.9 kB script adds Base UI's animation hooks. `bind:open` (or `open` and `onOpenChange`) keeps a signal in sync in islands.
 
 ```ts
 import { Collapsible } from "@lumiose/ui"; // or "@lumiose/ui/collapsible"
@@ -141,8 +141,9 @@ Collapsible in a server-rendered page works before any script loads, and with no
 trigger ignores the pointer through CSS. `open`, `onOpenChange` and `bind:open` need the component
 to run in an island.
 
-A page that renders a `Collapsible` loads a 0.7 kB (brotli) module once, without the Lumiose
-runtime; islands bundle it. It covers every Collapsible and [Accordion](accordion.md) panel on the
+A page that renders a `Collapsible` loads 0.9 kB (brotli) of modules once (its script, and the
+panel and animation modules it shares with Accordion), without the Lumiose runtime; an island
+loads the same modules. It covers every Collapsible and [Accordion](accordion.md) panel on the
 page:
 
 - the animation hooks above, set on every opening and closing, whatever caused it (the trigger,

package/docs/combobox.md

@@ -1,6 +1,6 @@
 # Combobox
 
-> A text input that filters a list of options, for picking one value or several from many: the WAI-ARIA combobox pattern with list autocomplete, after Base UI's Combobox. The input shows the option's label and the form gets its value. `<lu-combobox>`, a 5.4 kB form-associated light-DOM element, runs it on server-rendered pages and in islands; `bind:value` and `bind:open` keep signals in sync. Groups, an empty state, a status, a clear button, multiple values with chips, validation and async options.
+> A text input that filters a list of options, for picking one value or several from many: the WAI-ARIA combobox pattern with list autocomplete, after Base UI's Combobox. The input shows the option's label and the form gets its value. `<lu-combobox>`, a 5.8 kB form-associated light-DOM element, runs it on server-rendered pages and in islands; `bind:value` and `bind:open` keep signals in sync. Groups, an empty state, a status, a clear button, multiple values with chips, validation and async options.
 
 ```ts
 import { Combobox } from "@lumiose/ui"; // or "@lumiose/ui/combobox"
@@ -313,8 +313,9 @@ In the server HTML the input is empty even with a selected value: the input rend
 options, so the server does not know the selected option's label when it writes the input. The
 script puts the label in as it upgrades the element (decision-62).
 
-A page that renders a `Combobox` loads the script once, as a 5.4 kB (brotli) module without the
-Lumiose runtime, and islands bundle it. It defines `lu-combobox`, which upgrades every combobox on
+A page that renders a `Combobox` loads the script once, with the dismissal and placement modules
+it shares with Menu and Popover: 5.8 kB (brotli) without the Lumiose runtime, and an island loads
+the same modules. It defines `lu-combobox`, which upgrades every combobox on
 the page in place: it reads the selection the server rendered (`aria-selected="true"`), puts its
 label in the input (text typed before it ran is kept, as a search), renders the chips, and from
 then on owns the value, the filtering, the popup,

package/docs/context-menu.md

@@ -1,6 +1,6 @@
 # Context Menu
 
-> A menu opened at the pointer by a right-click in its trigger area, a long press on a touch screen, or Shift+F10 and the ContextMenu key: Menu's popup and items, with Menu's keys, typeahead, submenus and dismissal. A 0.6 kB script on top of Menu's (4.6 kB together) opens it; without JavaScript the browser shows its own menu. `bind:open` (or `open` and `onOpenChange`) keeps a signal in sync in islands.
+> A menu opened at the pointer by a right-click in its trigger area, a long press on a touch screen, or Shift+F10 and the ContextMenu key: Menu's popup and items, with Menu's keys, typeahead, submenus and dismissal. A 0.9 kB script on top of Menu's (5.4 kB together) opens it; without JavaScript the browser shows its own menu. `bind:open` (or `open` and `onOpenChange`) keeps a signal in sync in islands.
 
 ```ts
 import { ContextMenu } from "@lumiose/ui"; // or "@lumiose/ui/context-menu"
@@ -175,8 +175,8 @@ Opening a menu at the pointer needs the script: without JavaScript a right-click
 browser's own menu, and the popup stays hidden. `open`, `onOpenChange` and `bind:open` need the
 component to run in an island.
 
-A page that renders a `ContextMenu` loads Menu's script and a 0.6 kB (brotli) one of its own,
-4.6 kB together, without the Lumiose runtime; islands bundle them. The element opens the menu on a
+A page that renders a `ContextMenu` loads Menu's script and a 0.9 kB (brotli) one of its own,
+5.4 kB together, without the Lumiose runtime; an island loads the same modules. The element opens the menu on a
 right-click, a long press or the keys, at the pointer, through a zero-size anchor that it moves
 there (CSS anchor positioning places the popup, with Menu's flips; without it, the shared
 placement script does). Menu's script does the rest: keys, items, submenus, and dismissal shared

package/docs/dialog.md

@@ -221,7 +221,7 @@ server-rendered page works before any script loads, and with none. `open`, `onOp
 
 Where the native element falls short of Base UI's dialog, a small script closes the gap: a page
 that renders a `Dialog` loads it once, as a 1.5 kB (brotli) module without the Lumiose runtime, and
-islands bundle it. It covers every `<dialog>` on the page:
+an island loads the same module. It covers every `<dialog>` on the page:
 
 - a right-click or a second finger outside does not close the dialog;
 - `data-nested-dialog-open` and `--lu-nested-dialogs` on a dialog with open dialogs inside;

package/docs/drawer.md

@@ -182,8 +182,9 @@ The trigger, the close buttons, Escape and the click outside are HTML features,
 drawer in a server-rendered page works before any script loads, and with none, against its edge.
 `open`, `onOpenChange` and `bind:open` need the component to run in an island.
 
-A page that renders a `Drawer` loads Dialog's script and a 1 kB (brotli) one of its own (2.5 kB
-together), without the Lumiose runtime; islands bundle them. The drawer's script handles the
+A page that renders a `Drawer` loads Dialog's script and a 1.1 kB (brotli) one of its own (2.8 kB
+together, with the animation module it shares with Toast), without the Lumiose runtime; an island
+loads the same modules. The drawer's script handles the
 swipe, with the mouse and pen through pointer events and on touch screens through touch events,
 taking the gesture from scrolling only once it is a swipe.
 

package/docs/field.md

@@ -253,8 +253,8 @@ the message Error's id (`Field.Error` without children or `match`) even when the
 Errors with children or a `match`. Give a field that must read well without JavaScript a message
 Error, and its Descriptions before the control.
 
-A page that renders a `Field` loads a 1.7 kB (brotli) script once, without the Lumiose runtime;
-islands bundle it. On a submit attempt (a submit button, Enter in a field, `requestSubmit()` or
+A page that renders a `Field` loads a 1.7 kB (brotli) script once, without the Lumiose runtime; an
+island loads the same module. On a submit attempt (a submit button, Enter in a field, `requestSubmit()` or
 the form's `reportValidity()`; a silent `checkValidity()` changes nothing) it cancels the browser's
 `invalid` bubble for fields that have an Error part for the problem and shows it there instead (the
 browser's message, or one your `validate` set), with the timing above, and focuses the first

package/docs/installation.md

@@ -2,13 +2,13 @@
 
 > Add `@lumiose/ui` to a Lumiose app and import its stylesheets, and the default theme if you want its look. The components then render in server HTML, without an island, and a page loads only the small scripts of the components it renders.
 
-**Status:** `@lumiose/ui` is not on npm yet. In this repository's workspace, an app adds it as
-`"@lumiose/ui": "workspace:*"` in its `dependencies`.
+**Status:** in development, on npm with its own 0.x versions, apart from the version the other
+Lumiose packages share.
 
 ## Add the package
 
 `@lumiose/ui` needs a Lumiose app: it ships its components as TSX, which the app's build compiles
-with the app's own code, and `lumiose` is its peer dependency. Once it is on npm:
+with the app's own code, and `lumiose` is its peer dependency. Install it from npm:
 
 ```sh
 pnpm add @lumiose/ui