@Yuyz0112 @eoghanmurray @Juice10 PTAL and make sure we are heading in the right direction.

@Mark-Fenng impressive work so far!
Personally I would try not to do the css parsing myself, its a lot of work and there are many edge cases to consider. I'd go for something like cssstyle it's used by jsdom which is quite widely used and already has a lot of edge cases worked out for you.

@Juice10 Agreed! I have tried cssstyle and it works well in the nodejs environment but I found some problems in the browser environment. So I have to remove it temporarily in the commit d2fadec.
Maybe If we can handle that compatible problems, cssstyle is the best choice for us?

@Mark-Fenng cool, happy to see you already went down that road!
Since rrdom is meant to be used both server side and client side as a virtual dom. I wonder if it makes sense only use cssom in the node environment, and let let the browser do the css parsing on the client side.
We might need to use document.createElement().style to get access to that on the client side, but as long as we don't attach those nodes to the Dom it should be a lot faster and a lot less error prone than using regular expressions (especially on large or complicated styles).

@Mark-Fenng Does the one rrweb-snapshot use helps?

@Yuyz0112 css doesn't support the mutual conversion between inline-style and cssText.

@Mark-Fenng can you tell me about the virtual parent optimization, where in the current codebase is it?

@eoghanmurray
The main code is here.
The mechanism is that during the seeking process, we remove some root elements(parent elements) from the DOM, and then mutation of their children will not cause reflow, which is relatively slow. After the seeking is finished, we put these root elements back to the DOM. In this way, number of reflows is significantly reduced so that we're able to accelerate the performance of the seeking process.

I think I have mostly completed the content of stage 1.
Now, we can run rrweb.Replayer on nodejs in this way:

import { Replayer } from 'rrweb';
const fs = require('fs');
require('rrdom');

var events = JSON.parse(
  fs.readFileSync(require.resolve('./events.json')).toString(),
); // Load rrweb events from a file.
var replayer = new Replayer(events, {
  showWarning: false,
});
replayer.play();
replayer.on('finish', () => {
  console.log("playback finished!");
});

I hope the current work could be merged into the master branch without being squashed.

Absolutely loving this @Mark-Fenng! I'm reading through your PR, review will come soon!

I noticed that packages/rrdom/src/document-nodejs.ts and packages/rrdom/src/document-browser.ts are 90% the same.
Would it be possible to have one inherit from the other so changes don't have to be made twice?

I noticed that packages/rrdom/src/document-nodejs.ts and packages/rrdom/src/document-browser.ts are 90% the same. Would it be possible to have one inherit from the other so changes don't have to be made twice?

@Juice10 Your concern is absolutely reasonable. I split two versions of rrdom because rrdom for nodejs is getting bigger and it's not suitable for running on browsers. document-browser.ts is built for virtual dom optimization in rrweb replayer and it's in an initial state so that it's maybe not a proper time to do de-duplication work now. How about avoiding merging it into the main branch until it's finished and in a good code style?