[Proposal] Abstruct DOM level API

[malash]

What

Frameworks like Taro Next and kbone provide the DOM like API to support higher framework. Taro Next call it taro-runtime and kbone exports the API as part of window.document.
In Goji 0.5 the ElementInstance and TextInstance do the same things but somehow coupling with the container.

Why

Multi framework support

By using DOM like API Taro Next support not only React but also VUE. Because there is no need to care about how DOM rendered into view thead in each framework. The DOM API could handle diff logics, event binding, event propagation, blocking mode, setData performance analyzing and etc.

Easier to implement diff generation

For example, we'd like to implement blocking mode, which means block/batch the sequence set data call in a period of time, in the container level. But the most suitable placec is the DOM API. Here is the demo:

document.beginBlockMode();
// change DOM here
document.flushBlockMode();

Code decoupling and easier to test

After more than half-year developing Goji code base became larger and more complex. The current testing progress is render React component => check setData result in TestingAdaptor.

Advanced: Copy-on-write, snapshots and diff

I'll create another issue for this feature.

How

DOM API

Refer to taro-runtime, JSDOM, kbone or MDN DOM and I think it could be acceptable if some APIs are not standard.

We can reuse current ElementInstance and TextInstance ot implement the new DOM API.

Functional design

Some features like pure ( setData generation ) / adaptor calling / blocking mode should be moved into DOM level API. By doing this we can test DOM and TestingAdaptor wihtout React requirement.

And to make code more clear and easy understanding we can publish a new package for this abstruction like @goji/dom.