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.
$ npm i --save resize-detector
import { addListener, removeListener } from 'resize-detector'
// adding listener
addListener(elem, callback)
// removing listener
removeListener(elem, callback)
this
inside callback
function is the element whose size has been changed.
-
Is polyfill?
No.
-
Native first
Yes.
-
Strategy
Scroll-based + Mutation-based.
-
Pros
- Small size.
- Minimal limitations.
-
Side effects
- Targets with
position: static
will becomeposition: relative
. - Several hidden elements will be injected into the target elements.
- Targets with
-
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 becomeposition: relative
. - Several hidden elements will be injected into the target elements.
- Targets with
-
Limitations
- Cannot track detach/attach or visibility change on IE10 and below.
-
Is polyfill
Yes.
-
Native first
Yes.
-
Fallback Strategy
Use
MutationObserver
to observe every mutation in a document. For IE9/10, use Mutation Events instead. -
Pros
- Small size.
- Minimal side effects on target elements.
- Can track detaching/attaching in both DOM trees and render trees as soon as it's triggered by DOM mutation.
-
Limitations
- Need extra transition event handling to catch size change from user interaction pseudo classes like
:hover
. - Delayed transitions will receive only one notification with the latest dimensions of an element.
- Need extra transition event handling to catch size change from user interaction pseudo classes like
-
Is polyfill
No.
-
Native first
No.
-
Strategy
Listen to
resize
events via hidden<iframe>
s. -
Pros
Dead simple.
-
Side effects
- Targets with
position: static
will becomeposition: relative
. - Several hidden elements will be injected into the target elements.
- Relatively low performance.
- Targets with
-
Limitations
- Inapplicable for void elements.
- Cannot track detach/attach or visibility change.
-
Is polyfill?
Yes.
-
Native first
Yes.
-
Fallback Strategy
Long polling through
requestAnimationFrame
orsetTimeout
. -
Pros
Dead simple.
-
Side effects
- Might be not so performant by checking rendered sizes in each animation frame.
-
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 becomeposition: relative
. - Several hidden elements will be injected into the target elements.
- Targets with
-
Limitations
- Package size is relatively large.
- Inapplicable for void elements.
- Cannot track detach/attach or visibility change.