Replies: 3 comments 1 reply
-
|
The problem is we would then ensure all the tools don't introduce breaking changes between releases. It would be extremely complicated. |
Beta Was this translation helpful? Give feedback.
-
|
But you could just expose them for those who would find them traversing the code without guaranteeing it being part of the official interface.
It could be mentioned in the doc and case closed.
|
Beta Was this translation helpful? Give feedback.
-
|
Right... Ok, I can see that this will not be added. So here is my fork of this repository with updated README.md with instructions how to generate such version with these exposed export {getBoundingClientRect} from './utils/getBoundingClientRect';
export {getCssDimensions} from './utils/getCssDimensions';
export {getDocumentRect} from './utils/getDocumentRect';
export {getHTMLOffset} from './utils/getHTMLOffset';
export {getRectRelativeToOffsetParent} from './utils/getRectRelativeToOffsetParent';
export {getViewportRect} from './utils/getViewportRect';
export {getVisualOffsets} from './utils/getVisualOffsets';
export {getWindowScrollBarX} from './utils/getWindowScrollBarX';
export {isStaticPositioned} from './utils/isStaticPositioned';
export {unwrapElement} from './utils/unwrapElement';https://github.com/stopsopa/floating-ui Issue can be closed. Cheers |
Beta Was this translation helpful? Give feedback.
-
|
Just as a follow-up explanation of my reasoning for raising this issue: It seems from the tutorial https://floating-ui.com/docs/tutorial#before-proceeding that the driving design vision was to act as a polyfill for CSS to correctly position absolutely-positioned anchored elements on the document, which is, in my opinion, the best thing developer can do -> enhance/provide the fundamentals and this way empower the consumers. One of the main features to facilitate the core functionality of this tool seems to be calculating the position of DOM elements on the page. This library appears to contain the best algorithms I've seen so far. Writing and properly testing such algorithms is not a trivial task to accomplish, so this represents significant value in itself. I know how hard it is because I've tried to do that in the past myself: https://github.com/stopsopa/elkanatooltip?tab=readme-ov-file#demo It would be a shame to keep it hidden in the internals and not to expose this via an API, thereby preventing other projects from utilizing it. That's why I'm advocating for publishing it. here are changes with suggested PR |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Actually I'm rather suggesting to export all tools from utils.
Because in order to get my hands on getBoundingClientRect I had to do my own build using getBoundingClientRect.ts as an entrypoint for esbuild.
It just makes sense since these are implemented so well.
Great project. Cheers
Beta Was this translation helpful? Give feedback.
All reactions