Refactor to preclude the need for a continuous raf loop #1328
Conversation
🦋 Changeset detectedLatest commit: 23cd976 The changes in this PR will be included in the next version bump. This PR includes changesets to release 8 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
I've been running this change in production since early March |
|
Although I have it in production, so it's not obviously breaking things, there could be some subtleties with the shadowbuffer that might need expert analysis or a test... I wrote this based on the logic of how the weak map was cleared etc. |
eoghanmurray
force-pushed
the
shadowDomLoopOnDemand
branch
from
a86625d
to
6cb8335
Compare
|
@eoghanmurray very welcome change! This was creating a lot of noise when profiling the code 👏🏼 |
|
@JonasBa this is a hard one for anyone to review and we don't have tests on it. |
* Refactor to preclude the need for a continuous raf loop * Apply formatting changes * Create shadow-dom-unbusify.md --------- Co-authored-by: eoghanmurray <eoghanmurray@users.noreply.github.com>
* Refactor to preclude the need for a continuous raf loop * Apply formatting changes * Create shadow-dom-unbusify.md --------- Co-authored-by: eoghanmurray <eoghanmurray@users.noreply.github.com>
* Refactor to preclude the need for a continuous raf loop * Apply formatting changes * Create shadow-dom-unbusify.md --------- Co-authored-by: eoghanmurray <eoghanmurray@users.noreply.github.com>
It seems to me that the raf loop is unnecessary, so I've removed it to get your feedback.
Instead we queue up a single raf callback which will clear anything added in this frame.
I've no understanding as to why this exclusivity is per animation frame, and not (say) per emitted mutation event, any insight into that?