aab4c553cb
* docs: revamp installation docs for esm and umd Document recommended install paths across the main guides and package READMEs for rrweb, @rrweb/all, @rrweb/record, @rrweb/replay, and rrweb-player. Clarify three usage modes: bundler/npm, browser no-build with import maps and +esm, and legacy UMD fallback. * Apply suggestions from code review Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> * Apply formatting changes * Apply suggestion from @eoghanmurray Co-authored-by: Eoghan Murray <eoghan@getthere.ie> * Apply formatting changes * docs(all): streamline README usage section Move the guide link next to the import example and remove the duplicated Usage section to keep docs concise and easier to scan. * docs(readme): update gzip size badges in zh-cn readme * docs(plugins): update readme imports to scoped esm packages Replace `rrweb` default imports and `rrweb.Replayer` usage with `@rrweb/record` `record` and `@rrweb/replay` `Replayer` in plugin usage examples. Also update canvas WebRTC plugin imports to scoped `@rrweb/*` package names to keep docs aligned with current package structure. * docs: update docs to prefer scoped esm packages replace `rrweb` default import examples with `@rrweb/record` and `@rrweb/replay` across recipes and guides in en/zh-CN. clarify package selection for new integrations, add `@rrweb/all` convenience guidance, and refresh CDN/style import snippets for ESM and legacy UMD compatibility. --------- Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> Co-authored-by: Eoghan Murray <eoghan@getthere.ie>
47 lines
1.7 KiB
Markdown
47 lines
1.7 KiB
Markdown
# Real-time Replay (Live Mode）
|
||
|
||
If you want to replay the events in a real-time way, you can use the live mode API. This API is also useful for some real-time collaboration usage.
|
||
|
||
When you use `Replayer` for real-time replay, configure `liveMode: true` and call `startLive()` to enable live mode.
|
||
|
||
```js
|
||
import { Replayer } from '@rrweb/replay';
|
||
|
||
const replayer = new Replayer([], {
|
||
liveMode: true,
|
||
});
|
||
replayer.startLive();
|
||
```
|
||
|
||
Later when you receive new events (e.g. over websockets), you can add them using:
|
||
|
||
```
|
||
function onReceive(event) {
|
||
replayer.addEvent(event);
|
||
}
|
||
```
|
||
|
||
If you have an ongoing recording that already has events, and wish to initiate play from a 'live' time, it's also possible to use the `play` function, supplied with an offset which corresponds to the current time:
|
||
|
||
```js
|
||
import { Replayer } from '@rrweb/replay';
|
||
|
||
const replayer = new Replayer(EXISTING_EVENTS, {
|
||
liveMode: true,
|
||
});
|
||
replayer.play(Date.now() - EXISTING_EVENTS[0].timestamp);
|
||
```
|
||
|
||
When calling the `startLive` API, there is an optional parameter to set the baseline time. By default, this is `Date.now()` so that events are applied as soon as they come in, however this may cause your replay to appear laggy. Because data transportation needs time (such as the delay of the network), And some events have been throttled(such as mouse movements) which has a delay by default.
|
||
|
||
Here is how you introduce a buffer:
|
||
|
||
```js
|
||
const BUFFER_MS = 1000;
|
||
replayer.startLive(Date.now() - BUFFER_MS);
|
||
```
|
||
|
||
This will let the replay always delay 1 second than the source. If the time of data transportation is not longer than 1 second, the user will not feel laggy.
|
||
|
||
The same can be done for `play` as follows: `replayer.play((Date.now() - EXISTING_EVENTS[0].timestamp) - BUFFER_MS)`
|