[w3ctag/design-reviews] DOM merging engine/API (Discussion #882)

Whether it is a lit generated DOM, React virtual DOM or any other templating engine, the intent is to materialize the template as web page DOM. Any templating would need a mechanism not just to inject the (generated HTML | detached DOM | own custom DOM) reflection  into a web page, but to fuse the existing DOM with an updated one.

There are multiple reasons for merging instead of replacing. just a few as sample:
* the need to keep stateful components intact. Whether those are input fields with typed text or custom elements with associated processes in the flight, replacing them with new instances even in the same place would break the functionality.
* avoid the focus jumping
* prevent the screen reader re-reading the unchanged  content
* preserve selection 
* performance impact like simple memory consumption and re-render speed
* you name it 👅 

The shared library which would do the merge efficiently is not a trivial task. The lib which would have a matched native plugin even more. And ideally the API reference implementation which would be implemented on platforms as a standard, keeping the lib and plugin as polyfill. 

Now what is **AC** for such lib?

# input DOM presentation abstraction
While the template render result can be presented in multiple ways, API would give the abstraction layer to fit the need of passing the parts to merge API. I.e. along with `input data`, provide the `traversing interface` implementation.

Let's think of various most popular presentations
## string template
while the string is a solid object, to be fed to the merge engine, it has to be parsed first. The parser itself can produce the ready to consume detached DOM sub-tree as soon as tag close occurs. I.e. the source string has to be coupled with a streaming-enabled parser.
## detached DOM
Similarly to parser, the DOM traversal mechanism can initiate the DOM sub-tree merging 
## POJO
The plain JS object structure should be traversable in similar to detached DOM fashion. 
## virtual DOM
Ideally can be identical to to detached DOM

# immutability of input data
While the input data would be incrementally growing, only appending of data into not-yet passed to merging sub-tree are permitted.

Q. _Can this be enforced somehow?_

# streaming input 
the generated DOM parts can become available independently and asynchronously. Merge API would need to accept the stream of entities which represent the template results DOM and start the merging process immediately with `async` style completion( via Promise? ).
# async & interruptible API
the result of merging is a stream of async calls which
# continue merging
during the page render or even on server side, the rules of hydration can interrupt, cancel or re-start the particular DOM subtree merge. The owner of the merge process would need to be able to initiate, pause/continue, or break the merging on own discretion. The hydration API/events would be dictating the "suggested" behavior.

# complexity and progress
As template rendering and merging potentially can be a long lasting process, the ability to see the progress can be a usability requirement.

On another side , this is one of the criteria of page performance which can be a subject for analytics and numbers for CI/CD checks.

The template render also would need the same API.  As the template engine works with data and template, it is capable along with template to produce the complimentary data embedded into the input tree to track the progress and complexity of passed branches.

For example, in the string presentation, the complexity would be proportional to the HTML string length and chunk position in the string. 
# multithreading
While the multithreading is not something JS friendly, especially accounting the need to manipulate the live DOM, the part of the process can be counted as "safe": the DOM comparison does not engage the change and can be performed in own thread without the need for synchronization. The native implementation in the plugin, of course, can leverage the threads pool without limit.

_Should the new concept of UI DOM subtree-locking thread be introduced to allow multithreading on JS level?_

Such ability would be quite beneficial for web 3 microapplications insulation. IMO [microapplication](https://github.com/EPA-WG/EPA-concept/blob/master/microapplication.md) is live insulated content from 3rd party vendors running jailed on the page.

# What is next?
Looking for implementation references, ideas/comments/critics and people interested in developing the POC and standard API.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/discussions/882
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/repo-discussions/882@github.com>