xuguopeng/rrweb
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

CI: add a prettier GitHub action to format code automatically (#988)

Browse Source 
* CI: add a prettier GitHub action to format code automatically

* improve GitHub Action config and format some files

* Apply formatting changes

* CI: make the prettier action a standalone action

* Apply formatting changes

* CI: add push as new trigger event

Co-authored-by: Mark-Fenng <Mark-Fenng@users.noreply.github.com>
This commit is contained in:
Yun Feng
2026-04-01 12:00:00 +08:00
committed by GitHub
parent c94b5783c4
commit f878cc032d
22 changed files with 109 additions and 54 deletions
Download Patch File Download Diff File Expand all files Collapse all files

5
docs/replay.md
View File

@@ -1,7 +1,9 @@
# Replay
A design principle of rrweb is to process as little as possible on the recording side, minimizing the impact on the recorded page. This means we need to do some special processing on the replay side.
## High precision timer
During replay, we will get the complete snapshot chain at one time. If all the snapshots are executed in sequence, we can directly get the last state of the recorded page, but what we need is to synchronously initialize the first full snapshot, and then apply the remaining incremental snapshots asynchronously. Using a time interval we replay each incremental snapshot one after the other, which requires a high-precision timer.
The reason why **high precision** is emphasized is because the native `setTimeout` does not guarantee accurate execution after the set delay time, for example, when the main thread is blocked.
@@ -11,6 +13,7 @@ For our replay function, this imprecise delay is unacceptable and can lead to va
At the same time, the custom timer is also the basis for our "fast forward" function.
## Completing missing nodes
The delay serialization strategy when rrweb uses MutationObserver is mentioned in the [incremental snapshot design](./observer.md), which may result in the following scenarios where we cannot record a full incremental snapshot:
```
@@ -29,6 +32,7 @@ During replay, when we process the incremental snapshot of the new `foo`, we kno
After processing the incremental snapshot of the new n1, we normally process and insert `bar`. After the replay is completed, we check whether the neighbor node id of `foo` points to a node which is in the missing node pool. If it matches, then it will be removed from the pool and be inserted into the DOM tree.
## Simulation Hover
CSS styles for the `:hover` selector are present in many web pages, but we can't trigger the hover state via JavaScript. So when playing back we need to simulate the hover state to make the style display correctly.
The specific method includes two parts:
@@ -37,6 +41,7 @@ The specific method includes two parts:
2. When playing back the mouse up mouse interaction event, add the `.:hover` class name to the event target and all its ancestors, and remove it when the mouse moves away again.
## Play from any point in time
In addition to the basic replay features, we also want players like `rrweb-player` to provide similar functionality to video players, such as dragging and dropping to the progress bar to any point in time.
In actual implementation, we pass a start time to the method. We can then divide the snapshot chain into two parts: The parts before and the part after the start time. Then, the snapshot chain before the start time is executed synchronously, and then the snapshot chain after the starting times uses the normal asynchronous execution. This way we can achieve starting replay from any point in time.