Skip to content

feat: box layout and resize + anchor observer primitives - #10558

Open
nwidynski wants to merge 1 commit into
adobe:mainfrom
nwidynski:feat-box-layout
Open

feat: box layout and resize + anchor observer primitives#10558
nwidynski wants to merge 1 commit into
adobe:mainfrom
nwidynski:feat-box-layout

Conversation

@nwidynski

Copy link
Copy Markdown
Contributor

Closes no issues directly, because this PR is intentionally limited to additions only. Migrating call sites to the new utilities and signatures is to be done in chore follow-ups, because it would otherwise be rather hard to review what changed here.

Disclaimer: This PR is tightly related to #10556! Unfortunately Github doesn't allow for Stacks to be built across forks, so we have to do with this :/

From a high-level, this PR fixes various issues with layout precision and lays the groundwork for an alternative to floating-ui. The primary file to look at is layout.ts, which features a short description.

Will close #7142, #10036, #10131, #9318 and more.

✅ Pull Request Checklist:

  • Included link to corresponding React Spectrum GitHub Issue.
  • Added/updated unit tests and storybook for this change (for new code or code which already has tests).
  • Filled out test instructions.
  • Updated documentation (if it already exists for this component).
  • Looked at the Accessibility Practices for this feature - Aria Practices
  • I understand every change in this PR and can explain why it's there.
  • If AI-assisted, I followed our AI contribution guidance and pointed my assistant at CLAUDE.md.

📝 Test Instructions:

🧢 Your Project:

@nwidynski

nwidynski commented Sep 2, 2026

Copy link
Copy Markdown
Contributor Author

@LFDanLu This is the PR to look at for floating-ui, although it also addresses various other issues, like the ones coming from scrollbar-gutter: stable in Chrome. Please note that none of my PRs are AI assisted if not explicitly marked as such. I've just been working on these for quite some time so they land at once 😅

@reidbarber reidbarber left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is awesome!

* Returns the bounding rectangle of this target in frame coordinate space.
* Similar to `element.getBoundingClientRect()`, but normalized across engines.
*/
public get boundingRect(): DOMRect {

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

getBoundingClientRect returns values with transforms applied. Should the values in here be converted into the same coordinate space? (i.e. * scaleX, * scaleY)

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You mean the computed style values, right? If so, then yeah, we probably should.

this.update();
});

super.disconnect();

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This sets changedAt to 0 here, is that right? Reconnection wouldn't happen in the next frame.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah no, good catch! I'm still unsure about the rAF loop in general. It was intended as a performance measure so the browser wouldn't have to perform layout on the sentinels each frame, but I'm unsure whether that's actually a net benefit. Will need benchmarks.

* Similar to `element.getBoundingClientRect()`, but intersected with all ancestors.
*/
public get visibleRect(): DOMRect {
throw new Error('Not implemented yet.');

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TODO?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Kinda. I don't have a great use case for it yet, besides window scrolling in virtualizer, so it just satisfies the type for now. IIRC it wasn't added in virtualizer because walking the tree would be too costly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Pinch zooming causes modal overlay to flicker

2 participants