-
Notifications
You must be signed in to change notification settings - Fork 20.5k
Selector: Inline Sizzle into the selector module #4395
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
Conversation
dmethvin
left a comment
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.
👏 👏 👏
I like the progressive commits and the approach seems good, I'll leave approval to the Sizzleers!
|
This looks like it's on the right track. I'd like to see it with the tests migrated. |
|
I submitted a draft PR porting Sizzle tests in #4406. I'll be adding more commits to it but it might be easier for you to review commit by commit even now instead of all at once when I'm done. |
|
@jquery/core During my work on #4406, I've reminded myself we support many more custom selectors than just the ones listed in the 3.4.0 blog post as deprecated. We listed:
What do we plan to do with those selectors? Do we want to implement internal replacement (where possible, |
|
Some of this can be handled by Migrate, or at least the easy cases of them. I wonder if we want any of custom selectors in 4.0 or should just have new custom methods by similar names where needed? It would be useful to have very clear instructions on how to convert from old to new, even if it means making new core methods to simplify things. So |
(porting some info from the Gitter discussion) We still need to maintain our own custom parsing just to reliably apply the ID hack to have a correct scoping mechanism. When we have parsing, adding some re-mapping may not be that hard in many of those cases (like |
|
Porting a little more from the Gitter conversation, |
|
As far as this PR is concerned, I think it's good to go as a first step. |
|
Also, if not already, ensure all entries in AUTHORS.txt are present in the jQuery one. |
@Krinkle Good point. I'll need to sort them into the jQuery list based on comparing their first contribution to Sizzle with other first contributions to jQuery, I guess. |
|
OK, I think this is ready to review. I removed the draft status. |
|
@Krinkle |
This commit removes Sizzle from jQuery, inlining its code & removing obsolete workarounds where applicable. The selector-native module has been removed. Further work on the selector module may decrease the size enough that it will no longer be necessary. If it turns out it's still useful, we'll reinstate it but the code will look different anyway as we'll want to share as much code as possible with the existing selector module. The Sizzle AUTHORS.txt file has been merged with the jQuery one - people are sorted by their first contributions to either of the two repositories. The commit reduces the gzipped jQuery size by 1469 bytes compared to master.
This commit removes Sizzle from jQuery, inlining its code & removing obsolete workarounds where applicable. The selector-native module has been removed. Further work on the selector module may decrease the size enough that it will no longer be necessary. If it turns out it's still useful, we'll reinstate it but the code will look different anyway as we'll want to share as much code as possible with the existing selector module. The Sizzle AUTHORS.txt file has been merged with the jQuery one - people are sorted by their first contributions to either of the two repositories. The commit reduces the gzipped jQuery size by 1460 bytes compared to master. Closes gh-4395
Due to a faulty IE 8 workaround removal, the fast path qSA mode was skipped when jQuery's find was called on an element node - i.e. in most cases. 😱 Ref jquerygh-4395
Summary
This PR removes Sizzle from jQuery. The first commit inlines Sizzle mostly as-is, the subsequent commit fixes ESLint violations; later commits mostly remove workarounds for old browsers.
Currently the PR reduces the gzipped jQuery size by
1201bytes compared tomaster.I'm opening it as a draft as I still need to backport Sizzle tests. It's ready for initial review, though (reviewing by commit might be easier).
I've checked that all the tests pass in Chrome 74 & IE 11. All Sizzle tests are also passing for
jQuery.findexcept for theSizzle.noConflictone - butjQuery.findhas always strippednoConflictout of its internal Sizzle version.Checklist
If needed, a docs issue/PR was created at https://github.com/jquery/api.jquery.com