Could this be updated to return the native ResizeObserver if it exists? #127
-
|
Hey, first of all I'm excited to use this polyfill! Seems really good. Ok, as I was typing this, I think I realized why this is always ponyfilling. I can just do the check for native ResizeObserver in my own code and use that if it exists. Is that the recommended approach here? Is there a good reason for me to always use the ponyfill? I'm guessing the performance of the native one would be better if I can use it. |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 1 reply
-
|
Hi! Performance of the native variant will be more performant, however, due to breaking changes of the spec, it's very difficult to return the correct matching native version. This is because it's not just the It's worth noting that if you're only using the Hope this helps! |
Beta Was this translation helpful? Give feedback.
-
|
Thanks, that does help! I think I only need And now I see this is all in the readme 🤦♂️ |
Beta Was this translation helpful? Give feedback.
Hi!
Performance of the native variant will be more performant, however, due to breaking changes of the spec, it's very difficult to return the correct matching native version. This is because it's not just the
ResizeObserverAPI that has changed - it's also theResizeObserverEntry. Adding this type of auto-detection would bloat the library, so I felt it best to leave it up the app logic.It's worth noting that if you're only using the
contentRectproperty of the entry, it's fine to do a simple check to see if the native variant is available and use it without any worry.Hope this helps!