Skip to content
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

Ponyfill #26

Open
andershansander opened this issue Aug 7, 2019 · 5 comments
Open

Ponyfill #26

andershansander opened this issue Aug 7, 2019 · 5 comments

Comments

@andershansander
Copy link

I am not sure about this but I think that since the index.ts file call the install function immediately, then window.ResizeObserver will always be overwritten, and that that should be avoided by ponyfills.

Feel free to close this if I have misunderstood your code or what ponyfill means. 🙂

@devrelm
Copy link
Owner

devrelm commented Oct 2, 2019

You're right about the index.ts, but the package.json defines lib/ResizeObserver.js (the compiled ResizeObserver.ts) as the main entrypoint:

https://github.com/pelotoncycle/resize-observer/blob/64efdf34dc577286fccb22a531b1b171e902b739/package.json#L5

So importing resize-observer as a module will load it as a ponyfill as described in the readme.

Alternatively, you can load resize-observer as a polyfill by loading dist/resize-observer.js directly in a script tag.

As-is, the only way to accidentally load resize-observer as a polyfill would be to import the index.js file directly by one of the following:

import 'resize-observer/lib';

// or:

import 'resize-observer/lib/index';

At that point, I'd almost like to rename it and call it a feature. We could move/build index.ts to polyfill/index.js so that import 'resize-observer/polyfill' installs resize-observer as a polyfill. Then users don't have to deal with adding another <script> tag to their html.

In fact, that really sounds like something that should be done. I'm going to keep this issue open to track that.

@andershansander
Copy link
Author

Oh, I see. I missed that. Sorry for reporting on a non-existing issue.

@sag1v
Copy link

sag1v commented Aug 18, 2022

@devrelm This means that if the browser already support ResizeObserver we will use the native?

@devrelm
Copy link
Owner

devrelm commented Aug 19, 2022

@sag1v

No. When you use resize-observer you will always get this package's implementation. This package does no checks for a native implementation.

The reason for this is that no matter how hard we try to keep this package in line with the ResizeObserver spec, we have seen some differences pop up here and there. To keep from having strange behavior pop up on some browsers but not others, we decided it would be better to have resize-observer always use its own version.

@sag1v
Copy link

sag1v commented Aug 19, 2022

Thanks @devrelm 🙏
In our case (a shared library) we want to use the native RO and use a ponyfill/pollyfill in test environment (because jest doesn't support it)

So i wanted to understand if the logic of conditionally using the native already done or should we write it ourselves. I understand that the latter is the case 🙂

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants