[Popper][base-ui] Replace or refactor to use Floating UI

[rodrigofariow]

With https://floating-ui.com/ aiming to replace Popper.js, I was wondering what are your plans with regards to Popper component. Are you planning to deprecate it, refactor it to use Floating UI or any other changes?
I wanted to know if I can use it without worring too much if it will get changed soon.

Thank you for your time 🙏

[siriwatknp]

cc @michaldudak

[michaldudak]

We don't plan to do anything breaking in the v5 timeframe, so you're safe to use whatever we currently have. We'll likely upgrade to Floating UI at some point, as we generally want to use the latest dependencies. If upgrading from Popper to Floating UI cause breaking changes, we'll do it in the next major.

cc @mnajdova (as the co-owner of this component)

[mnajdova]

The plan sounds good to me 👍

[rodrigofariow]

Sounds good, thanks for the info!

[oliviertassinari]

If upgrading from Popper to Floating UI cause breaking changes, we'll do it in the next major.

I have added this issue to #30660 and added the v6.x label, to be sure we consider this in the next major cc @atomiks. We have to consider the pros & cons.

Pros:

• It seems to be a bit smaller: https://bundlephobia.com/package/@popperjs/core vs. https://bundlephobia.com/package/@floating-ui/dom
• …

Cons:

• Breaking changes
• …

Benchmark

• https://mantine.dev/changelog/5-0-0/#migration-to-floating-ui

[jy95]

Floating UI has a page for the pros https://floating-ui.com/docs/motivation#comparison-with-popper-style-api
For the migration guide : https://floating-ui.com/docs/migration

So what could be the cons ? The refactoring cost ?

[o-alexandrov]

This issue should be labeled as a bug, instead of new feature.

• Floating-UI is a rebranding of the same library as its author explained here

There are many resolved bugs in Floating-UI in the past few months (when Popperjs didn't receive updates).

• since Floating-UI is a rebranding, we should consider its bugfixes (at least some of them) as fixes to @popperjs/core

---

@popperjs/core is 252% (2.5x times) heavier than @floating-ui/react-dom when bundling with vite 4/rollup 3 (both latest).

[atomiks]

@o-alexandrov it's lighter but not that much lighter. It depends what features you import though, as each piece is tree-shakeable (within reason).

https://bundlejs.com is the best source to check. For example, for common usage:

• @floating-ui/react-dom (5.88 kB min + Brotli)
• react-popper (8.54 kB min + Brotli)

[o-alexandrov]

@atomiks most importantly, do you agree on labeling as a bug based on the raised arguments?

---

You can compare weight on bundlephobia, bundlejs, etc. for a general idea of the weight.

However, to know the precise difference, you should compare it postbundling, achieving feature-parity.

• it’s as you said, code could be better written on how well side-effects could be inferred and other nuances that allow for better tree-shaking and minification

My weight observation is based on making changes in the Menu component from MUI.

• ex. copy Menu component, replace popper, bundle, compare weight between two components

[oliviertassinari]

We might be able to rely entirely on CSS with https://drafts.csswg.org/css-anchor-position/ to solve the positioning problem. I think within 3 years. It's detailed a bit in https://developer.chrome.com/blog/tether-elements-to-each-other-with-css-anchor-positioning/. I raised the opportunity in #35914 (comment).

What I conclude from this is that using @floating-ui/dom makes more sense than @floating-ui/react-dom so we can minimize future breaking changes, by keeping a close developer-facing API.

One last thought, is there a CSS anchor() ponyfill that we could use? Unless we consider that it's too early.

[atomiks]

There's a polyfill for CSS anchor positioning using @floating-ui/dom 54k gzipped (but it's not a ponyfill). I guess using @floating-ui/dom directly would be the best choice before being able to use native CSS in the future. Note that if CSS doesn't support all the features it has, the positioning part of Floating UI could start leveraging native CSS where possible while also enhancing/adding additional features on top, acting as a sort of wrapper.

[o-alexandrov]

