[vjeux]

Depends on #8143. Review only this PR's change: vjeux/astryx@a6bcd6d...fe0bb94

Why

ListInput lets people build an ordered list of records, such as guests. Its grip grabbed every touch at once, so swiping over grips on a phone didn't scroll.

What led to it

This is part of the UIKit-parity program, which makes Astryx's components behave like their iOS counterparts on touch screens. Moving Lab's reorders onto core's is part of it. ListInput had its own drag code, duplicating core List's reorder. Following Cindy's direction (her 1272d6a is here), it takes reorderable, the createReorderable object, keyed by getItemKey. Each record ends with core's handle ("Reorder guest 2"), each move goes to onReorder({key, to}), and disabled or loading lists keep their handles inert. Lab reaches core's reorder through @astryxdesign/core/internal/reorder.

Before: <ListInput isReorderable onChange={...} />. After: <ListInput reorderable={createReorderable({onReorder})} getItemKey={...} />.

Options and tradeoffs

• Keep ListInput's own drag, or reuse core's reorder and change the API.
• Handle placement: before Remove, or after it.

Why this choice

Reusing core's reorder means one implementation, and ListInput gets the hold, the keyboard path and the announcements. The cost is the API change; Lab is private, so there's no changeset. The handle goes after Remove, where UIKit puts it. ListInput shrinks by 4,181 B gzip. The design record drops the removed reorderStyles.ts path and its "Implementation gap" paragraph, which this closes, for Cindy's review.

How to check it

In Storybook Lab/ListInput:

1. On a phone, hold a grip and drag the record down two places. A flick scrolls, and a pinch zooms.
2. Tab to a grip, press Enter, use the arrow keys, then press Escape.
3. Loading: the grips do nothing, and dragging scrolls the page.

I ran the unit tests and the Chromium browser tests, covering moves through onReorder, keyboard reorder mode, inert handles, and pinch-zoom on a handle. All pass. Two reds come from elsewhere: touch-support-bundle, which #8671 fixes, and pr-rtl, main's newer RTL test from 0472c4e.

Writing rubric results

For design:ordered-collection-reordering:

• R1: the deleted "Implementation gap" paragraph described Lab before this PR. Each of its three claims now holds through core's tests:
  • "marks a key move's new place with the insertion line until the mode ends";
  • "moves a record in reorder mode with the arrow keys, through the owner's onReorder";
  • "keeps the other rows still during a drag".
• R2, R4 and R5: none.
• R3: verified_by names a spec file.
• R6: OQ1 to OQ3 are unanswered.

Evidence

Before: the grip drags at once, and on iOS 26.2: after, hold, drag and drop, and loading: the grip is inert.

Stack (merge in this order): … → #8139 → #8337 → #8143 → this.

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
astryx	Ready	Preview	Nov 3, 2026 11:10pm UTC

AI review status for this pull request.

Review status	Updated
❓ Needs maintainer input (for maintainers only)	Nov 3, 2026, 11:26 PM UTC

PR Analysis Report

Current run: The current CI run concluded cancelled. Current analysis is unavailable.

View Storybook for this PR · View Sandbox for this PR

---

_{Generated by PR Enrichment workflow | View current CI run}

Approval waits on an engineering owner's decision on direction that no current spec covers: draft spec:AST-094 FR1–FR23 with DEC-1 and DEC-2, and the four ListInput decisions the description marks as pending owner review. An engineering owner records that decision by commenting /approve-spec <full head SHA> on this pull request, and the author may do so if they are an engineering owner. Whatever that decision is, these still need changes:

• Land or retarget the stack so this diff is only the ListInput change; it now carries 34,464 authored lines, most of them from eight other pull requests.
• Add the real-browser test that useListReorder.ts and ListReorder.test.tsx point to (ListReorder.interaction.browser.spec.ts), covering the slide, autoscroll, drop and pointer cancel.
• Remove the document touch listeners ListReorderHandle installs once no handle needs them, and fix AST-094's references to a spec:AST-090 that does not exist.

[Automated review]

