Repository navigation
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
meta-cla
Bot
added
the
CLA Signed
|
AI review status for this pull request.
|
PR Analysis Report📚 Storybook Preview🧪 Sandbox PreviewNew ComponentsSearchField (@astryxdesign/lab) · View in Storybook
Component Size
Sizes are gzip. Import counts the JavaScript the import loads eagerly; CSS counts the package stylesheet rules referenced by the modules it can load from its own package, lazily loaded ones included. Bundle Size SummaryGzip figures measure each package's entry file, not the code an import pulls in.
Accessibility AuditStatus: No accessibility violations detected. Visual Regression55 of 502 shot(s) changed. A change here is a question, not a failure: check whether the after is the
and 35 more. Generated by PR Enrichment workflow | Storybook | Sandbox | View full report |
![astracat-bot[bot]](https://avatars.githubusercontent.com/in/4796231?s=60&v=4){kind=small}
There was a problem hiding this comment.
This needs an owner decision before it can be approved: every change here rests on the draft AST-094 touch-presentations spec, whose two decisions (UIKit as the reference for touch, and recognizers with compositor-played releases) are still pending, and which proposes touch amendments to the current pressed-overlay rule (user-states DR1) and to scroll chaining (AST-025 FR14). An engineering owner records that decision by commenting /approve-spec followed by the full head SHA on this pull request; the author may do so if they are an engineering owner. Two changes are needed whichever way that goes:
- Land the predecessor PRs first, or retarget this one onto #8243's branch, so this diff is the 306-line Cancel-button commit rather than the 39,586-line stack.
- After a cancel the bar re-expands while the release wobble plays, so the visible Cancel circle settles at the bar's 62 px instead of the measured 48 px; the new test reads only the wrapper's scale.
[Automated review]
|
|
||
| // The cancel button's press: it grows to `searchCancelPressedSize` under | ||
| // the finger and shrinks back with UIKit's wobble on release. | ||
| const pressCancel = (isPressed: boolean) => { |
There was a problem hiding this comment.
Cancelling also returns the bar to the previous tab, so useTabBarMinimize.ts:271–275 springs the search glass from 48⁄62 back to full size on collapseSize while this wrapper plays searchCancelReturn. What a person sees is the product of the two: about 63.65 → 52 → 63 → 62 px, not the measured 63.65 → 43.6 → 49.2 → 48. The new proof samples only this wrapper's scaleX, so it cannot catch this. Holding the glass's expansion until the return settles, or asserting the glass's composed size against the iOS data, would close it.
c37afd9 to
83f8078
Compare
github-actions
Bot
added
the
needs:design-review
There was a problem hiding this comment.
This needs an engineering owner's decision before it can be approved: the cancel button's press and most of the stack beneath it have no governing spec on main, so an engineering owner must provide or identify one, either accepting spec:AST-094 (proposed in #8378) or naming another record, and records that decision by commenting /approve-spec followed by the full head SHA on this pull request; the author may do so as an engineering owner. Two changes are needed either way:
- Land the predecessor PRs first, or retarget onto #8243's branch, so this diff is the 160-line cancel-button commit rather than a 50,114-line stack.
- When Cancel ends search, the bar's glass re-expands while the release wobble plays, so the visible circle dips only to 52.3 px and settles at 62 px instead of the measured 43.6 → 48 px, and the new proof samples the button's box rather than the painted glass.
[Automated review]
83f8078 to
39970f4
Compare
|
Both changes from the last review are in 39970f4.
On the stack: each PR carries its own commit, and this one is the 160-line cancel-button commit on top of #8243. The predecessors are its stack, not its content; the whole stack now sits on the gesture line's current head. |
There was a problem hiding this comment.
This needs an engineering owner's decision before it can be approved: spec:AST-094 now governs the touch mechanics, but it leaves each component's touch presentation and any new motion roles to that component's own record, and no TabBar record covers the Cancel press or its new tabBar.searchCancelPress and tabBar.searchCancelReturn theme roles. An engineering owner can approve them, or name the record that must come first, by commenting /approve-spec followed by the full head SHA on this pull request; the author may do so as an engineering owner. Whatever is decided, three changes are needed:
- Land the predecessor pull requests first, so this diff is the 209-line Cancel commit rather than a 51,420-line stack.
- Describe the two new theme roles in
.changeset/uikit-tab-bar-search-cancel-press.mdas theme-settable rather than internal. - Limit
.changeset/touch-selection-lock.mdto what ships, since no Slider, Switch or SegmentedControl takes the selection lock in this diff.
[Automated review]
| '@astryxdesign/core': patch | ||
| --- | ||
|
|
||
| [chore] Internal: the UIKit constants table's `tabBar` gains the measured values of the iOS 26 tab bar's search cancel button: its pressed size and the springs it grows and shrinks back on. Not exported from the package entry point; the lab TabBar imports it by name. |
There was a problem hiding this comment.
This calls the change internal, but tabBar.searchCancelPress and tabBar.searchCancelReturn become role ids that defineTheme accepts (roleKinds.generated.ts:63–64) and that astryx docs motion lists. .changeset/uikit-search-table.md ships its role additions as [feat]; describing these two as theme-settable roles in the same category would tell theme authors they exist.
| '@astryxdesign/core': patch | ||
| --- | ||
|
|
||
| [fix] Under a finger or pen, holding a control whose hold does something (a slider's thumb, a switch's or a segmented control's drag) no longer starts text selection or the iOS callout; they come back when the finger lifts. A control or row whose hold does nothing keeps the browser's long-press selection. Text fields keep their selection, a link keeps its native menu and preview, and where the primary pointer is fine (a mouse, a trackpad, a touchscreen laptop, a desktop pen tablet) every contact keeps desktop selection. There, the press controller also registers no touch listener. |
There was a problem hiding this comment.
At this head only the gesture host takes the selection lock, and no released Slider, Switch or SegmentedControl uses it (none of their files changes), so this [fix] promises behaviour the release would not ship. Limiting the note to the press controller's touch listener, and carrying the selection claim with the change that moves those controls onto the gesture host, would keep the changelog accurate.
39970f4 to
7a63201
Compare
There was a problem hiding this comment.
This needs an engineering owner's decision before it can be approved: spec:AST-094 governs the touch mechanics, but it leaves each component's touch presentation and any new motion roles to that component's own record, and no TabBar record covers the Cancel press or its new tabBar.searchCancelPress and tabBar.searchCancelReturn theme roles. An engineering owner can approve them, or name the record that must come first, by commenting /approve-spec followed by the full head SHA on this pull request; the author may do so as an engineering owner. Whatever is decided, these changes are needed:
- Rebase onto
mainand land the remaining predecessor pull requests, so this diff is the 209-line Cancel commit rather than a 51,430-line stack that now conflicts withmain. - Describe the two new theme roles in
.changeset/uikit-tab-bar-search-cancel-press.mdas a[feat]rather than internal, and limit.changeset/touch-selection-lock.mdto what ships, since no Slider, Switch or SegmentedControl takes the selection lock in this diff. - Return the circle's scale when search ends while Cancel is still pressed, so the circle cannot stay enlarged.
[Automated review]
| }, []); | ||
| const pressTargetRef = useRef<HTMLElement | null>(null); | ||
| useLayoutEffect(() => { | ||
| pressTargetRef.current = isCancel ? cancelElementRef.current : null; |
There was a problem hiding this comment.
If search ends while a finger is still on Cancel, this clears the target and useAttachment disposes the tracker without calling onHighlightChange(false) (usePressTracker.ts:82–85, :137–144). Nothing else animates the circle's scale, so it stays at 63.65⁄48 of its size, about 82 px once the bar expands. Playing the return here when isCancel turns false while the press is still highlighted would close it.
…rt times The expand's first frame is checked against the expand spring started from the offset the accessory turns from, with the speed the collapse had at the turn. The turn's moment is the two animations' start times apart, so a late tap (a loaded box) moves the prediction with it instead of failing the case.
There was a problem hiding this comment.
This needs an engineering owner's decision before it can be approved: spec:AST-094 governs the touch mechanics but leaves each component's touch presentation and its springs to that component's own record, and no TabBar record covers the Cancel press. An engineering owner can provide or identify that record, or approve the press as it stands, by commenting /approve-spec followed by the full head SHA on this pull request, and the author may do so as an engineering owner. Whatever is decided, these changes are needed:
- Land the predecessor pull requests first, or retarget onto #8243's branch, so this diff is the 253-line Cancel layer rather than about 44,900 changed lines.
- Make the gesture host attach for every pointer, as
spec:AST-094FR19 and FR43 andarchitecture:react-component-runtimeINV13 now require, instead of installing nothing under a fine pointer. - Back the claim that Cancel answers the finger in iOS Safari with a recording on a real iPhone.
[Automated review]
| * ONLY WHERE THE PRIMARY POINTER IS COARSE | ||
| * | ||
| * - Recognizers attach, and the host registers listeners, only while the | ||
| * primary pointer is coarse (`spec:AST-094` FR19, FR24; coarsePointer.ts). | ||
| * Where it is fine, an attach is recorded but nothing is installed: no | ||
| * document, window or element listener, no `touch-action` or other style, | ||
| * nothing delivered, so a finger on a touchscreen laptop gets the | ||
| * browser's defaults. The host follows the query: turning coarse installs | ||
| * it and styles every registration; turning fine cancels every touch in | ||
| * flight and removes it all. A development warning names the first attach | ||
| * under a fine pointer. | ||
| * - The one carve-out is `perEventPointer` (AttachOptions). A per-event | ||
| * recognizer gets its listeners and its element's style on any pointer. A | ||
| * per-event press tracker, where the pointer is fine, gets only passive | ||
| * `touchstart` and `pointerdown` listeners on its own element and no | ||
| * style; the host's document and window listeners are added at a finger's | ||
| * press on it and removed once that press's contacts end. |
There was a problem hiding this comment.
This keeps the host inactive under a fine pointer, but current spec:AST-094 FR19 says "Recognizers attach for every pointer, with FR43's exceptions", FR43 says "Gestures attach for every pointer, a mouse, a pen, and a finger, not only a coarse primary pointer", and architecture:react-component-runtime INV13 says "The gesture host attaches for every pointer, with no touch-only query". Attaching for every pointer with FR43's exceptions, and listening only on the component's own element under a fine pointer (FR24), would also retire perEventPointer's carve-out and the FR19 warning at lines 1353–1362.
…arch field covers it Under a finger the active field spans the bar's row over the leading circle, which kept its tab stop and its name. It is inert while the field is active there, with a browser test (red first: the covered circle took focus).
The Effect that ends a press when the recognizer turns off, and the one that ends it when the tab list changes under a finger, now say what they synchronize, as the selection Effect does.
While the bar is collapsed its tabs are inert, so focus never lands on a tab: keyboard focus reaches the circle, whose activation expands the bar. The prop doc, the component doc and the hook said focus on a tab expands it.
…tree (AST-085 FR5) Reads Chromium's accessibility tree: the disabled tab keeps its name and is announced disabled on the tab itself; no other tab is.
The component doc said the search circle becomes the cancel button; the circle stays a tab, out of reach while the field is active, and a separate Cancel button lies over it.
There was a problem hiding this comment.
This needs an engineering owner's decision before it can be approved: spec:AST-094 governs the touch mechanics but leaves each component's touch presentation and its springs to that component's own record, and no TabBar record covers the Cancel press. An engineering owner can provide or identify that record, or approve the press as it stands, by commenting /approve-spec followed by the full head SHA on this pull request, and the author may do so as an engineering owner. Whatever is decided, these changes are needed:
- Land the predecessor pull requests first, or retarget onto #8243's branch, so this diff is the 253-line Cancel layer rather than about 44,900 changed lines.
- Make the gesture host attach for every pointer, as
spec:AST-094FR19 and FR43 andarchitecture:react-component-runtimeINV13 require, instead of installing nothing under a fine pointer. - Back the claim that Cancel answers the finger in iOS Safari with a recording on a real iPhone.
- Move the unit test that leaves search from the leading circle with the keys (
TabBar.test.tsx) to the inline-field state, since the active field now makes that circle inert and jsdom ignoresinert.
[Automated review]
| ); | ||
| }); | ||
|
|
||
| it('leaving search from the circle with the keys moves focus on to the tab it returns to', () => { |
There was a problem hiding this comment.
This activates the field under a coarse pointer (the default automaticallyActivates), then focuses and activates the leading circle. In that state the circle is now inert (TabBar.tsx:1622), and the new browser test shows a focus call on it fails (TabBar.interaction.browser.spec.ts:2751–2756); jsdom ignores inert, so this test keeps asserting a keyboard path nobody can take. Rendering it with automaticallyActivates={false} keeps the field inline and the circle reachable, and an inert assertion while the field is active would cover the new state; the click at line 707 drives the same covered circle.
There was a problem hiding this comment.
This needs an engineering owner's decision before it can be approved: spec:AST-094 governs the touch mechanics but leaves each component's touch presentation and its springs to that component's own record, and no TabBar record covers the Cancel press. An engineering owner can provide or identify that record, or approve the press as it stands, by commenting /approve-spec followed by the full head SHA on this pull request, and the author may do so as an engineering owner. Whatever is decided, these changes are needed:
- Land the predecessor pull requests first, or retarget onto #8243's branch, so this diff is the 253-line Cancel layer rather than about 45,000 changed lines.
- Make the gesture host attach for every pointer, as
spec:AST-094FR19 and FR43 andarchitecture:react-component-runtimeINV13 require, instead of installing nothing under a fine pointer. - Back the claim that Cancel answers the finger in iOS Safari with a recording on a real iPhone.
- Move the unit test that leaves search from the leading circle with the keys (
TabBar.test.tsx) to the inline-field state, since the active field makes that circle inert and jsdom ignoresinert.
[Automated review]
Depends on #8243.
Review only this PR's change: vjeux/astryx@c79ed7f...f85f937
User need
Part of matching Astryx's touch components to iOS 26, so apps built with it feel native on phones. On iOS the search Cancel button answers the finger: it grows while pressed and wobbles back on release. In #8243 it gives no feedback until the tap ends search, so a press feels missed. This adds the press, measured on iOS 26.2.
Problem and solution fit
Current specification
spec:AST-094FR13, FR11 (Cancel follows the control profile: it highlights on touch-down and the browser's click activates it), FR8.Public delta and caller burden
None.
uikit.tabBargains Cancel's pressed size and springs;internal/touchgainsusePressTracker.Size, gzip against #8243's head: TabBar's import 67.9 → 69.7 KB JavaScript, 1,980 → 1,980 B CSS.
Design and alternatives
:active(main thread, no measured spring); a wrapper around the glass (one element per role).Evidence
iOS 26.2 simulator: a 0.5 s hold on Cancel, before (#8243: no response) and after, with close-ups; then Android 15 Chrome.
Scope
Stack: #8076 → … → #8320 → #8129 → … → #8222 → #8243 → this PR (with #8224 merged into #8243).
Testing
Try it:
pnpm storybook, Lab › TabBar › Search Tab, on a phone.Browser tests: a held finger grows the painted circle to UIKit's size; the lift wobbles it back, never below the measured 43.6 px, before the bar expands; under Reduce Motion it keeps its size. They run in Chromium only, since Playwright's WebKit turns a held finger into a long press with no click.
Passing:
pnpm test:interaction TabBar,pnpm vitest run packages/lab/src/TabBar packages/lab/src/SearchField,pnpm typecheck, lint.