Re: [w3ctag/design-reviews] Incubation: patching (interleaved out-of-order streaming) (Issue #1134)

noamr left a comment (w3ctag/design-reviews#1134)

> Thanks for sending this to the TAG! We have some questions and things you may want to consider.

Thanks for the detailed review!

> * Since perceived performance is a primary motivation, we're wondering if you have expectations about how much time can be saved and where specifically the saved time is going to come from. Maybe the benefit of one-off (JS-driven)  patches could be measured as [INP](https://developer.mozilla.org/en-US/docs/Glossary/Interaction_to_next_paint) improvement? How about Interleaved (HTML-driven) patches? Or is the goal more about reducing JS payload size because streamed updates no longer need to be managed in JS? Maybe both?

These numbers are going to be very difficult to produce effectively. We do have evidence however that this technique is used in production today.

> * It's good to see `patchid` used to target patches rather than `id`, but consider also https://github.com/webplatformco/explainers/blob/main/html-element-references/README.md. How does the scoping of `patchid` work with shadow DOM?

References here are both tree-scoped and element-scoped to the parent of the patch template (the latter applies if it's not a child of `body`).

> * Regarding "The first patch for a target in the document stream replaces its content, and the next ones append." The need to append is clear but it seems like it'd be simpler if all patches appended, without the first one replacing. If there's a desire to show a "Loading" message/icon that goes away when the first patch comes in, that could alternatively be managed with the proposed `:patch-pending` pseudo.

The rationale, which came from userland solutions that implement this, is that you want to be able to "replay" all the patches and reach the same result, e.g. when traversing history. 

We are thinking of adding a patch "mode" (replace/set/append/prepend/before/after), with an "auto" mode that uses this mechanism.

> * If the first patch appended rather than replaced the initial content, would there still be a use case for [replacing a range](https://github.com/WICG/declarative-partial-updates/blob/main/patching-explainer.md#enhancement---replace-range-instead-of-whole-contents)?

See above. We are currently thinking of using those modes rather than replacing a range.

> * The Security & Privacy self-review answer to "Does data exposed by your specification carry related but distinct information that may not be obvious to users?" should probably be "Yes" since this is about streaming HTML, which carries lots of different kinds of information, to an arbitrary node, where different nodes might expect different kinds of information.

Ack

> * What does interaction with the BFCache look like if the page navigates while there's an active stream? Does the streaming continue? Or does the fetch get cancelled in a way that might not be recoverable when the page is reloaded?

If you're navigating away from the page, what would be cancelled is the `fetch` that instantiated the response rather than the stream itself. if you have an ongoing JS stream I don't think it would be affected. But it's a good detail to flesh out.

> * The `pending` state in [[css-selectors-4] CSS reflection of "patching" w3c/csswg-drafts#12579](https://github.com/w3c/csswg-drafts/issues/12579) seems useful, especially since it seems to replace the use case for the first patch to replace the initial content as discussed above. Triggering it based on the presence of the `patchid` attribute is a little worrying. Maybe the declarative patch should also be able to update the original node's attributes? We're happy that the CSSWG is exploring how and whether to merge the proposed `:patching` pseudo-classes into other pseudo-classes that already exist.

Ack.

> * "Patch" might not be the right name. The action is either to replace or append to an existing node (and we'd prefer to avoid "replace" if possible), while "patch" implies changes in the middle of the content. Perhaps something like `appendto` as the declarative attribute is a better fit?

Thinking of `contentfor`

> * Can multiple patches be active at once? Can a patch be started when the main HTML parser is still active on the document? Would any issues arise from allowing multiple instances of the HTML parser to be active (in a paused state) simultaneously on the same document?

Currently patching the same element twice would cancel previous patches. There are a few permuations of this that are yet to be defined. 

> * If started before the `load` event fires, do active patches block the `load` event? Or `DOMContentsLoaded`? More generally, is there a need for a central way for developers to track whether there are active patches, or is it enough to be able to track them individually?

Patches from `<template>` would block the load event by definition, since the HTML is not fully loaded.
With `patchsrc` - they probably should as well but `patchsrc` is currently on the back burner.
Patches instantiated in JS are likely not going to block the load event. 

> * [Patching contents from a URL](https://github.com/WICG/declarative-partial-updates/blob/main/patching-explainer.md#potential-enhancement---patch-contents-from-url) kind of sounds like what [HTML imports](https://chromestatus.com/feature/5144752345317376) was trying to do; it's worth revisiting the history there to ensure the same issues aren't getting repeated that led to its deprecation. An issue with HTML imports was that it was a new type of dependency that didn't integrate well with ES modules (also new at the time). Is that a problem for this proposal? ES modules seem incompatible with streaming, as they require all module dependencies to be loaded prior to execution.

Yes we've revisited the history carefully. But currently `patchsrc` is on the back burner so we'll come back to it later on.


> * Can a single patch be directed into multiple elements?
No

> * Can interleaved patches be chained as follows?
> 
> <section patchid=gallery>Loading...</section>
> <template patchfor=gallery>
>  <div patchid=gallery-item>Loading item...</div>
> ...
> </template>
> <template patchfor=gallery-item>...</template>

Yes as long as the scoping rules work and the outlet's parent is an ancestor of the patching template.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1134#issuecomment-3360882022
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1134/3360882022@github.com>