This effect installs capture touchstart, touchend and touchcancel listeners on the document through countFingers (lines 106–118) and returns no cleanup, so they stay for the document's lifetime and one module-level fingersDown serves every document. architecture:react-component-runtime INV3 requires cleanup to release what setup installs; counting handles per document and removing the listeners with the last one would meet it.

List/__tests__/ListReorder.interaction.browser.spec.ts is not in this head, so the drag, slide, autoscroll, drop and pointer-cancel paths this comment hands to it have no real-browser test, which spec:AST-013 FR10 asks for. Add the spec, or point this comment (and the headers of ListReorder.test.tsx and ListInput.test.tsx) at evidence that exists.

There is no spec:AST-090 on main or at this head, so this proposed amendment, and the one in Current-state impact, has no record for its owners to rule on. Cite the record that states these exit rules, or drop the amendment.

This layout effect sets shown when the collapse springs finish. architecture:react-component-runtime INV3 asks a new effect to name the external system it synchronizes; a comment saying it waits for the collapse motion's finished promises would cover it.

Approval waits on an engineering owner's decision on direction no current spec covers: draft spec:AST-094 FR1–FR23 with DEC-1 and DEC-2, and the four ListInput decisions the description marks as pending owner review. An engineering owner records that decision by commenting /approve-spec <full head SHA> on this pull request, and the author may do so if they are an engineering owner. Whatever that decision is, these still need changes:

• Land or retarget the stack so this diff is only the ListInput change; it now carries 34,443 authored lines, most of them from other pull requests.
• Add the real-browser test that useListReorder.ts and ListReorder.test.tsx point to (ListReorder.interaction.browser.spec.ts), covering the slide, autoscroll, drop and cancel.
• Remove the document touch listeners ListReorderHandle installs once no handle needs them, and fix AST-094's references to a spec:AST-090 that does not exist.

[Automated review]

On the predecessor stack: this pull request is stacked, as its first line says, and only its last commit (79c4b3c, 5 files, +359 −1,392) is its own. It rebases onto main as each predecessor lands, and the diff then shrinks to that commit.

Approval waits on an engineering owner's decision on direction no current spec covers: draft spec:AST-094 FR1–FR23 with DEC-1 and DEC-2 (including whether FR4's untunable touch motion or the themable reorder.slide.spring stands) and the ListInput reorder decisions the description marks as pending owner review, now including the handle's moves menu. An engineering owner records that decision by commenting /approve-spec <full head SHA> on this pull request, and the author may do so as an engineering owner. Whatever that decision is, these still need changes:

• Land or retarget the stack so this diff is only the ListInput change; it now carries 48,303 authored lines, most of them from ten other open pull requests.
• The reorder handle announces itself as a menu button, but Enter and Space pick the record up and never open its moves menu; give that role its keyboard activation or drop aria-haspopup.
• Add a browser test for the moves menu's focus path and the drag autoscroll, and correct the theme template's platform axis, the stale sentence in the touch-motion-theme-roles changeset, and AST-094's references to a spec:AST-090 that does not exist.

[Automated review]

aria-haspopup="menu" and aria-expanded make this handle a menu button for assistive technology, but Enter and Space never open the menu: useListReorder.ts takes both for the pick-up and prevents their default (lines 1018–1029), so only a click reaches setMenu('mounting'). spec:AST-020 FR15 asks a part that plays an APG role for "activation by Tab plus Enter or Space". Letting Enter open the moves menu while Space keeps the pick-up, or dropping these two attributes, would resolve it.

This effect sets menu to 'open' on the next frame, and its comment does not name the external system it waits for (architecture:react-component-runtime INV3). Saying it waits a frame for the DropdownMenu's anchor to mount before it can move focus would cover that. The focus move into the menu and back to the handle is also browser-owned behavior with only a jsdom test (ListReorder.test.tsx: "jsdom never shows the popover"); spec:AST-013 FR10 asks for a real-browser proof of it.

