-
Notifications
You must be signed in to change notification settings - Fork 4.1k
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
Framework: Add wp-polyfill as central polyfill #9794
Conversation
@@ -99,66 +99,84 @@ function gutenberg_register_scripts_and_styles() { | |||
|
|||
register_tinymce_scripts(); | |||
|
|||
wp_register_script( | |||
'wp-polyfill', | |||
null, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In one of my plugins, I was using this technique but I recall it was creating an issue for the script loading order. I can't reproduce thought here but thought I'd mention.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, okay, it's good to note. I've not encountered an issue like that which you describe. I did find that wp_add_inline_script
doesn't work with the null
$src
, which is why I've opted for the equivalent wp_script_add_data
below.
array( | ||
'\'fetch\' in window' => 'wp-polyfill-fetch', | ||
'document.contains' => 'wp-polyfill-node-contains', | ||
'window.FormData && window.FormData.prototype.keys' => 'wp-polyfill-formdata', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Weren't you planning to add element closest or are you leaving this for a separate PR?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Weren't you planning to add element closest or are you leaving this for a separate PR?
If we can review and merge #9750 before this one, I can rebase and add it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems like the opposite is simpler right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM 👍
Testing on IE 11, here's what I see: first one I guess IE 11 doesn't know what Not sure about the error related to |
@aduth thanks will check. Note: I've also seen |
In my testing after rebasing with the included #9795 fix, everything here works as expected in IE11. |
Yup I don't see the error related to |
Related (will require changes to): #9750
This pull request seeks to refactor our polyfills, introducing a new central
wp-polyfill
handle which includes polyfills for both JavaScript language features (Promise
, etc) and modern browser features (currentlywindow.fetch
,Node#contains
,FormData
, soonElement#closest
).Implementation notes:
It does not remove or deprecate
wp-polyfill-ecmascript
, but rather acts as a superset, where the intended contract of "ecmascript" would be for language features, regardless of whether the underlyingbabel-polyfill
/core-js
provides browser polyfills.Testing instructions:
Verify there are no regressions in the behavior of polyfills, particularly in Internet Explorer 11.
Note that there is currently a separate issue with saving in IE11, not addressed here.