Standardize support for non-attribute properties in protocol about rrweb HOT 5 CLOSED

Just read the description and the commits about media support, it looks nice. I Still need some time to think about this carefully, but the following points may be considered as a design principle:

1. It will be nice if the data structure is similar to the node's original data interface, so the serializer will be more transparent to the developer.
2. It is important to have a data structure with less overhead, I know there is a trade-off about namespace or abstraction, but still need to be careful here.

Currently, the special cases you've mentioned are following these rules, like only add a flag when it really needs, or re-use the attributes object to store some internal attributes. However, there are absolutely some spaces to improve, but if there is a breaking change, we need to do that ASAP before someone use rrweb in production heavily:)

from rrweb.

How about using a properties key to store these states?

from rrweb.

A properties key would be similar to the mediaState object I used, reusable for properties from all types of DOM objects. I think keeping it typed would be nice to have.

However, I'm not entirely sure that provides the extensibility I meant. A bit like the width and height: While storing them as strings in custom-named attributes works, it feels like a bit of a hack. So, I meant, if we're going to add new arbitrary, typed, possible composit values in the future, what is the preferred way to store them? A properties key only addresses DOM object properties.

I think "we add new keys" is a acceptable answer to that question. But I want to make sure that we agree that is the way to do it, since in the README you mentioned wanting to have a stable data structure for v1.0, and it also implies we'll from now on have to deal with new/missing keys for compatibility between different versions and cannot make any of these keys required in the typedef.

from rrweb.

@DvdGiessen Yes I agree with this and now you can add new keys without considering about compatibility.

cannot make any of these keys required in the typedef

This will be true after v1.0 is released.

from rrweb.

Alright, I'll update and my media branch to include this.

from rrweb.