Replies: 2 comments
-
I'm hesitant to move any interaction logic to the vanilla library as it will broaden its scope beyond being a CSS anchor positioning polyfill, which is the most maintainable and clear to document. Keeping interaction features limited to React helps clearly separate their roles - unless we wanted to port most other interactions to vanilla JS. It's hard to document which library supports what feature already. |
Beta Was this translation helpful? Give feedback.
-
I completely understand the hesitation, it would be a nightmare to have to support complex interactions and components in the base library. We're currently using the @floating-ui/dom library in a project that does not use react. So far, the high quality of this library enabled us to implement the components we need on our side (tooltip, combobox). This is the first time we're facing a "limitation", we have to add a tooltip that has potentially large content, and so we would limit the height of the content and add a scrollbar. I could very well re-implement the safe polygon logic on our side, but this feels like a utility that could be directly in the core library. In the end, it is your decision |
Beta Was this translation helpful? Give feedback.
-
The base library would greatly benefit from the addition of safe polygon logic as a building block for developers to use.
For clarification, I did see the discussion to add sub-menus, but this is not what I am talking about. Let's leave all the
to consumers of the library, and only provide safe polygon as a building block to use. This is to expand the use-cases covered by the base library, for example something simple like a tooltip with a scrollbar would benefit from this additional feature.
Looking at the code, it already seems like there are very few dependencies to react. I'm open to contributing if there's consensus.
Beta Was this translation helpful? Give feedback.
All reactions