-
Notifications
You must be signed in to change notification settings - Fork 43
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
Allow the observed node to be specified and the selector scan search pattern to be configured. #19
Conversation
Support scanning of only addedNodes in the mutation instead of scanning the entire document for matching selectors.
This is for #17 |
Maybe it'd be better idea to add option like
|
Edit: Warning: This is superseded by #21. Hi @pie6k, yes, we could probably improve performance by passing in a root node to observe. However, I think this solution is valid also. They solve two different separate performance issues: 1) What object to observe for mutations, and 2) Where to scan for selectors when a mutation is observed. This change solves the latter by making it possible to only scan the added nodes in the mutation (instead of the entire document.) This pull request allows, for example:
With this change, if If we wanted to implement your suggestion alongside this, we could improve this even further. For example:
Differences are in bold. So, there is potential to improve two things: 1) which element mutations are observed on, and 2) how to match selectors when the mutation event is captured. I will see if I can improve this pull request further to make both features possible. |
jquery.initialize.js
Outdated
// For each mutation. | ||
for (var m = 0; m < mutations.length; m++) { | ||
// If mutation type is observed. | ||
if ($.inArray(mutations[m].type, mtypes) != -1) { |
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.
For such code I'd consider negative if
's eg
if (!$.inArray(mutations[m].type, mtypes) != -1) {
continue;
}
// rest of the code. HEY! we caved some tabs in indent!
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 will update accordingly as I implement your other concerns.
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.
Don't forget to add yourself to contributors as well as some note in the README
I might also need to rename the |
So,
|
Oops, not entirely correct. If the mutation is an |
I have updated the pull request to allow the "root node" to be specified and will now test it in my company's application, to see how it affects performance. Then, I might consider renaming the options after that. See also, test2.html. |
Edit: Warning: This is superseded by #21. @pie6k I have this working now and is ready for testing. I had to use JavaScript that may break older browsers (that is, Array.forEach(), Element.querySelectorAll() and Element.matches()) There options are now:
Explanation of the different scan modes are:
This should provide a large degree of control to the developer. Unfortunately, the best way to understand these scanModes is by using them. See the example in |
After you are happy with this, I can document it in the README before merging. |
Seems good. I think it'd be good to provide links to proper demos in README |
Did you want to host the demo somewhere? GitHub Pages maybe? |
Yup, I think GH is totally fine. Thanks for your help @dbezborodovrp |
I opened a separate issue for documentation, #20. |
Cool, merged 🎉 |
Cool. I think I could have actually simplified this. I might open a second PR if you can hold off tagging a new version number. |
See #21 for simplification of this feature. |
Support scanning of only addedNodes in the mutation instead of scanning the entire document for matching selectors.