CORE-2710: Compose render-callback style in react-aria-components wrappers - #137
Open
OpenStaxClaude wants to merge 1 commit into
Open
CORE-2710: Compose render-callback style in react-aria-components wrappers#137OpenStaxClaude wants to merge 1 commit into
OpenStaxClaude wants to merge 1 commit into
Conversation
Contributor
There was a problem hiding this comment.
Pull request overview
Fixes render-callback style handling in React Aria component wrappers while preserving caller override precedence.
Changes:
- Composes callback and object styles for three wrappers.
- Adds regression and override-precedence tests.
- Corrects Jira secret references and documents the fix.
Reviewed changes
Copilot reviewed 6 out of 6 changed files in this pull request and generated no comments.
Show a summary per file
| File | Description |
|---|---|
src/components/Tree/TreeCheckbox.tsx |
Composes checkbox styles safely. |
src/components/Tree/TreeCheckbox.spec.tsx |
Tests callback and object styles. |
src/components/NavBarMenuButtons.tsx |
Composes menu item and popover styles. |
src/components/NavBarMenuButtons.spec.tsx |
Adds style regression tests. |
CHANGELOG.md |
Documents the corrected behavior. |
.github/workflows/checks.yml |
Corrects Jira secret names. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
RoyEJohnson
force-pushed
the
CORE-2710-compose-render-props-style
branch
from
August 27, 2026 19:46
a35fb0f to
61e5db8
Compare
RoyEJohnson
marked this pull request as ready for review
August 27, 2026 19:51
OpenStaxClaude
added a commit
that referenced
this pull request
Aug 31, 2026
Addresses review: the four wrappers that bind CSS custom properties merged the caller's style with an object spread. react-aria-components types style as `CSSProperties | ((renderProps) => CSSProperties)`, and spreading a function copies nothing, so a render-callback style was silently dropped and replaced by the wrapper's static object. ProfileMenuButton, ProfileMenuItem, HelpMenuButton and HelpMenuItem now build their variables inside a composeRenderProps callback, the same fix applied to NavBarMenuItem/NavBarPopover/TreeCheckbox in CORE-2710 (#137). The caller still spreads last, so its ability to override the wrapper's variables is preserved, and the object form is unchanged (all 116 snapshots pass untouched). ProfileMenuItem and HelpMenuItem pass style down to NavBarMenuItem, so they need the CORE-2710 fix underneath to reach the DOM; this branch is stacked on that PR rather than duplicating it. Each wrapper gets a callback test, an override test and an object-form test. Confirmed failing before the fix: stashing only the two component files leaves 8 failed, 33 passed across the two specs -- the 8 callback/override cases fail, the 4 object-form cases pass. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
OpenStaxClaude
added a commit
that referenced
this pull request
Aug 31, 2026
Addresses Copilot's two review comments. ProfileMenuButton and HelpMenuButton merged the caller's style into their CSS-variable object with a spread. react-aria-components types style as `CSSProperties | ((renderProps) => CSSProperties)`, and spreading a function copies nothing, so a render-callback style was silently dropped and replaced by the wrapper's static object. Both now build their variables inside composeRenderProps, the same shape CORE-2710 (#137) uses for NavBarMenuItem/NavBarPopover/TreeCheckbox. The caller still spreads last, and the object form is unchanged -- all 116 snapshots pass untouched. Their style reaches react-aria's Button directly (HelpMenuButton's by way of NavBarButton, which passes it straight through), so this works against main as it stands. ProfileMenuItem and HelpMenuItem have the same defect but are left spreading for now, with a comment saying why: they hand style to NavBarMenuItem, which spreads it as well, so composing only here would send a function into that spread and lose these variables along with the caller's style. Both levels have to compose together, which needs #137 on main first. Eight tests: three per button wrapper (render-callback merged, render-callback overriding the wrapper variables, object form merging caller-last) plus object-form coverage for each menu item. Confirmed failing before the fix: stashing only the two component files leaves 4 failed, 33 passed across the two specs -- the four callback and override cases fail, the object-form cases pass. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
RoyEJohnson
requested changes
Aug 31, 2026
RoyEJohnson
left a comment
Contributor
There was a problem hiding this comment.
Rebase to main and resolve conflicts.
OpenStaxClaude
force-pushed
the
CORE-2710-compose-render-props-style
branch
from
August 31, 2026 17:29
61e5db8 to
27ab430
Compare
Contributor
Author
|
@RoyEJohnson Rebased onto Three files conflicted; the two components auto-merged.
Verification after the rebase:
Two heads-ups:
Re-requesting review. |
RoyEJohnson
pushed a commit
that referenced
this pull request
Aug 31, 2026
Addresses Copilot's two review comments. ProfileMenuButton and HelpMenuButton merged the caller's style into their CSS-variable object with a spread. react-aria-components types style as `CSSProperties | ((renderProps) => CSSProperties)`, and spreading a function copies nothing, so a render-callback style was silently dropped and replaced by the wrapper's static object. Both now build their variables inside composeRenderProps, the same shape CORE-2710 (#137) uses for NavBarMenuItem/NavBarPopover/TreeCheckbox. The caller still spreads last, and the object form is unchanged -- all 116 snapshots pass untouched. Their style reaches react-aria's Button directly (HelpMenuButton's by way of NavBarButton, which passes it straight through), so this works against main as it stands. ProfileMenuItem and HelpMenuItem have the same defect but are left spreading for now, with a comment saying why: they hand style to NavBarMenuItem, which spreads it as well, so composing only here would send a function into that spread and lose these variables along with the caller's style. Both levels have to compose together, which needs #137 on main first. Eight tests: three per button wrapper (render-callback merged, render-callback overriding the wrapper variables, object form merging caller-last) plus object-form coverage for each menu item. Confirmed failing before the fix: stashing only the two component files leaves 4 failed, 33 passed across the two specs -- the four callback and override cases fail, the object-form cases pass. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
RoyEJohnson
pushed a commit
that referenced
this pull request
Sep 1, 2026
Addresses Copilot's two review comments. ProfileMenuButton and HelpMenuButton merged the caller's style into their CSS-variable object with a spread. react-aria-components types style as `CSSProperties | ((renderProps) => CSSProperties)`, and spreading a function copies nothing, so a render-callback style was silently dropped and replaced by the wrapper's static object. Both now build their variables inside composeRenderProps, the same shape CORE-2710 (#137) uses for NavBarMenuItem/NavBarPopover/TreeCheckbox. The caller still spreads last, and the object form is unchanged -- all 116 snapshots pass untouched. Their style reaches react-aria's Button directly (HelpMenuButton's by way of NavBarButton, which passes it straight through), so this works against main as it stands. ProfileMenuItem and HelpMenuItem have the same defect but are left spreading for now, with a comment saying why: they hand style to NavBarMenuItem, which spreads it as well, so composing only here would send a function into that spread and lose these variables along with the caller's style. Both levels have to compose together, which needs #137 on main first. Eight tests: three per button wrapper (render-callback merged, render-callback overriding the wrapper variables, object form merging caller-last) plus object-form coverage for each menu item. Confirmed failing before the fix: stashing only the two component files leaves 4 failed, 33 passed across the two specs -- the four callback and override cases fail, the object-form cases pass. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
RoyEJohnson
force-pushed
the
CORE-2710-compose-render-props-style
branch
from
September 1, 2026 18:19
27ab430 to
e18e5ec
Compare
OpenStaxClaude
added a commit
that referenced
this pull request
Sep 1, 2026
Consequence of stacking this onto #137. Three of that PR's new tests asserted the component still sets its own --navbar-menu-item-* / --navbar-popover-border-color inline (`expect(...).toBeTruthy()`), which is exactly what this PR moves into NavBarMenuButtons.css. The assertions on the vanished inline defaults are gone; everything else in those tests stays. What CORE-2710 was actually protecting — that a caller's style reaches the element in both the object and render-callback forms — is still asserted, and tokens.spec.ts now guards the defaults centrally. Comments in place pointing at where the defaults live now, so the next reader does not think the coverage was simply dropped. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
RoyEJohnson
force-pushed
the
CORE-2710-compose-render-props-style
branch
from
September 1, 2026 19:09
e18e5ec to
590bda0
Compare
OpenStaxClaude
added a commit
that referenced
this pull request
Sep 1, 2026
Addresses Copilot's two review comments. ProfileMenuButton and HelpMenuButton merged the caller's style into their CSS-variable object with a spread. react-aria-components types style as `CSSProperties | ((renderProps) => CSSProperties)`, and spreading a function copies nothing, so a render-callback style was silently dropped and replaced by the wrapper's static object. Both now build their variables inside composeRenderProps, the same shape CORE-2710 (#137) uses for NavBarMenuItem/NavBarPopover/TreeCheckbox. The caller still spreads last, and the object form is unchanged -- all 116 snapshots pass untouched. Their style reaches react-aria's Button directly (HelpMenuButton's by way of NavBarButton, which passes it straight through), so this works against main as it stands. ProfileMenuItem and HelpMenuItem have the same defect but are left spreading for now, with a comment saying why: they hand style to NavBarMenuItem, which spreads it as well, so composing only here would send a function into that spread and lose these variables along with the caller's style. Both levels have to compose together, which needs #137 on main first. Eight tests: three per button wrapper (render-callback merged, render-callback overriding the wrapper variables, object form merging caller-last) plus object-form coverage for each menu item. Confirmed failing before the fix: stashing only the two component files leaves 4 failed, 33 passed across the two specs -- the four callback and override cases fail, the object-form cases pass. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
OpenStaxClaude
added a commit
that referenced
this pull request
Sep 1, 2026
CORE-2708 (#136) is on main now, so NavBarButton, NavBarMenuItem and NavBarPopover compose className through composeRenderProps. The wrappers added here can follow: ProfileMenuButton, ProfileMenuPopover, ProfileMenuItem, HelpMenuButton and HelpMenuItem passed the caller's className straight into classNames(), which ignores functions, so a render-callback className was silently dropped -- and unlike the style case TypeScript does not catch it. Composing only at this level was not possible before #136: the composed function would have reached NavBarMenuItem's classNames() and been discarded there, taking the profile-menu-item / help-menu-item class with it. Two tests per component, matching the shape #136 uses: a render-callback className reaches the DOM alongside the wrapper's own class, and a string className still composes. Confirmed failing before the fix: stashing only the two component files leaves the two render-callback cases red. The style half of this is still split. The two button wrappers compose it; the two menu items cannot until CORE-2710 (#137) lands, because NavBarMenuItem still spreads style. Comments in both files say so. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
OpenStaxClaude
added a commit
that referenced
this pull request
Sep 1, 2026
Consequence of stacking this onto #137. Three of that PR's new tests asserted the component still sets its own --navbar-menu-item-* / --navbar-popover-border-color inline (`expect(...).toBeTruthy()`), which is exactly what this PR moves into NavBarMenuButtons.css. The assertions on the vanished inline defaults are gone; everything else in those tests stays. What CORE-2710 was actually protecting — that a caller's style reaches the element in both the object and render-callback forms — is still asserted, and tokens.spec.ts now guards the defaults centrally. Comments in place pointing at where the defaults live now, so the next reader does not think the coverage was simply dropped. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…ppers NavBarMenuItem, NavBarPopover and TreeCheckbox merged the caller's `style` into their own CSS-variable object with a spread. RAC types `style` as `CSSProperties | ((renderProps) => CSSProperties)`, and spreading a function into an object literal copies no enumerable own properties, so a render-callback `style` was silently discarded — with no type error to catch it. Each wrapper now builds its CSS variables inside a `composeRenderProps` callback, so the caller's declarations land on the element in both forms. The caller still spreads last and keeps its ability to override the wrapper's variables, and the emitted inline styles for the object form are unchanged (snapshots pass untouched). TreeCheckbox's `as unknown as RACCheckboxProps['style']` double cast is replaced by a `CSSPropertiesWithVariables` return-type annotation, which types the custom properties properly instead of casting them away.
RoyEJohnson
force-pushed
the
CORE-2710-compose-render-props-style
branch
from
September 1, 2026 19:52
590bda0 to
9a9bae3
Compare
OpenStaxClaude
added a commit
that referenced
this pull request
Sep 1, 2026
Addresses Copilot's two review comments. ProfileMenuButton and HelpMenuButton merged the caller's style into their CSS-variable object with a spread. react-aria-components types style as `CSSProperties | ((renderProps) => CSSProperties)`, and spreading a function copies nothing, so a render-callback style was silently dropped and replaced by the wrapper's static object. Both now build their variables inside composeRenderProps, the same shape CORE-2710 (#137) uses for NavBarMenuItem/NavBarPopover/TreeCheckbox. The caller still spreads last, and the object form is unchanged -- all 116 snapshots pass untouched. Their style reaches react-aria's Button directly (HelpMenuButton's by way of NavBarButton, which passes it straight through), so this works against main as it stands. ProfileMenuItem and HelpMenuItem have the same defect but are left spreading for now, with a comment saying why: they hand style to NavBarMenuItem, which spreads it as well, so composing only here would send a function into that spread and lose these variables along with the caller's style. Both levels have to compose together, which needs #137 on main first. Eight tests: three per button wrapper (render-callback merged, render-callback overriding the wrapper variables, object form merging caller-last) plus object-form coverage for each menu item. Confirmed failing before the fix: stashing only the two component files leaves 4 failed, 33 passed across the two specs -- the four callback and override cases fail, the object-form cases pass. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
OpenStaxClaude
added a commit
that referenced
this pull request
Sep 1, 2026
CORE-2708 (#136) is on main now, so NavBarButton, NavBarMenuItem and NavBarPopover compose className through composeRenderProps. The wrappers added here can follow: ProfileMenuButton, ProfileMenuPopover, ProfileMenuItem, HelpMenuButton and HelpMenuItem passed the caller's className straight into classNames(), which ignores functions, so a render-callback className was silently dropped -- and unlike the style case TypeScript does not catch it. Composing only at this level was not possible before #136: the composed function would have reached NavBarMenuItem's classNames() and been discarded there, taking the profile-menu-item / help-menu-item class with it. Two tests per component, matching the shape #136 uses: a render-callback className reaches the DOM alongside the wrapper's own class, and a string className still composes. Confirmed failing before the fix: stashing only the two component files leaves the two render-callback cases red. The style half of this is still split. The two button wrappers compose it; the two menu items cannot until CORE-2710 (#137) lands, because NavBarMenuItem still spreads style. Comments in both files say so. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
OpenStaxClaude
added a commit
that referenced
this pull request
Sep 1, 2026
Addresses Copilot's two review comments. ProfileMenuButton and HelpMenuButton merged the caller's style into their CSS-variable object with a spread. react-aria-components types style as `CSSProperties | ((renderProps) => CSSProperties)`, and spreading a function copies nothing, so a render-callback style was silently dropped and replaced by the wrapper's static object. Both now build their variables inside composeRenderProps, the same shape CORE-2710 (#137) uses for NavBarMenuItem/NavBarPopover/TreeCheckbox. The caller still spreads last, and the object form is unchanged -- all 116 snapshots pass untouched. Their style reaches react-aria's Button directly (HelpMenuButton's by way of NavBarButton, which passes it straight through), so this works against main as it stands. ProfileMenuItem and HelpMenuItem have the same defect but are left spreading for now, with a comment saying why: they hand style to NavBarMenuItem, which spreads it as well, so composing only here would send a function into that spread and lose these variables along with the caller's style. Both levels have to compose together, which needs #137 on main first. Eight tests: three per button wrapper (render-callback merged, render-callback overriding the wrapper variables, object form merging caller-last) plus object-form coverage for each menu item. Confirmed failing before the fix: stashing only the two component files leaves 4 failed, 33 passed across the two specs -- the four callback and override cases fail, the object-form cases pass. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
OpenStaxClaude
added a commit
that referenced
this pull request
Sep 1, 2026
CORE-2708 (#136) is on main now, so NavBarButton, NavBarMenuItem and NavBarPopover compose className through composeRenderProps. The wrappers added here can follow: ProfileMenuButton, ProfileMenuPopover, ProfileMenuItem, HelpMenuButton and HelpMenuItem passed the caller's className straight into classNames(), which ignores functions, so a render-callback className was silently dropped -- and unlike the style case TypeScript does not catch it. Composing only at this level was not possible before #136: the composed function would have reached NavBarMenuItem's classNames() and been discarded there, taking the profile-menu-item / help-menu-item class with it. Two tests per component, matching the shape #136 uses: a render-callback className reaches the DOM alongside the wrapper's own class, and a string className still composes. Confirmed failing before the fix: stashing only the two component files leaves the two render-callback cases red. The style half of this is still split. The two button wrappers compose it; the two menu items cannot until CORE-2710 (#137) lands, because NavBarMenuItem still spreads style. Comments in both files say so. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
OpenStaxClaude
added a commit
that referenced
this pull request
Sep 1, 2026
Follows the CORE-2720 (#143) sweep, which this branch is now stacked on. The two new stylesheets repeated eleven palette hexes as var() fallbacks; they now read the --ox-* tokens instead, e.g. color: var(--help-menu-button-color, var(--ox-color-gray)); The override hooks are unchanged -- only their defaults moved from JavaScript to the CSS side, so the components no longer bind static custom properties inline. That means style is no longer destructured in ProfileMenuButton, ProfileMenuItem, HelpMenuButton or HelpMenuItem: it passes through in ...props and react-aria handles both the object and render-callback forms itself. Two consequences worth naming: - The CORE-2710 (#137) dependency is gone rather than deferred. The bug it guards against was a wrapper overwriting the caller's style, which these wrappers no longer do, so the menu items need nothing from #137. Same reasoning as the note #143 leaves on NavBarMenuItem. - iframeWrapperStyle and putAwayStyle are gone; the iframe wrapper and the put-away bar take their colours from HelpMenu.css. className composition stays -- that one is a real bug fix, not a default. The specs that asserted the inline defaults now assert what matters instead: the caller's style reaches the element in both forms, and the override hook still wins. Defaults are covered centrally by src/theme/tokens.spec.ts, which also fails on any colour literal that duplicates a theme value -- both new stylesheets pass it. Also carries CORE-2715 (#138) as a cherry-pick: it is on main but not yet in this base, and without it the old flaky ProfileMenu snapshot fails against the migrated component. It drops out as a duplicate when #143 rebases onto main. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
OpenStaxClaude
added a commit
that referenced
this pull request
Sep 2, 2026
Consequence of stacking this onto #137. Three of that PR's new tests asserted the component still sets its own --navbar-menu-item-* / --navbar-popover-border-color inline (`expect(...).toBeTruthy()`), which is exactly what this PR moves into NavBarMenuButtons.css. The assertions on the vanished inline defaults are gone; everything else in those tests stays. What CORE-2710 was actually protecting — that a caller's style reaches the element in both the object and render-callback forms — is still asserted, and tokens.spec.ts now guards the defaults centrally. Comments in place pointing at where the defaults live now, so the next reader does not think the coverage was simply dropped. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
OpenStaxClaude
added a commit
that referenced
this pull request
Sep 2, 2026
Addresses Copilot's two review comments. ProfileMenuButton and HelpMenuButton merged the caller's style into their CSS-variable object with a spread. react-aria-components types style as `CSSProperties | ((renderProps) => CSSProperties)`, and spreading a function copies nothing, so a render-callback style was silently dropped and replaced by the wrapper's static object. Both now build their variables inside composeRenderProps, the same shape CORE-2710 (#137) uses for NavBarMenuItem/NavBarPopover/TreeCheckbox. The caller still spreads last, and the object form is unchanged -- all 116 snapshots pass untouched. Their style reaches react-aria's Button directly (HelpMenuButton's by way of NavBarButton, which passes it straight through), so this works against main as it stands. ProfileMenuItem and HelpMenuItem have the same defect but are left spreading for now, with a comment saying why: they hand style to NavBarMenuItem, which spreads it as well, so composing only here would send a function into that spread and lose these variables along with the caller's style. Both levels have to compose together, which needs #137 on main first. Eight tests: three per button wrapper (render-callback merged, render-callback overriding the wrapper variables, object form merging caller-last) plus object-form coverage for each menu item. Confirmed failing before the fix: stashing only the two component files leaves 4 failed, 33 passed across the two specs -- the four callback and override cases fail, the object-form cases pass. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
OpenStaxClaude
added a commit
that referenced
this pull request
Sep 2, 2026
CORE-2708 (#136) is on main now, so NavBarButton, NavBarMenuItem and NavBarPopover compose className through composeRenderProps. The wrappers added here can follow: ProfileMenuButton, ProfileMenuPopover, ProfileMenuItem, HelpMenuButton and HelpMenuItem passed the caller's className straight into classNames(), which ignores functions, so a render-callback className was silently dropped -- and unlike the style case TypeScript does not catch it. Composing only at this level was not possible before #136: the composed function would have reached NavBarMenuItem's classNames() and been discarded there, taking the profile-menu-item / help-menu-item class with it. Two tests per component, matching the shape #136 uses: a render-callback className reaches the DOM alongside the wrapper's own class, and a string className still composes. Confirmed failing before the fix: stashing only the two component files leaves the two render-callback cases red. The style half of this is still split. The two button wrappers compose it; the two menu items cannot until CORE-2710 (#137) lands, because NavBarMenuItem still spreads style. Comments in both files say so. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
OpenStaxClaude
added a commit
that referenced
this pull request
Sep 2, 2026
Follows the CORE-2720 (#143) sweep, which this branch is now stacked on. The two new stylesheets repeated eleven palette hexes as var() fallbacks; they now read the --ox-* tokens instead, e.g. color: var(--help-menu-button-color, var(--ox-color-gray)); The override hooks are unchanged -- only their defaults moved from JavaScript to the CSS side, so the components no longer bind static custom properties inline. That means style is no longer destructured in ProfileMenuButton, ProfileMenuItem, HelpMenuButton or HelpMenuItem: it passes through in ...props and react-aria handles both the object and render-callback forms itself. Two consequences worth naming: - The CORE-2710 (#137) dependency is gone rather than deferred. The bug it guards against was a wrapper overwriting the caller's style, which these wrappers no longer do, so the menu items need nothing from #137. Same reasoning as the note #143 leaves on NavBarMenuItem. - iframeWrapperStyle and putAwayStyle are gone; the iframe wrapper and the put-away bar take their colours from HelpMenu.css. className composition stays -- that one is a real bug fix, not a default. The specs that asserted the inline defaults now assert what matters instead: the caller's style reaches the element in both forms, and the override hook still wins. Defaults are covered centrally by src/theme/tokens.spec.ts, which also fails on any colour literal that duplicates a theme value -- both new stylesheets pass it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
RoyEJohnson
requested review from
Dantemss
and
a balanced review from Copilot
September 2, 2026 20:50
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Jira: CORE-2710
The
stylehalf of the bug fixed forclassNamein CORE-2708 / #136.Problem
react-aria-componentstypesstyleon anything extendingStyleRenderPropsasCSSProperties | ((values) => CSSProperties). Three wrappers merged the caller'sstyleinto their own CSS-variable object with a spread:Spreading a function into an object literal is legal TypeScript and copies no enumerable own properties, so a caller-supplied
stylecallback was silently discarded. Unlike theclassNamecase there was no type error to catch it.Fix
NavBarMenuItem,NavBarPopoverandTreeCheckboxnow build their CSS variables inside acomposeRenderPropscallback, which resolves the callback form before the merge:The caller still spreads last, so its ability to override the wrapper's CSS variables is preserved.
TreeCheckboxalso drops itsas unknown as RACCheckboxProps['style']double cast in favour of aCSSPropertiesWithVariablesreturn-type annotation, which types the custom properties properly rather than casting them away.Acceptance criteria
styleinstead of discarding it.styletest, plus an override test and an object-form test. Confirmed failing before the fix: checking out only the two source files frommainleaves 6 failed, 18 passed across the two specs — the 6 callback/override cases fail, the rest pass.useRenderPropsresolves both forms to the same object, and none ofMenuItem/Popover/Checkboxsupply adefaultStyle).Rebase onto #136
Rebased onto
mainat bf6ef32 (#136, CORE-2708) per review. Resolution notes:NavBarMenuButtons.tsx/TreeCheckbox.tsx— auto-merged. Each wrapper now has both fixes side by side:composeRenderPropsonclassNamefrom CORE-2708: Compose render-callback classNames in react-aria-components wrappers #136,composeRenderPropsonstylefrom this branch.CHANGELOG.md— kept both entries under### Fixed, CORE-2708 then CORE-2710.NavBarPopoverthe two sides had conflicting scaffolding: CORE-2708: Compose render-callback classNames in react-aria-components wrappers #136 rendered each case inline, this branch added arenderPopoverhelper. Kept the helper and ported CORE-2708: Compose render-callback classNames in react-aria-components wrappers #136's twoclassNamecases onto it, so the describe block has one render path rather than two..github/workflows/checks.yml— theJIRA_EMAIL/JIRA_TOKENsecret fix this branch carried as a cherry-pick is now onmainvia CORE-2708: Compose render-callback classNames in react-aria-components wrappers #136, so it dropped out of the diff entirely.Post-rebase verification:
tsc --noEmitclean,eslintclean, full suite 256 passed / 116 snapshots green.Notes
ProfileMenu › opens menu on clickfailed itsdocument.bodysnapshot once during post-rebase verification, with a straydata-pressed="true"in the received output, then passed on the immediately following full-suite run and on 3 consecutive isolated runs. Same pre-existing press-state timing flake flagged before the rebase; it involves nostyleand nothing this PR touches. There is aCORE-2715-profile-menu-flaky-snapshotbranch for it. Flagging in case CI hits it.