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

makes jQuery work without public buildFragment and overwritable domManip #2177

Merged
merged 29 commits into from
Jan 21, 2016

Conversation

justinbmeyer
Copy link
Contributor

Closes #2176

This makes jQuery 1.12 and 2.2 work.

@justinbmeyer justinbmeyer added this to the 2.3.9 milestone Jan 9, 2016
@daffl daffl modified the milestones: 2.3.10, 2.3.9 Jan 11, 2016
@mjstahl
Copy link
Contributor

mjstahl commented Jan 13, 2016

fixed merge conflicts.

@rjgotten
Copy link

@justinbmeyer

Why not keep your old buildFragment logic and feature-detect the existence of the jQuery.parseHTML( data [, context ] [, keepScripts ] ) method, which is part of the stable public API?

The parseHTML method does everything $.buildFragment did, but it flushes the contents of the document fragment that it internally uses with $.buildFragment into a plain array of DOM nodes and returns that to the caller. (Note: DOM nodes; not elements, so it still contains text nodes, comment nodes, etc. as well.)

Since you were cloning the cached fragment into a fresh fragment anyway, all you need to do with that array of nodes handed to you by $.parseHTML, is to pour it into a new empty document fragment of your own creation.

@justinbmeyer
Copy link
Contributor Author

@rjgotten I thought about that, but knew I had the buildFragment that worked everywhere else. Also, I wanted to avoid another "convert to a fragment" step. Meaning, that yes, we were creating a fresh fragment (via DOM clone method), but my thought that .clone() would be much faster than having parseHTML break the DOM into an array, and then us re-assemble it into another fragment. clone() presumably doesn't have to keep updating .nextSibling references.

We can maybe check if the performance is about the same.

@justinbmeyer
Copy link
Contributor Author

@mjstahl what did you change when you fixed the merge conflicts? It seems things are breaking now. Is there a merge commit?

Also, I noticed the view/stache/test/system/test.html file looks different than the standard test.html file. Where did you get that structure from? steal-qunit should be imported, not loaded via script tags.

@justinbmeyer
Copy link
Contributor Author

@mjstahl this is what I see when I open that page.

localhost_8080_canjs_view_stache_test_system_test_html

@justinbmeyer
Copy link
Contributor Author

Ah, it seems that wasn't intended to be opened as a standalone test page. I'm going to rename it.

@mjstahl
Copy link
Contributor

mjstahl commented Jan 14, 2016

@justinbmeyer AllI did was resolve the merge conflicts with package.json and bower.json

@daffl daffl modified the milestones: 2.3.11, 2.3.10 Jan 15, 2016
daffl added a commit that referenced this pull request Jan 21, 2016
makes jQuery work without public buildFragment and overwritable domManip
@daffl daffl merged commit c41c229 into master Jan 21, 2016
@daffl daffl deleted the 2176-jquery-22 branch January 21, 2016 23:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants