Summary

rrweb currently doesn't have a preferred way of dealing with events that take a while to process before they are fully captured. Let's discuss strategies to deal with these types of events.

Reasons

Handling async commands

Some commands are only available async so we have to wait till they are complete before we're able to save the event.

Keeping event order

In some cases event order is important.
Example of two events happening within the timespan of one second:

1. SLOW EVENT: adds element A (capture takes 10 seconds to complete)
2. FAST EVENT: does something with element A (takes 1ms to complete)
   If we were to emit these events when they are completed processing they'll be saved out of order, breaking the replay.

Real world use cases

Performance / web workers

Some heavy synchronous tasks we do (e.g. canvas.toDataURL, JSON.stringify base64 encoding) cause jank. Moving this to a web worker would mean having a wait longer for the results but a much smoother user experience during recording.

Image inlining

When using fetch to request images to inline we have to wait for the request to complete. Most of the time this will be pretty fast as the browser probably still has the image in cache, but this is an async operation.
More info: #836 (comment)

Stylesheet inlining

Some stylesheets take a while to load and currently their contents get missed from the inline script: #764

Canvas mutation serialization

Serializing some arguments of canvas calls is only available async. Examples: Blob#arrayBuffer() Canvas#toBlob()
With canvas recording order is incredibly important, if two events get recorded out of order the whole recording would (silently) break yielding an empty canvas (which is a PITA to debug).