feat(responsive): add useContainerWidth hook#1144
feat(responsive): add useContainerWidth hook#1144JeanMarcMilletScality wants to merge 4 commits into
Conversation
Container-width (not viewport) responsiveness primitive for narrow host side-panels. Exposes isNarrow / isNarrowerThan(px) for multi-tier layouts via a callback-ref ResizeObserver, with an optional hysteresis band to prevent flicker on a breakpoint. Ships the NARROW_BREAKPOINT_PX and TABLE_NARROW_BREAKPOINT_PX constants and is exported from the library entry point. Opt-in; no existing behaviour changes. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Hello jeanmarcmilletscality,My role is to assist you with the merge of this Available options
Available commands
Status report is not available. |
Waiting for approvalThe following approvals are needed before I can proceed with the merge:
Peer approvals must include at least 1 approval from the following list: |
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
Stubs a controllable ResizeObserver to verify the hook reports wide-first before measuring, flips on the breakpoint in both directions, rounds the measured width, honours a custom breakpoint and the hysteresis band, and stops observing a detached node. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Rename the test cases to state the exact return value being asserted (isNarrow / isNarrowerThan / width) and to flag the ones relying on the default breakpoint. Their widths are derived from NARROW_BREAKPOINT_PX so the relationship to the default is explicit. No behaviour change. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Waiting for approvalThe following approvals are needed before I can proceed with the merge:
Peer approvals must include at least 1 approval from the following list: |
JeanMarcMilletScality
force-pushed
the
improvement/responsive-use-container-width-hook
branch
from
0e09fca to
218e4d8
Compare
useContainerWidth should report the element's own width — matching its CSS width and the breakpoint constants — rather than a value that shifts with the container's padding. Read borderBoxSize in the observer, and where it is unsupported re-measure the target's border box (instead of contentRect's content box) so every path agrees with the getBoundingClientRect sync read and isNarrow never flips after mount. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
JeanMarcMilletScality
force-pushed
the
improvement/responsive-use-container-width-hook
branch
from
218e4d8 to
c736d3f
Compare
| entry?.target.getBoundingClientRect().width; | ||
| if (typeof observedWidth === 'number') { | ||
| const rounded = Math.round(observedWidth); | ||
| setWidth((prev) => (prev === rounded ? prev : rounded)); |
There was a problem hiding this comment.
strictly equivalent to the simpler setWidth(rounded) for number values
Waiting for approvalThe following approvals are needed before I can proceed with the merge:
Peer approvals must include at least 1 approval from the following list: |
damiengillesscality
left a comment
damiengillesscality
left a comment
There was a problem hiding this comment.
I don't vibe too much with this. The signature of useContainerWidth is a bit strange, breakpoint does not seem like a parameter I would expect for such function. Since we use this hook to monitor some container width, why would the default 640px breakpoint be relevant for most of our containers ? The choice of returning isNarrow and isNarrowerThan is odd too. Is isNarrowerThan is like admitting breakpoint parameter is irrelevant. And isNarrow is not that useful I would rather write a more explicit (width ?? 0) < breakpoint in my main code. On that, I will add a small picky note undefined is better than null for no width value both semantically and in the hypothesis a core-ui user would not use typescript since undefined < number is always false which is not true with null.
Regarding the use cases is it also necessary to export this or could it be contained in core-ui ? It could be better to not expend the not design system part of our api imho.
Have you considered the very good and stable use-resize-observer ?
And one last thing have you updated your knowledge on @container css queries ? They are well supported and can probably replace js in some of your use cases.
Waiting for approvalThe following approvals are needed before I can proceed with the merge:
Peer approvals must include at least 1 approval from the following list: The following reviewers are expecting changes from the author, or must review again: |
3 participants
What
First of a progressive series merging the responsive-panels exploration into
development/1.0. This PR adds only the foundational hook —useContainerWidth— plus its library export and unit tests. Nothing else from the exploration branch (AdaptivePanels, column-drop, icon-only buttons, fluid forms, navbar/sidebar/table changes) is included here.Details
useContainerWidthis a container-width (not viewport) responsiveness primitive, for screens that must stay usable when a host side-panel shrinks the available space without changing the viewport width.ResizeObserver; returnsisNarrow/isNarrowerThan(px)for multi-tier layouts.hysteresisband to avoid flicker when the container rests on a breakpoint.NARROW_BREAKPOINT_PX(640) andTABLE_NARROW_BREAKPOINT_PX(820) constants, plusUseContainerWidthOptions/UseContainerWidthResulttypes.src/lib/index.ts.Compatibility
Purely additive / opt-in — no existing component behaviour changes.
Verification
tsc --noEmitcleaneslintclean on changed filesjest— 9 unit tests covering wide-first-before-measure, breakpoint flips in both directions, width rounding, custom breakpoint, the hysteresis band, and detaching the observed node🤖 Generated with Claude Code