-
-
Save jwilson8767/db379026efcbd932f64382db4b02853e to your computer and use it in GitHub Desktop.
// MIT Licensed | |
// Author: jwilson8767 | |
/** | |
* Waits for an element satisfying selector to exist, then resolves promise with the element. | |
* Useful for resolving race conditions. | |
* | |
* @param selector | |
* @returns {Promise} | |
*/ | |
export function elementReady(selector) { | |
return new Promise((resolve, reject) => { | |
let el = document.querySelector(selector); | |
if (el) { | |
resolve(el); | |
return | |
} | |
new MutationObserver((mutationRecords, observer) => { | |
// Query for elements matching the specified selector | |
Array.from(document.querySelectorAll(selector)).forEach((element) => { | |
resolve(element); | |
//Once we have resolved we don't need the observer anymore. | |
observer.disconnect(); | |
}); | |
}) | |
.observe(document.documentElement, { | |
childList: true, | |
subtree: true | |
}); | |
}); | |
} |
import { elementReady } from "es6-element-ready"; | |
// Simple usage to delete an element if/when it exists: | |
elementReady('#someWidget').then((someWidget)=>{someWidget.remove();}); |
@acropup, an alternative solution is to match on the unique ID only, and not use selectors. This would be intuitive, since the promise resolves after the first match is found.
However, if there was a way to reliably tokenise a selector, it could be found through introspection what kind combinators are present and adjust the match/query algorithm accordingly. There is a css-selector-tokenizer
package, but that seems overkill for something that should be easily achievable.
section:has(div > strong)
example using closest()
. Adjacent and sibling combinators can also be implemented, but the important aspect in terms of performance is having a tokeniser to introspect and recognise which algorithm to pick based on the complexity of the selector. Although even without that, this should represent a substantial improvement.
const element = (addedNode.matches(selector) && addedNode)
|| addedNode.querySelector(selector)
|| addedNode.closest(selector);
ok boo
Yes, what @bezborodow is recommending is that instead of doing a
document.querySelectorAll(selector)
on line 20, it is more efficient to only try to match on the added notes in themutationRecords
parameters (ex. check ifmutationRecords[0].addedNodes[0].matches(selector)
, and repeat for allmutationRecords
andaddedNodes
).Even if performance is better, I don't think this strategy works in all cases. One reason: adding a node such as
<div>This div has <strong>children</strong></div>
will put the outer div into theaddedNodes
list, but none of its children will be inaddedNodes
. So, matching on'div > strong'
would not succeed. You could instead doaddedNode.querySelectorAll(selector)
for all added nodes, but there are other CSS selectors for which this is insufficient. One example that comes to mind is'#parentElem:has(div > strong)'
. Even if adding the nodes would cause a valid match, #parentElem is never part ofaddedNodes
, because that particular node was never added. I believe using + and ~ in selectors is similarly problematic.tl;dr Referring to
addedNodes
might be more performant, but it can fail to match in some scenarios. document.querySelectorAll might be inefficient, but it is always correct.