sindresorhus

element-ready

Detect when an element is ready in the DOM

by sindresorhus

JavaScript

JavaScript95.8%
TypeScript4.2%

Commit activity

Last 12 weeks · 0 commits

Full graph →

Community health

4 of 6 standards met

Community profile →
71
✓README✓License✓Contributing✓Code of Conduct○Issue Template○PR Template

Recent PRs & issues

Quiet · 1 in progress · Last activity 4mo ago
See all on GitHub →
fregante

This might be a niche request, but "element ready" might be useful even without querying a selector: Is _this_ element/node that I _already_ have ready? The shape of this function depends on a few open issues in order for it to be self-contained: https://github.com/sindresorhus/element-ready/issues/68 https://github.com/sindresorhus/element-ready/issues/67 https://github.com/sindresorhus/element-ready/issues/64 Signature, either:

fregante · 4mo ago
sindresorhus

Snapshot ancestor siblings per matched element and track child mutations. Treat a next sibling as a parsing signal only if it existed at match time, unless the element is reparented or its children change; then allow later ancestor siblings. Apply the same stateful check to observeReadyElements. Fixes #64 This was the absolute simplest I was able to come up with the help of AI. Not sure it's worth the complexity...

sindresorhus · 8mo ago
fregante

Context: https://github.com/sindresorhus/element-ready/issues/62#issuecomment-3798835723 I think that the current logic () is the best we got, but I wish we could find a better heuristic, maybe something based on mutation sequence. For example: e.g. no mutations in but a new _any-parent_ sibling appeared _while waiting_ specifically avoided MutationObserver in favor of polling to improve performance and reduce complexity, so I'm not sure if this is worth it. However conflicts with extensions and other third party scripts (e.g. script appends advertisement frame to ) are still a real issue.

fregante · 8mo ago
fregante

https://github.com/sindresorhus/element-ready/blob/28f2ec4265666cdcc2c5fb34b5bd1811708f2efd/index.js#L46-L49 Due to this condition, the loop (including ) will continue as if the element was never matched. This would improve performance. I think that it should instead just loop until the children are ready. Perhaps this condition should just be a nested loop, e.g. However I think this kinda prompts a review/merge of the / options: https://github.com/sindresorhus/element-ready/issues/67

fregante · 4mo ago
Richienb

Useful for running automations. 1. Do some action 2. Wait for element to no longer exist (for example, a dialog/dropdown closing) 3. Continue

Richienb · 8mo ago
Structured data for AI agents

Repository: sindresorhus/element-ready. Description: Detect when an element is ready in the DOM Stars: 448, Forks: 16. Primary language: JavaScript. Languages: JavaScript (95.8%), TypeScript (4.2%). License: MIT. Latest release: v9.0.2 (9mo ago). Open PRs: 1, open issues: 4. Last activity: 4mo ago. Community health: 71%. Top contributors: sindresorhus, fregante, Richienb, BendingBender, bfred-it, riophae, cheap-glitch, reyronald, soenkekluth.