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
feat: migration to popper v2 #333
feat: migration to popper v2 #333
Conversation
@@ -58,13 +58,13 @@ | |||
"popover" | |||
], | |||
"peerDependencies": { | |||
"@popperjs/core": "^2.0.0", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This shouldn't be here, having it in dependencies
is enough.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is common practice (see react-redux or mobx-react). And now we don't need re-export things like placements
or modifierPhases
. User can import all that he or she need directly from original library.
type VirtualElement, | ||
type Modifier, | ||
type ModifierArguments, | ||
} from '@popperjs/core/lib'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think importing from @popperjs/core
should be enough
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
unfortunately it doesn't work, popper exports from main file @popperjs/core
only three things:
export { createPopper, popperGenerator, defaultModifiers };
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See this one + official doc
Isn't v2 just going to be a |
I was thinking the same, but probably it won't hurt to first upgrade the existing API to use Popper 2, and later add the With this PR people can still do:
Later we can add:
The render-prop based API is still handy if you need to create several poppers bound the the same reference element. |
First of al thanks for the great lib. When Popper 2 is release we implemented thin react integration locally in our project and I extracted it into one gist (in case there is any chance it could be usefull): https://gist.github.com/akozhemiakin/e91c23b8ebc2ceb9c59edab947b2de92 |
Adding a hook to the lib would most likely force to change peerDependency Additionally, adding a hook later means that there will be two implementations of the popper in the lib: hook-based and class-based. It would be more reasonable to create a hook-based implementation first and reuse it to create functional component with render prop to replace current class-based implementation. Thank you for your hard work, great lib! |
Hi, folk. I created this PR in hope that we can iteratively upgrade this library to Popper v2. Honestly, I don't understand why we can't merge this one and move on. My changes don't relates to hook API. Hook API can be added in next iterations. These changes don't mean that there will be two implementations: hook-based and class-based. We can always move core implementation to hooks and add wrappers for supporting previous API. And hook API is not silver bullet. How will developers who prefer classes use this library, if there is only hook API? Should they write own wrappers? @FezVrasta If you disagree with my answers for your comments, just tell me, and I will fix all. I think, new API providing is very complex problem and we need some small milestones to achieve main goal. Let's try to take small steps towards right direction. This will help library user to get use to new API. We can release first implementation, get feedback and continue improve this solution. |
I’m sorry if it’s taking so long, I’ve been through some major changes in my life and now both my wife’s and mine families are locked down in Italy, we live elsewhere so we are very worried and this doesn’t help me to focus on my side projects. I’ll try to get back to this PR in the next days. |
Oh, sorry if I was too persistent. I sincerely wish a speedy resolution to all your problems. I hope that I can help with the development as much as I can. |
Migration Guide
@popperjs/core is peer dependency now. Instalation:
If you want use
placements
ormodifierPhases
enums, you can import they directly from @popperjs/core:modifiers
prop should be present as array with changed format (see official docs).eventsEnabled
prop is removed, you can use Event Listeners modifier to control it (see official docs).positionFixed
prop is removed, you can usestrategy
prop instead (see official docs).outOfBoundaries
is not provided in<Popper>
component render child anymore, two new props are provided now:isReferenceHidden
andhasPopperEscaped
. They are provided from Hide modifier.scheduleUpdate
method is renamed toupdate
(like in @popperjs/core). Now it returnsPromise<PopperJS.State>
orPromise<null>
if you try call it whenPopper Instance
is not defined.Change List
<Popper>
component