Adaptation rules have no platform axis: defineTheme refuses when: {platform: 'ios'} (the head's own test "refuses a platform condition, which adaptations do not have" in expandMotionRoles.test.ts). A theme author following this template comment gets a thrown error; dropping the platform sentence fixes it.

"No shipped component reads the roles yet" no longer holds in this branch: List (useListUpdateMotion.ts), TreeList (useTreeExpansionMotion.ts), the selection hold and the reorder (ListReorderTouch.ts) all read motion roles, as the list-selection-hold and tree-list-expand-motion changesets say. Dropping the sentence keeps the release note accurate.

Approval waits on an engineering owner's decision on direction no current spec covers: draft spec:AST-094 FR1–FR23 with DEC-1 and DEC-2 (including whether FR4's untunable touch motion or the themable reorder.slide.spring stands) and the ListInput reorder decisions the description marks as pending owner review, including the handle's new look and drag for mouse users. An engineering owner records that decision by commenting /approve-spec <full head SHA> on this pull request, and the author may do so as an engineering owner. Whatever that decision is, these still need changes:

• Land or retarget the stack so this diff is only the ListInput change; it now carries 48,192 authored lines, most of them from nine other open pull requests.
• The reorder handle announces itself as a menu button, but Enter and Space pick the record up and never open its moves menu; give that role its keyboard activation or drop aria-haspopup.
• Add browser evidence for the moves menu's focus path, the drag autoscroll and the mouse drag after the change, and mark or drop the new @astryxdesign/core/motion/reducedMotion.stylex export.
• Correct the changesets that say no component uses the gesture and motion code yet, and AST-094's references to a spec:AST-090 that does not exist.

[Automated review]

aria-haspopup="menu" and aria-expanded make this handle a menu button, but Enter and Space never open the menu: useListReorder.ts takes both for the pick-up and prevents their default (lines 1018–1028), and a prevented Enter or Space keydown suppresses a button's click in Chromium, so only a pointer click reaches setMenu('mounting'). spec:AST-020 FR15 asks a part that plays an APG role for "activation by Tab plus Enter or Space". Letting Enter open the moves menu while Space keeps the pick-up, or dropping these two attributes, would resolve it.

This adds a public @astryxdesign/core/motion/reducedMotion.stylex subpath outside any /experimental boundary, and reducedMotion.stylex.ts carries no @experimental, so under spec:AST-017 FR21 its first release makes reducedMotionFadeConsts and reducedMotionKeys stable API; the touch-experimental-subpaths changeset also says no other subpath is added. Moving them under motion/experimental or keeping them internal would fix it.

"No shipped component reads the roles yet" does not hold in this branch: the reorder (ListReorderTouch.ts), useListUpdateMotion.ts, useTreeExpansionMotion.ts and the selection hold read motion roles. The [chore] notes for the gesture host, tap and long press, the animator, the motion math and the reorder values say the same about code List now runs. Dropping those sentences keeps the release notes accurate.

There is no spec:AST-090 on main or at this head, so this proposed amendment, and the one in Current-state impact, has no record for its owners to rule on. Cite the record that states these exit rules, or drop the amendment.

On main the claim that touch work leaves fine-pointer behavior alone is spec:AST-017 FR59; there is no FR55. The same citation appears in interactionOverlay.cell.test.ts and ListRowPressPaths.interaction.browser.spec.ts.

Approval waits on an engineering owner's decision on ListInput's new reorder handle: a 28 px three-line button after Remove that mouse and keyboard users also get, which no current spec decides and spec:AST-017 FR59 sends to its own owner decision. An engineering owner records that decision by commenting /approve-spec <full head SHA> on this pull request, and the author may do so as an engineering owner. Whatever the decision, these need changes:

• Reorder mode ends after the first move and announces the old position names, because each handle is named by its index (ListInput.tsx:1195, spec:AST-103 FR4).
• ListInput's list never applies the reorder session's list style, so no insertion line shows for a drag or a key move (ListInput.tsx:1024-1029).
• Each record gains two elements (FR5), the handle's code loads without reorderable (FR2), its name is concatenated (architecture:internationalization INV1a), and the docs describe behavior this head does not have.
• Land or retarget the stack: the diff carries 44,231 authored lines, almost all from other open pull requests.

[Automated review]