It would be great, if the end users wouldn't have to download floating-ui (as it'd improve Lighthouse LCP everyone has issues with), if their browsers support CSS anchor positioning.

In other words, imho, this feature should be conditionally dynamically imported w/ a polyfill (mentioned above), but not shipped to everyone. It doesn't matter the polyfill is large, two-thirds of users are typically supported within first weeks of the browsers' API release, so on average the data transfer should decrease comparing to shipping floating-ui to everyone, especially in web-based mobile apps and for 100% of Electron (desktop) users due to the bundled latest version of Chromium.
MUI shouldn't wait until the feature is widely supported by browsers, but instead have conditional dynamic imports.
(out of topic, same as Temporal API for date pickers)

[atomiks]

@o-alexandrov the main problem is that it appears CSS doesn't completely replace all of Floating UI's features, namely uncertainties with same-placement overflow prevention (shifting), arrows, boundaries, virtual elements, available space size, inline elements, cross-document anchoring, shadow DOM, virtual/software keyboards on iOS, pinch-zooming, etc. I guess it depends on what features MUI wants or needs, but some of those are quite fundamental.

I'm not sure if shipping a polyfill (rather than something pure) is something a library should be doing 🤔 . I didn't realize the polyfill was that large which is unfortunate, shipping 50 kB to 1/3 of users, especially browsers other than Chrome/old iOS (it would especially affect mobile users), doesn't seem great. Waiting for wider support seems like a better path to me — the positioning part of Floating UI could get smaller anyway if it detects native CSS can be used for core parts, reducing bundle size.

[o-alexandrov]

@atomiks imho, the ideal for MUI would be:

flowchart
  1{Browser supports CSS anchor positioning}
  1 --> |No| 2{Have enough time for a more complex fallback}
  1 --> |Yes| 3[use CSS anchor positioning]
  2 --> |Yes| 4[load floating-ui dynamically, so the fallback is minimal in size]
  2 --> |No| 5[load CSS anchor positioning polyfill dynamically]

Loading

Unfortunately, in the source code of floating-ui, end users always load everything they import, there are no dynamic imports (no feature detection based imports).

• I understand CSS anchor positioning is in early stages

Are you saying there are plans on adding a dynamic import for CSS anchor positioning to floating-ui in the future?

[oliviertassinari]

@michaldudak On the topic what to do with the <Popper> component, I think that we should start by updating https://mui.com/base-ui/react-popper/ to give us a better hold of production constraints, we should likely:

1. Add a demo with a clean transition. For example to match https://www.radix-ui.com/docs/primitives/components/popover. The current demos are not usable in production because of this IMHO.
2. Add a "without portal" demo. While most cases need a portal (otherwise it's unusable anytime there is an overflow CSS property), I think that it could be nice to make this optional.

Otherwise,

• a. Consider a component API to automatically wire the anchorEl. The problem with demos like https://mui.com/base-ui/react-popper/#basics is that anytime your component logic grows, hooks make it hard to follow the logic, you need to scroll up and down to understand the logic, not a great DX. MUI X repository has not too bad examples of this problem, e.g. mui-x/docs/data/data-grid/state/RestoreStateApiRef.js.
• b. the Popper bundling the Portal is a questionable choice. If we remove it (I like the idea to keep things flat like in Radix, making Popover.Portal optional), we would still need an API to change the overflow detection https://floating-ui.com/docs/detectoverflow#altboundary based on portalled vs. not portalled.
• c. I think that it would be much better to wrap @floating-ui so 1. developers don't have to think about which version they use, and so that once CSS 2. so we can add custom plugins, e.g. collisionPadding, something we need for [tooltip] Tooltip touch the edge base-ui#413. 3. so we can, later on, more easier handle migration between versions, like this allows us today between popper and floating UI. A quick benchmark: Radix UI wraps @floating-ui/dom, React Aria build it in house, ariakit wraps @floating-ui/dom.
• d. to optimize the solution to be compatible with a world CSS based. So not sure how much space there is for a hook or even a component in the future.