https://medium.com/@FezVrasta/popper-js-v1-5e8b3acd888c
This article is translated from a blog by the author of popper.js
In the past, I would spend hours writing the same piece of code, fine-tuning it, to better position my tooltips and popovers in a web app. Every time I start a new project, there are always different needs for positioning according to different environments. This kind of tediousness reaches the extreme when I use emberjs to develop a large-scale application. Due to the poor UX design decision in this project, she wants to support hover and a popover on almost every element!
In this big project, we started to use the tooltip of bootstrap3, and constantly implemented new functions through hacking code.
In this large project, an important requirement is: it is not allowed to move the tooltip element to the direct child of the body element, because if it did, our code would be broken.
After almost a year of developing the project and maintaining our custom implementation, I decided to use Tetcher because it seems to be very powerful and stable. . Unfortunately, after playing for a few hours, I found out that he has an important flaw or limitation: he automatically modifies the dom node, moving the popper to the position of the body's son. He'll add some classes and add some inline styles that you have little control over!
So I went to github and spent a lot of time looking for alternatives, but I ended up finding nothing. Could it be that no one needs a similar library? Or has no one been able to abstract and implement a lib that can be released separately?
I decided to spend a weekend event rewriting the positioning engine used in our own project, and that's where popper.js comes in again.
In the v0.x era, popper was just a js file, thanks to a few functions, focused on keeping the lib small and lightweight. I wanted popperjs to be extensible, so I decided to use the middleware system. The main idea is: calculate the position of elements and allow middleware to modify this position according to specific needs.
For example: once we have the popper's position and give some bounds constraints, the modifier can check if the popper will overflow and automatically reverse the position to ensure that the popper is not cut off by the viewport.
After working for a while, I found that we need a better code structure to better maintain and use it, which is the original intention of the v1.0 release.
In order to manage the code, I decided to switch to es6 modules. I introduced rollup as the code bundler and babel as the transpiler, and I also switched the automated test engine from a headless chrome setup to the saucelabs cross-browser test suite.
During the development process, I decided to put the first-level modifier/middleware of each functional module into their own files, so that they can be reused in Libray.
update process:
I also refactored the entire update process, which is the code that needs to be called every time the popper needs to update the position of the element.
This update process will be called every frame, which means about 60fps, which can ensure smooth and coherent position modification. In order to achieve this coherent and smooth goal, the code of the entire update process must be concise, and avoid direct access to the dom as much as possible. The following is its workflow