0d5b46068d
* Simplify css for click animation
* Refactor to transfer responsibility for casting multiple synchronous to index.ts from machine.ts (so they can be dealt with in bulk)
* During synchronous application of a batch of events, move the mouse to the last position so that it's in the correct place when the timer starts
- previous `needCastInSyncMode` added in 4bf533a675 meant that the isSync versions of MouseMove/TouchMove were being accidentally ignored
- each synchronous MouseMove would have resulted in a separate mouse position update
- the Click/TouchStart/TouchEnd events didn't have an async version
* The desktop pointer cursor is not representative of what is happening on a mobile device.
Instead, check a recording for any presence of a Touch event, and switch to a touch visualisation mode for the entire recording.
(for now, we use this mode even for mixed touch/mouse devices - this could be improved upon in future)
Show a round circle representing the users' finger which is visible only between TouchStart and TouchEnd events
Again this can be evolved upon, but this change should be a good start in the right direction.
* It's more correct to not have a transition for repositioning of touch as user can lift finger off screen and place elsewhere; however we can now have much smoother touch movement during the .touch-active phase as we know the finger is on the screen. This has a .25s delaying effect on the touch position which IMO is acceptable; e.g. scroll position can lag behind a touch movement and this seems to bring them more in sync
* Ensure we end up with the correct touch-active state after a series of synchronous events
* Important to discontinue tail animations and position transitions when user has lifted their finger and placed it into a new position. This is apparent in a replay session where the user is scrolling the page using repeated TouchMove bottom-to-top movements
* Simplify by unwrapping `mouseState.touchActive` and `mouseState.pos` into their own global vars
rrweb
The new adventure of the rrweb community
I have joined Github Sponsors and highly appreciate your sponsorship.
rrweb refers to 'record and replay the web', which is a tool for recording and replaying users' interactions on the web.
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 a 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
- rrdom: an ad-hoc DOM for rrweb session data #419
- storage engine: do deduplication on a large number of rrweb sessions
- more end-to-end tests
- compact mutation data in common patterns
- provide plugins via the new plugin API, including:
- XHR plugin
- fetch plugin
- GraphQL plugin
- ...
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.
Core Team Members
Yuyz0112 |
Mark-Fenng |
eoghanmurray |
Juice10 |
Who's using rrweb
