I was just testing this by merging it to the add/wp-show-ssr branch. However, I’m finding a weird behavior 😅

It seems that the HTML from the server is correct, but it gets malformed after hydrating. I made a quick video trying to explain it better:

https://www.loom.com/share/b6060fcc6d5c4ac0b4be34a2fd41f746

Basically, for this HTML:

<div data-wp-context=‘{ “isOpen”: false }’>
    <div data-wp-show=‘context.isOpen’><span>WP Show</span></div>
</div>

The HTML from the server is correct:

<div data-wp-context=“{ “isOpen”: false }“>
    <template data-wp-show=“context.isOpen”>
        <div><span>WP Show</span></div>
    </template>
</div>

In the client, an extra empty <template> is being added inside the <template>:

<div data-wp-context=“{ “isOpen”: false }“>
    <template data-wp-show=“context.isOpen”>
        <div><span>WP Show</span></div>
        <template></template>
    </template>
</div>

In the video, I'm not using the latest version of the branch, but I tested it again with the latest changes and the problem is still there for me.

Thank you Mario for testing! 🙌

I’m a bit relieved that the issue is on the client side only, and that it doesn’t occur when you disable JS, as that confirms that it must be an issue with our client-side code (and not e.g. malformed HTML that the browser "fixes" when building the DOM).

I made a Loom to explain the issue:

https://www.loom.com/share/b05feef81060465983c313ef40733c4f

Hmm, I think I've found another instance of wrapped <template> tags that this PR hasn't fixed yet 😕

<template data-wp-show="selectors.wpmovies.isPlaying"><template ><div  class="wpmovies-video-player wp-block-wpmovies-video-player">
	<div class="wpmovies-video-wrapper">
		<div class="wpmovies-video-close">
			<button class="close-button" data-wp-on.click="actions.wpmovies.closeVideo">
				Close			</button>
		</div>
		<iframe src=""
			width="420"
			height="315"
			allow="autoplay"
			allowfullscreen
			data-wp-bind.src="state.wpmovies.currentVideo"
		></iframe>
	</div>
</div></template></template>

(This is again the Movies Demo when used locally with the block-interactivitiy-experiments repo, with the branch from #141 checked out, and fixes from this branch applied.)

Oh, I just remembered that the wp-show directive client logic was different than the one we are using in the server because there is a bug (no issue yet) of props passing to next element. If we take a look at this discussion, the SSR is returning the Option 1: "Wrapped everything inside the <template> tag", and the CSR is returning the Option 2: "Wrapped children inside the <template> tag"

Maybe that's the reason why it is not working as expected in the video I shared previously.

I think I've found another instance of wrapped <template> tags that this PR hasn't fixed yet

I confirm that I can also replicate the issue you reported in the movies demo 😢

Apart from that, I have one question: is it correct to move the data-wp-show="selectors.wpmovies.isPlaying" attribute to the <template> tag, or should it remain in the div? I don't know about the implications (if any).

Oh, I just remembered that the wp-show directive client logic was different than the one we are using in the server because there is a bug (no issue yet) of props passing to next element. If we take a look at this discussion, the SSR is returning the Option 1: "Wrapped everything inside the <template> tag", and the CSR is returning the Option 2: "Wrapped children inside the <template> tag"

Maybe that's the reason why it is not working as expected in the video I shared previously.

Ah yeah, that seems likely!

Apart from that, I have one question: is it correct to move the data-wp-show="selectors.wpmovies.isPlaying" attribute to the <template> tag, or should it remain in the div? I don't know about the implications (if any).

TBH I was really just trying to follow what seemed to be the outcome of the discussion you mentioned at the time:

Actually, I would even use a slightly simplified variation of 1. When wp-show is false:

• Wrap it with <template> in the server (maybe also move the wp-show to the template).
• Remove it from the DOM in the client.

Should I leave the data-wp-show attribute on the wrapped tag (instead of moving it to the wrapping <template>) after all? cc/ @luisherranz

Should I leave the data-wp-show attribute on the wrapped tag (instead of moving it to the wrapping template) after all?

So there's a small problem with templates and vdoms that I haven't figured it out completely yet.

https://www.loom.com/share/a8fe41eeb30343cc8fc41f08d0045b41
https://stackblitz.com/edit/vitejs-vite-razb5u?file=src%2Fmain.jsx,index.html

At first glance, it looked like moving the data-wp-show to the template would help. But again, I've barely investigated the issue, so maybe there's a better solution.

Oh, wait. I just remembered that I actually did some coding for this.

This is wp-show with the directive moved to the <template> in the server: https://stackblitz.com/edit/demo-filters-multiple-queries-rsrp5l?file=src%2Fruntime%2Fdirectives.js,index.html

<!-- This was SSRed as false in the server -->
<template data-wp-show="context.showImage">
  <img src="..." />
</template>

<!-- This was SSRed as true in the server -->
<img data-wp-show="context.showImage" src="..." />

In this implementation, the HTML is removed from the client when wp-show is false (instead of keeping the <template> in the DOM).

What I'm doing here is saving the HTML of the template in a separate prop:

const isTemplate = localName === "template";
const childNodes = isTemplate ? node.content.childNodes : node.childNodes;

// ...

if (isTemplate) return h(localName, { ...props, templateChildren: children });

That way, the hydration doesn't add the inner contents of the template to the DOM.

Then, in the wp-show directive, I get either the children in that prop (when wp-show was false in the server), or the element (when wp-show was true in the server).

const children = useMemo(
  () =>
    element.type === "template" ? element.props.templateChildren : element,
  []
);

And finally, I remove the HTML from the DOM in the client when wp-show is false:

if (!evaluate(show, { context: contextValue })) return null;

return children;

Since this PR isn't quite fixing all the issues we were seeing, and we're looking to fix what seems to be an underlying issue with the Tag Processor, I'm considering closing this PR.

There's still the separate issue of processing directives repeatedly (once for each layer of nested inner block) which is fixed by one of the commits in this PR (a8cadac), but I'm thinking to file a new PR for that to keep that conversation separate.

There's still the separate issue of processing directives repeatedly (once for each layer of nested inner block) which is fixed by one of the commits in this PR (a8cadac), but I'm thinking to file a new PR for that to keep that conversation separate.

#227