[Umbrella] Roadmap to Floating UI v1

Roadmap

Part of the rebranding to Floating UI was that the package would eventually support “interactions” logic (like Tippy). This has taken a while and I had a lot of false starts but I think it’s close to an early release 🥳 . It will start at v0 and it’s React-only, as re-inventing useEffect for vanilla was a mess. The logic might be able to be shared across frameworks eventually though.

In the meantime, I also want to get the main positioning library to v1. Some have been holding off adopting the package due to it being v0, so the sooner this is fully stable the better. These are the current breaking changes I want to make. For the most part these won’t require major refactors for v0 users as the API is quite thin anyways.

If you’re making a library and using this package I recommend not exposing any of the underlying API of Floating UI. This will allow you to update easily without affecting your consumers. The main problem with such a low-level library is that it can’t update frequently due to churn (Popper is used as a dependency in thousands of packages). I want to get the API right for v1 so the major version will be solid for a long time.

v1 be released by the end of March. Feel free to share any problems with the API you have.

1. Work more with logical properties rather than physical ones ☑️

This means the placement string ${physicalSide}-${logicalAlignment} should support RTL automatically. In addition offset.crossAxis should also adapt to the alignment appropriately.

Issues:

• https://github.com/floating-ui/floating-ui/issues/1530
• https://github.com/floating-ui/floating-ui/issues/1170

2. ~Merge flip and autoPlacement into one generic placement-changing middleware~

Ditched this idea for now

3. Rename getScrollParents to getOverflowAncestors export an official API for updating automatically ☑️

These are the cases you’ll want to update:

• Ancestor scrolling
• Ancestor resizing
• Element resizing
• Reference element changing location on the screen (transform scale, animations, etc…)

4. Make platform object less dependent on DOM terms ☑️

There are terms like getDocumentElement() that are a little too DOM-y and could be made more agnostic. I need to make a Canvas Floating UI POC to dogfood the names. Charting library tooltip stuff is the best example I’ve seen where Floating UI could be used in a <canvas />

5. Improve lifecycle resetting/skipping ☑️

Some difficulties popped up in the following PR: https://github.com/floating-ui/floating-ui/pull/1496 - this area can use improvement

[atomiks]

https://github.com/floating-ui/floating-ui/issues/1580 is the last thing I’m going to investigate this weekend to see if there’s anything that needs to break. Then I’m going to release v1 RC versions of @floating-ui/core, @floating-ui/dom, and @floating-ui/react-dom (Rolling Versions doesn’t support RC, so it’ll just be a new v0 minor with RC in the changelog title).

Then after 2 weeks if there are no issues I will release v1 😄

[atomiks]

I just released a big update for all the packages with a bunch of changes and some breakages, but I think the API in this state should be very close to v1. The next release will likely be a v1 RC (where some minor details may change), and then after that a final v1.0.0 release 🎉