[WIP] feat(replay): Add experimental dropRepetitiveMutations#15438
[WIP] feat(replay): Add experimental dropRepetitiveMutations#15438
dropRepetitiveMutations#15438Conversation
|
I'm wondering if we move this logic to be after rrweb processing (e.g. when we add to our event buffer). A [potentially big] downside is that we will always process the mutation w/ rrweb. I don't remember what the mutation records that the onMutation handler looks like (iirc they are just entries from MutationObserver), but will it be able to handle the case where we have the same set of dom elements that get removed and then readded? A benefit of moving is that it'd be easier to test and verify changes -- we have example replays of different causes of infinite mutations to build against and we can use existing "normal" replays as inputs to our function to check correctness. Maybe it's even possible to translate between the two (pre and post). WDYT? |
I think for this we would need to update the fingerprint logic in the pr to check on the removed and added nodes.
The testing aspect is def a big upside I would say. But yeah we would still run every mutation through the processing pipeline. Can you point me to some of the example replays, I would need to check how to convert them into tests |
Yeah i'll work on finding new examples as the ones I had are out of retention now. |
|
Can we close this PR or is it still relevant? (just asking as part of a PR cleanup attempt :) ) |
Adds a new experimental flag
dropRepetitiveMutationsto the replay integration options.When enabled:
ref #11517