perf(Root,Portal,Overlay): batch stylesheet writes into one invalidation per commit

[tenphi]

Adopts tasty 3.2.0's batched style injection across the kit.

Why

Every insertRule() on a live stylesheet invalidates style for that sheet's scope. Kit components inject during React's render phase, so when anything else reads layout in the same pass — a tooltip positioning itself, TextArea autosizing, a virtualized table measuring rows — the two interleave and the browser is forced to recalculate style between every injection. A Chrome trace of a production app showed 16 forced recalcs totalling 62 ms sandwiched between insertRule calls, including one 475 ms task with 52 injections and 17 recalcs.

What changed

configure({ batchInjection: true }) in Root.tsx, plus a batch window at each portal boundary. Windows have to be per-boundary: a commit that mounts a portal never re-renders <Root>, so Root's window cannot cover it.

Window	Covers
<Root>	App mount, and any Root re-render
<Portal>	Tooltips — TooltipTrigger is its only consumer among the components
<Overlay>	Popovers, modals, trays — i.e. Dialog and Menu surfaces

Deliberately not covered: Board's WidgetHost drag clone, LayoutPanel, and use-context-menu's 0×0 anchor. The first two measure only from event handlers, which sit outside any window in true mode and so are written straight through; LayoutPanel never measures geometry at all. A window there would buy nothing but an extra effect per portal.

No API change — no new props, no new setup for consumers.

Why this is safe

The flush happens in useInsertionEffect, which React runs in the mutation phase, before any useLayoutEffect:

provider renders          -> window OPEN
  children render         -> injections queued
provider insertionEffect  -> FLUSH, window CLOSED
layout effects run        -> rules are in the sheet

Any commit with no window in it writes straight through, exactly as before. Turning this on can make injection cheaper; it cannot make a measurement wrong. SSR is unaffected — styles are collected as text there and the provider is inert without a document.

Verification

• pnpm test — 97 files, 2093 pass (1 pre-existing skip). Every test using renderWithRoot now runs inside a batch window, so the existing suite doubles as the regression test.
• pnpm test:browser — 11 files, 129 pass, including the measure-heavy suites this targets: TextArea autosize, DialogTrigger, MenuTrigger, Tabs, Board, DataTable.
• Chromatic UI Tests + UI Review pass — no visual diffs, which matters because <Overlay> wraps every popover, modal and tray.
• pnpm lint clean, pnpm build succeeds, size +0.15% overall / +0.6% tree-shaken, both within limits.

Root.browser.test.tsx asserts on the write queue itself (hasPendingStyleWrites() mid-render), so the wiring cannot silently degrade into a no-op — the flag staying on while a provider goes missing would otherwise be invisible. Each test was verified to fail with its window removed.

Review history worth knowing

Two bugs were found and fixed here, both by testing claims rather than reading code:

1. Cursor Bugbot caught that this PR's original central claim was wrong. Popover/Modal/Tray portal through Overlay's raw createPortal, not <Portal>, so DialogTrigger and MenuTrigger — the surfaces named as benefiting most — had no window at all. Fixed by adding the <Overlay> window. The test that now covers it drives a real DialogTrigger; the original <Portal> test passed whether or not the overlay path was covered, so it validated the mechanism while leaving the claim untested.
2. A StrictMode window leak in tasty itself, found while reviewing that PR: a depth counter ended each StrictMode commit above zero, silently giving the next provider-less commit 'always' semantics and letting its layout effect measure an unstyled box. Fixed upstream before 3.2.0 shipped; the StrictMode test here is the integration-level proof, and it fails against the pre-fix snapshot.

🤖 Generated with Claude Code

[changeset-bot]

🦋 Changeset detected

Latest commit: 57c5710

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@cube-dev/ui-kit	Minor

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[vercel]

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

Project	Deployment	Actions	Updated (UTC)
cube-ui-kit	Ready	Preview	Aug 21, 2026 6:11pm

[github-actions]

📦 NPM canary release

Deployed canary version 0.0.0-canary-3fca3d8.

[github-actions]

🧪 Storybook is successfully deployed!

• 👀 Review changes: https://www.chromatic.com/build?appId=626ee6db91d1c8004a912249&number=3951
• 👨‍🎨 Preview storybook: https://626ee6db91d1c8004a912249-ihavfhnrwx.chromatic.com/

[github-actions]

🏋️ Size limit report

Name	Size	Passed?
All	498.7 KB (+0.15% 🔺)	Yes 🎉
Tree shaking (just a Button)	121.84 KB (+0.6% 🔺)	Yes 🎉

Compared against main at 4afd730 — run 32492162650, 2026-08-21T14:26:38Z.

To see which modules changed, download the size-limit-statoscope-report artifact from this run and open report.html.

[cursor]

Cursor Bugbot has reviewed your changes using default effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 2eb6c28. Configure here.}

[tenphi]

@cursor Good catch, and it invalidated this PR's central claim rather than a detail of it — fixed in 37deb99.

You were right: Popover, Modal and Tray portal through Overlay's own createPortal, so DialogTrigger and MenuTrigger — the surfaces I named as benefiting most — got no batch window at all. Checking the rest of the portal surface, <Portal> turns out to cover tooltips only: TooltipTrigger is its single consumer among the components. So the placement I shipped covered the one overlay family I hadn't argued for and missed the one I had.

What changed:

• <Overlay> now opens a window of its own, so popovers, modals and trays are covered.
• A new test drives a real DialogTrigger and asserts writes were queued during the commit that mounts it. It fails without the Overlay window — which the existing <Portal> test could never do, since that one passes whether or not the overlay path is covered. It validated the mechanism while leaving the claim untested.
• The comments and changeset now name which surfaces each of the three windows covers, instead of implying blanket coverage.

Deliberately still uncovered, and now documented as such: Board's WidgetHost drag clone, LayoutPanel, and use-context-menu's 0×0 anchor. None of them position themselves off a same-commit measurement, so a window buys them nothing but an extra effect. The general constraint is that windows must be opened per portal boundary, because a commit that mounts a portal never re-renders <Root> — worth keeping in mind for future portal sites.

[cursor]

No changes needed — the fix you describe is already committed and pushed as HEAD (37deb99d), and the working tree is clean.

I verified the three batch windows are in place and that each one's comment names its scope:

• Root.tsx wraps the tree in <TastyBatchProvider>, and the configure() comment states windows must be opened per portal boundary since a portal-mounting commit doesn't re-render <Root>.
• Portal.tsx notes it covers tooltips only, since TooltipTrigger is its sole consumer.
• Overlay.tsx opens a window around its raw createPortal, covering popovers, modals, and trays — with a comment explicitly flagging that this is a raw createPortal and not <Portal>, so the <Portal> window doesn't reach it.

Your point about the <Portal> test being unable to catch this is the important one: a test that passes regardless of whether the overlay path is covered validates the mechanism but not the claim, so the DialogTrigger test that fails without the Overlay window is what makes the coverage load-bearing.