Feedback

Happy to break any of this out into specific issues if it would benefit from it. I've only really looked at part 1.

High level design feedback

Imagining a site like the following:

What I'm trying to express here is that the home page does not have a side nav. All docs pages have the same side nav. All blog posts have the same side nav, but it's different to docs pages. All pages have the same footer etc etc.

Based on my understanding of the proposal, here are some observations:

• Unless developers are prepared to create specific patches from each page type to every other page type (which doesn't seem to be the intent of this proposal), each patch payload is going to contain the full destination page content, which may include content that's already being displayed.
• The home page will need to have elements ready to house the side nav and chat widget, even through it doesn't have them. Otherwise, the side nav will be missing when patching from home to other pages. I guess the easiest thing to do would be to create a single page shell for the whole site which contains all possible content containers.
• The home page will need to have empty <template patchfor>s to clear out the side nav and chat widget containers, else if you go from home to docs to home, the home page would have an unwanted side nav.
• Given that the footer is consistent across all pages, it wouldn't need to be expressed in a <template patchfor>, and therefore wouldn't update across same-doc navigations. Although this would need to be refactored if a single page has a different footer, or doesn't have a footer.
• When navigating between docs pages, the side nav would be fully replaced, because all pages would have a <template patchfor=nav> to handle navigations between the page types. This would be frustrating if the nav contained state, eg <details> elements that the user had interacted with.
• The same problem exists with the chat widget - it will be reinitiated between all navigations because it'd be replaced with a fresh <chat-widget> or whatever.

The benefit of modern frameworks is the developer can describe the destination state (eg in JSX), and the framework determines some DOM operations to get the current state to the new state, ideally preserving things which are common between both states. Both states may have a <ChatWidget>, but as long as a framework-specific set of rules determine it's the 'same' chat widget, it isn't reinitialised. It feels like this proposal doesn't have this feature.

Other questions/notes:

• What's the best practice if one page requires additional script. Eg, when moving from home to docs, how/when is the code for the chat widget loaded? Would this be a <script type=module src> in the <template patchfor>?
• How are overlapping patch* calls handled? As in, what happens with document.patch(response); document.patch(otherResponse);
• Why does the API need a Response and not just a text/byte stream?
• When handling page titles, I assume you'd have to do something like <title id="title">My page title</title><template patchfor="title">My page title</template>, because if you omit the content from title element, a bunch of simple parsers are going to miss it.
• There are a bunch of differences between regular document parsing, and innerHTML parsing, especially around scripts. Which model is used here?
• What happens if <template patchfor="foo"> contains a <template patchfor="foo">?
• The content of <template> flipping from success content to error content depending on the presence of patchsrc seems a bit weird.
• The behaviour of element.patchSelf seems self-contained, individually useful, and complex enough to treat as a first-to-ship part of this.

Start by reviewing the declarative partial updates proposal and its template patchfor, patchsrc, document.patch, and element.patchSelf entry points. Compare the feedback about page shells, navigation state, chat widgets, scripts, titles, parsing, overlapping patches, and nested templates. Done would require a decided design and concrete scope, which this issue does not yet provide.