43be602816
There are some long-term issues in rrweb's mutation observer. A scenario cause problem: A list of DOM node: n1, n2, n3, n4, n5 Steps of modifying the nodes: 1. remove n1, n2, n3, n4 sequentially 2. append n4, n3, n2, n1 after n5 sequentially Then we got the added node data like this: (id: n4, prev: null, next: n3 ) (id: n3, prev: n4, next: n2 ) (id: n2, prev: n3, next: n1 ) (id: n1, prev: n2, next: null) The problem comes when we try to replay the first add node datum. Since its prev node is null, we rely on its next sibling n3. But n3 was not present at this moment, and in previous code, we fallback to append n4 to the last of its parent node. The solution is to defer the append of elements that missing siblings. But it is also hard to tell which node is the first one that needs to be appended. Take a step back and rethink the design of the mutation observer, we've found there are two implementations make things complicated. 1. We set the id to -1 when we seeing some nodes are not serialized yet. 2. We record both previous sibling and next sibling to determine the position of the node. But we can do better! First, we can put nodes with un-serialized siblings to a queue, and try to add it again later. Then we can just record the next sibling as 'the single truth' so we can be sure which node is the last one of its parent. This patch has implemented the new observer strategy. Data recorded with the new observer should no longer have any node with id -1. But for compatibility consideration, we still keep some replayer code that helps solve legacy data.
rrweb
rrweb refers to 'record and replay the web', which is a tool for recording and replaying users' interactions on the web.
Currently, rrweb has already solved many difficult problems in recording and replaying, but the data structure may still be changed before the release of Version 1.0. So please be cautious to use rrweb in the production environment.
Guide
📚 Read the rrweb guide here. 📚
Project Structure
rrweb is mainly composed of 3 parts:
- rrweb-snapshot, including both snapshot and rebuilding features. The snapshot is used to convert the DOM and its state into a serializable data structure with an unique identifier; the rebuilding feature is to rebuild the snapshot into corresponding DOM.
- rrweb, including two functions, record and replay. The record function is used to record all the mutations in the DOM; the replay is to replay the recorded mutations one by one according to the corresponding timestamp.
- rrweb-player, is a player UI for rrweb, providing GUI-based functions like pause, fast-forward, drag and drop to play at any time.
Roadmap
- rrweb
- handle cross-domain request errors
- record in web worker
- implement transmission data compression
- verify recording in mobile browser
- rrweb-player
- implement efficient progress bar drag and drop control
- add full screen mode
- extensions
- hijack the console API and record corresponding events
- hijack Ajax/fetch API and record request events
- use TraceKit to log exception events
Internal Design
Contribute Guide
Since we want the record and replay sides to share a strongly typed data structure, rrweb is developed with typescript which provides stronger type support.
- Fork the rrweb component repository you want to patch.
- Run
npm installto install required dependencies. - Patch the code and pass all the tests.
- Push the code and create a pull request.
In addition to adding integration tests and unit tests, rrweb also provides a REPL testing tool.
Who's using rrweb
