Repository navigation
Conversation
…ion-group tracker The track-across-items loop useMenuPress owns is the same job as core's internal action-group tracker. The record now says the loop moves into the tracker in the change after the in-flight menu press work, that useMenuPress then keeps only its menu-only parts, and that no third copy is added meanwhile.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
AI review status for this pull request.
|
github-actions
Bot
added
the
needs:spec-owner-review
PR Analysis Report
The exact-head preview is not available yet. Generated by PR Enrichment workflow | View current CI run |
meta-cla
Bot
added
the
CLA Signed
![astracat-bot[bot]](https://avatars.githubusercontent.com/in/4796231?s=60&v=4){kind=small}
There was a problem hiding this comment.
Approval waits on an engineering owner deciding whether useMenuPress's track-across-items loop should move into core's internal action-group tracker, with no third copy meanwhile: no current record establishes that direction, and an engineering owner (the author may, as one) records the decision by commenting /approve-spec <full head SHA> on the head they approve. If the direction is approved, the paragraph still needs these changes, so approving the reworked head avoids a second approval:
- It narrates a planned change ("recorded 2026-10-26", "the change after the in-flight menu press work", "once it lands"), which
architecture:knowledge-contractsINV10 keeps out of current records, so state only durable facts there and keep the plan in the pull request. - It names the internal
hooks/actionGroupTracker.ts, which is not onmain, while INV18 places internal seams in an architecture record rather than a module contract. - The description needs the
## Writing rubric resultssection that knowledge-contracts asks of every pull request that changes a record.
[Automated review]
| **Planned convergence (recorded 2026-10-26).** The track-across-items loop | ||
| above (document-level pointer tracking, the highlight under the pointer, the | ||
| row under the release acting, the stray click swallowed) is the same job as | ||
| core's internal action-group tracker (`hooks/actionGroupTracker.ts`), which | ||
| control groups such as a segmented control's segments track through once it | ||
| lands. The change after the in-flight menu press work moves that loop into the | ||
| action-group tracker; this module then keeps only its menu-only parts: opening | ||
| from a trigger press or a held finger, the settle rule, edge autoscroll, and | ||
| the highlight as DOM focus. Until then both exist, and no third copy is added. |
There was a problem hiding this comment.
This paragraph describes a pending change: it is dated, speaks of "the change after the in-flight menu press work", and relies on a tracker in use "once it lands". architecture:knowledge-contracts INV10 asks a current record to state durable facts independently of any one change, so consider keeping the plan in the pull request or an issue and rewriting the Owns list in the change that moves the loop.
| **Planned convergence (recorded 2026-10-26).** The track-across-items loop | ||
| above (document-level pointer tracking, the highlight under the pointer, the | ||
| row under the release acting, the stray click swallowed) is the same job as | ||
| core's internal action-group tracker (`hooks/actionGroupTracker.ts`), which |
There was a problem hiding this comment.
hooks/actionGroupTracker.ts is not on main (only #8127 adds it), and INV18 keeps internal files and seams out of module contracts, so please drop the file name here.
…ithout an internal file name The ownership boundary now says, as a durable fact, that tracking a held finger across a control group's targets outside a menu or picker is core's internal group tracker's, that its loop is the same job as this module's tracking, and that no third copy is added (knowledge-contracts INV10, INV18).
cixzhang
changed the title
There was a problem hiding this comment.
Approval waits on an engineering owner providing the governing spec for this addition, which no current spec establishes: whether useMenuPress's non-goals should assign held-finger tracking across control groups outside menus and pickers to core's internal group tracker, with no third copy of that loop, a decision an engineering owner (the author may, as one) records by commenting /approve-spec <full head SHA> on the head they approve. If the direction is approved, the bullet still needs two changes, so approving the reworked head avoids a second approval:
- The tracker it names is not on
main(only #8127 adds it, and nothing tracks page-control dots), so the current record would point readers at an owner that does not exist yet; land the bullet with or after the tracker. - An internal owner and a one-loop rule belong in an architecture record under
architecture:knowledge-contractsINV18, asarchitecture:interaction-modalityINV10 does for the velocity tracker, with this module keeping only the caller-visible boundary.
[Automated review]
| - Tracking a held finger across a control group's targets outside a menu or | ||
| picker, such as a segmented control's segments or a page control's dots — | ||
| owned by core's internal group tracker. Its loop is the same job as this | ||
| module's tracking (the highlight under the pointer, the target under the | ||
| release acting, the stray click swallowed), so no third copy is added. |
There was a problem hiding this comment.
This names core's internal group tracker as the owner, but no such tracker is on main or at this head: only #8127 adds one, and nothing tracks page-control dots, so a current record would point readers at an owner that does not exist yet (architecture:knowledge-contracts INV10). The no-third-copy rule is also internal ownership, which INV18 places in an architecture record, as architecture:interaction-modality INV10 does for the velocity tracker. Consider landing this with the tracker, moving the rule to that record, and keeping only the caller-visible non-goal here.
Maintainer impact
Core has two trackers of a held finger moving across a group of targets:
useMenuPress, which runs menus and pickers, and an internal group tracker that control groups such as SegmentedControl's segments use. Their core loop is the same job: highlight the target under the pointer, act on the target under the release, and swallow the browser's stray click. The record now says where that boundary sits, so no third copy appears. The convergence of the two is separate, later work.Change
module:DropdownMenu/useMenuPress's ownership boundary gains one "Does not own" item: tracking a held finger across a control group's targets outside a menu or picker (a segmented control's segments, a page control's dots) is core's internal group tracker's. Its loop is the same job as this module's tracking, so no third copy is added.There is no behavior, API or code change, and the module's Owns list is unchanged.
Writing rubric results
Testing
pnpm check:knowledge: records aligned.