Naming the handle by its index ends reorder mode on every committed move: the new label re-runs the handle's registration, and its cleanup ends the mode (listReorderEngine.tsx:662-669); the move is also announced with the old names. spec:AST-103 FR4 keeps the mode until Escape, Done or the handle. Keep the handle registered when only its name changes, and build the name from a catalog message (@astryx.listInput.reorderItem is still in en.json) instead of concatenating it (architecture:internationalization INV1a).

This list never takes reorderScope.session.listStyle, the rule that draws the insertion line (core List applies it at List.tsx:371), so neither a drag nor a key move shows where the record will land (design:ordered-collection-reordering DR3 and DEC-1, spec:AST-103 FR4).

The cell <div> plus the handle adds two elements to each record, and a record isReorderable rejects keeps an empty cell; spec:AST-103 FR5 allows one added element, the handle.

Importing ListReorderHandle statically puts reorder code in every ListInput bundle, with or without reorderable (spec:AST-103 FR2). Core List renders reorder.session.Handle from the object instead (ListItem.tsx:444).

The records a drag passes no longer slide aside: the engine keeps them still with a preview and an insertion line, as the current reordering design's DEC-1 requires. The anatomy entry also claims a 44 px target, Home and End, and a Space/Escape pick-up, the dense guidance promises one onChange per move, and the anatomy omits the reorder hint that spec:AST-103 FR4 requires.

Approval waits on an engineering owner deciding, or identifying the governing spec for, ListInput's new reorder handle: a 28 px three-line button after Remove that mouse and keyboard users also get, which no current spec decides and spec:AST-017 FR59 sends to its own owner decision. An engineering owner records that decision by commenting /approve-spec <full head SHA> on this pull request, and the author may do so as an engineering owner. Whatever the decision, these need changes:

• Reorder mode ends after the first move and announces the old position names, because each handle is named by its index (ListInput.tsx:1195, spec:AST-103 FR4).
• ListInput's list never applies the reorder session's list style, so no insertion line shows for a drag or a key move (ListInput.tsx:1024-1029).
• Each record gains two elements (FR5), the handle's code loads without reorderable (FR2), its name is concatenated (architecture:internationalization INV1a), and the docs and the design record's deleted gap note describe behavior this head does not have.
• Land or retarget the stack: the diff carries 44,560 authored lines, almost all from other open pull requests.

[Automated review]

Naming the handle by its index ends reorder mode on every committed move: the new label re-runs ListReorderHandle's registration effect, and its cleanup ends the mode (listReorderEngine.tsx:662-668); the move is also announced with the names from before it. spec:AST-103 FR4 keeps the mode until Escape, Done or the handle, so that the data, the screen and the announcement agree. The name is also assembled here rather than from the catalog (architecture:internationalization INV1a).

This list never takes reorderScope.session.listStyle, the rule that draws the insertion line (core List applies it at List.tsx:371), so neither a drag nor a key move shows where the record will land (design:ordered-collection-reordering DR3, DR7 and DEC-1; spec:AST-103 FR4).

This cell plus the handle inside it adds two elements to each record, and a record isReorderable rejects keeps the empty cell; spec:AST-103 FR5 allows one added element, the handle.

Importing the handle and scope statically puts reorder code in every ListInput bundle, with or without reorderable (spec:AST-103 FR2: a collection imports none of it until the object is passed).

At this head the handle is 28 × 28 px for a mouse, not “at least 44 by 44 px”; Home and End are not handled, and Space and Escape toggle and end reorder mode, keeping the moves. The anatomy also needs the reorder-hint part spec:AST-103 FR4 asks each adopting collection to name, and lines 98 and 613 still describe records sliding aside.

The DR7 part of this note still holds for ListInput at this head: its list draws no insertion line in keyboard reorder mode. Keeping that sentence until the line is drawn keeps the record accurate.

Posted by Cindy's agent on her behalf: closed and reopened only to restart this PR's CI on the current workflow after tonight's queue-wide cancel; nothing in the PR changed.

Thanks, and sorry for the late reply. ListInput now takes the createReorderable(...) object, keyed by getItemKey, and drives core's reorder through @astryxdesign/core/internal/reorder, as you decided. Its reorder already takes the public createReorderable object.

