* Sort events at start, as otherwise we risk misidentifying the last event
* Keep inserted events in the correct order, ensuring we don't misidentify the last event
- e.g. network conditions mean that 'live' events come in non-sequentially
- or so that adding custom events to an existing event works
* Ensure we maintain original ordering while inserting a new event which has an identical timestamp to an existing event. This came up with a series of mutations which had the same timestamp but needed to be applied in the correct order
* Fast track the common case of a new event being added which occurs after all prior events
* wip: working on rrweb logger
* wip: can record and replay some simple log
* wip: can record and replay log's stack
* wip: try to serialize object
* wip: record and replay console logger
hijack all of the console functions.
add listener to thrown errors
* wip: record and replay console logger
add limit to the max number of log records
* feat: enable rrweb to record and replay log messages in console
this is the implementation of new feature request(issue #234)
here are a few points of description.
1. users need to set recordLog option in rrweb.record's parameter to record log messages. The log recorder is off by default.
2. support recording and replaying all kinds of console functions. But the reliability of them should be tested more
3. the stringify function in stringify.ts needs improvement. e.g. robustness, handler for cyclical structures and better support for more kinds of object
4. we can replay the log messages in a simulated html console like LogRocket by implementing the interface "ReplayLogger" in the future
* improve: the stringify function
1. handle cyclical structures
2. add stringify option to limit the length of result
3. handle function type
* refactor: simplify the type definition of ReplayLogger
- What was broken was that it would just play activity from the first page view, but then would stop at the second page view (meta) as actions after that had been discarded
- This restores the functionality given by the comment 'return the events from last meta to the end.' - we never want to discard events that are after the baseline time
- I believe 'session' is the incorrect terminology for this function name, as a session in web analytics usually means a series of page views
related to #6
Since the currently 'play at any time offset' implementation is pretty simple,
there are many things we can do to optimize its performance.
In this patch, we do the following optimizations:
1. Ignore some of the events during fast forward.
For example, when we are going to fast forward to 10 minutes later,
we do not need to perform mouse movement events during this period.
2. Use a fragment element as the 'virtual parent node'.
So newly added DOM nodes will be appended to this fragment node,
and finally being appended into the document as a batch operation.
These changes reduce a lot of time which was spent on reflow/repaint previously.
I've seen a 10 times performance improvement within these approaches.
And there are still some things we can do better but not in this patch.
1. We can build a virtual DOM tree to store the mutations of DOM.
This will minimize the number of DOM operations.
2. Another thing that may help UX is to make the fast forward process async and cancellable.
This may make the drag and drop interactions in the player's UI looks smooth.
On recordings with many full pageloads, dom state and mutations were being applied only to be discarded when a new pageload came in, resulting in very slow time to rebuild - and inability to interactively 'scrub' through these recordings
* refactoring play, pause, resume, load style sheet to subscribe style code
* support live mode in state machine
* 1. upgrade @xstate/fsm
2. add toggle interact methods to the player
