Resize Detector
This project is basically a modified version of sdecima/javascript-detect-element-resize including these changes:
- Try to utilize native
ResizeObserver first.
- Adopt Mutation-based approach to track detaching/attaching in both DOM trees and render trees (see que-etc/resize-observer-polyfill).
- Use ES Modules.
- Put most CSS content inside a separate
.css file.
- Drop support for IE8 and below.
- Make the package available from npm.
Installation
$ npm i --save resize-detector
Usage
import { addListener, removeListener } from 'resize-detector'
// adding listener
addListener(elem, callback)
// removing listener, callback can be omitted to indicate that
// all event listeners should be removed
removeListener(elem, callback)
this inside callback function is the element whose size has been changed, also callback receive element as first argument.
Heads up
As resize-detector is published in both ES Module & CommonJS format and when you use webpack to bundle your app, the ESM version will be imported. It is not transpiled by Babel or similar tools so you have to transpile it in your build process.
For webpack with babe-loader you need to add it to the include field of the options:
// ...
{
test: /\.js$/,
loader: 'babel-loader',
include: [
// other stuff to be transpiled
// ...
path.resolve('node_modules/resize-detector')
]
}
// ...
If you are using other toolchain, just configure your bundler similarly so that resize-detector will be transpiled during build process.
Limitations and caveats
Comparison with other projects
-
Is polyfill?
No.
-
Native first
No.
-
Strategy
Scroll-based.
-
Pros
- Small size.
- Higher performance comparing to hidden
<object>s.
- Compatible with down to IE7.
-
Side effects
- Targets with
position: static will become position: relative.
- Several hidden elements will be injected into the target elements.
-
Limitations
- Cannot track detach/attach or visibility change on IE10 and below.
-
Is polyfill?
No.
-
Native first
No.
-
Strategy
Either hidden <object>s or scroll-based.
-
Pros
Two approaches available (Really, why?) with scroll-based approach being much faster than hidden <object>s.
-
Side effects
- Targets with
position: static will become position: relative.
- Several hidden elements will be injected into the target elements.
-
Limitations
- Package size is relatively large.
- Inapplicable for void elements.
- Cannot track detach/attach or visibility change.