Approval of this pull request waits on an engineering owner's decision, and the findings below need changes whatever that decision is.

Owner decision needed. No current record decides two directions this pull request ships: ListInput's 28 × 28 px three-line handle after Remove, shown to mouse and keyboard users in place of the six-dot gutter grip (spec:AST-017 FR59 requires its own owner decision for a new fine-pointer look made in touch work), and Core List's new public hasAnimatedChanges prop, which no record vets and which overlaps spec:AST-105's animatedLayout. An engineering owner records the decision by commenting /approve-spec <full head SHA> on this pull request; the author may do so as an engineering owner.

Required changes:

• Reorder mode ends after the first arrow or Move button, because the handle's position-based name (ListInput.tsx:1195) re-runs its registration, and the move is announced with the names from before it, against spec:AST-103 FR4.
• ListInput's list never takes the session's insertion-line style (ListInput.tsx:1024-1029), so neither a drag nor reorder mode shows where a record lands, against design:ordered-collection-reordering DR3 and DR7 and spec:AST-103 FR4.
• Each record gains a grid cell plus the handle (ListInput.tsx:1181-1201, spec:AST-103 FR5), the handle and scope are imported statically (ListInput.tsx:41-45, FR2), and the handle's name is concatenated at the call site instead of using the catalog's @astryx.listInput.reorderItem (architecture:internationalization INV1a).
• ListInput.doc.mjs (lines 98, 221, 613, 637) describes sliding rows, a 44 px target, Home and End and one onChange per move, its anatomy omits the reorder hint, and the design record edit and the description call the insertion-line gap closed while ListInput still draws no line.
• ListReorderScope repeats List's session creation, after-commit commit() and Host (List.tsx:288-299), so the two reorder paths can drift; let List call the same hook.
• The diff carries 44,560 authored lines across 242 files, 229 of them from other open pull requests; land or retarget the stack so this diff is the ListInput adoption.

Please add a test that makes two moves in one reorder mode and a browser check for the insertion line.

[Automated review]

This name changes with the record's index, and ListReorderHandle's registration effect depends on it, so the committed move re-runs the registration and its cleanup ends reorder mode (listReorderEngine.tsx:667). In Chromium, after Enter and one Arrow Down, aria-pressed is false and a second Arrow Down moves nothing; the move is also announced with the old names ("tag 1, position 2 of 4, after tag 2, before tag 3"). spec:AST-103 FR4 keeps the mode until Escape, Done or the handle. A catalog-built name (@astryx.listInput.reorderItem) would also meet INV1a.

The list takes only styles.list, so the engine's data-astryx-reorder-line has no ::after rule to draw: core List applies reorderSession?.listStyle (List.tsx:371). Apply reorderScope?.session.listStyle here (or in ListReorderScope) so drags and reorder mode show the insertion line (design DR3, DR7; AST-103 FR4).

Each record gets this cell <div> plus the handle, and a rejected record keeps the empty cell: two added elements per row against spec:AST-103 FR5 ("at most one element to a row"). Let the handle carry the grid placement and render nothing for a rejected record.

A static import ships the handle, its styles and its hit-area watcher in every ListInput, with or without reorderable; spec:AST-103 FR2 says a collection imports none of it until the object is passed. Rendering reorderScope.session.Handle (as List does) keeps it with the object.

At this head the handle is 28 px (a 44 px hit layer only under a coarse pointer), the engine takes only Arrow Up, Arrow Down and Escape (no Home or End), and Space toggles reorder mode while Escape ends it keeping the moves. Lines 98 and 613 also describe rows sliding aside, which the engine does not do (design DEC-1).

This repeats List's session creation and after-commit commit() (List.tsx:288-299), kept in step only by the SYNC note. List can call useListReorderScope after useListUpdateMotion (hook order keeps the effect order) and render the same Host, so both collections make one call.

The DR7 part of this note still holds for ListInput: its list draws no insertion line at this head (ListInput.tsx:1024-1029). Keep that sentence until the line is drawn; the DR3 and preview parts are now closed for ListInput.