Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Docs: Hitbox example import broken #64

Open
nikischin opened this issue May 30, 2024 · 2 comments
Open

Docs: Hitbox example import broken #64

nikischin opened this issue May 30, 2024 · 2 comments

Comments

@nikischin
Copy link

nikischin commented May 30, 2024

Not 100% if this might be because I did something wrong with the imports, but seems like your example at https://atlassian.design/components/pragmatic-drag-and-drop/optional-packages/hitbox/about uses a broken import:

image

I did some research and if I replace @atlaskit/pragmatic-drag-and-drop-hitbox/addon/closest-edge with @atlaskit/pragmatic-drag-and-drop-hitbox/closest-edge (leaving out the /addon) it does the job for me.

Generally speaking I find all those imports a bit confusing and would prefer to have one package with all those packages which for my understanding should have the same bundle size if tree-shaking is enabled? VS code often mixes up auto-suggestions and recommends some paths to the /dist directories which can be quite confusing. (see this)

Except that I really like your library, thank you so much!!

@nikischin
Copy link
Author

Also the import for the scrollJustEnoughIntoView is broken unfortunately.
image
(Generally I find it super hard to find this information through the navigation, as it is hidden in a sub sub view).

The import should be import { scrollJustEnoughIntoView } from '@atlaskit/pragmatic-drag-and-drop/element/scroll-just-enough-into-view'; (the /element is missing in the example)

@ivanjeremic
Copy link

Generally speaking I find all those imports a bit confusing and would prefer to have one package with all those packages which for my understanding should have the same bundle size if tree-shaking is enabled

Exactly my thoughts, this library, and the add-ons are prime examples of overthinking and making it worse. Bundlers will do the job just fine that's why we have them. The amount of people working without bundlers is minimal, for those who work without bundlers all these packages can stay how they are but for the majority of people the version that is published to npm should be a package with all the modules, and developers will use only the module they need that`s how ESM works, bundlers will take care of the rest.

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

No branches or pull requests

2 participants