Return htmx responses as SimplePageVariant

Opened an MR that uses a default simple page with a header control for using a block page variant.

Can we make use of a main content renderer like we do for dialogs?

Maybe. That doesn't necessarily look simpler to me but I don't know the internals as well as @larowlan. The work in 📌 Process attachments (CSS/JS) for HTMX responses and add drupal asset libraries Active is based on returning an HtmlResponse object, so would we be creating a simpler version of \Drupal\Core\Render\MainContent\HtmlRenderer? I would think we would still need an event subscriber to divert the request to the alternate renderer.

Another advantage of the page variants is that SimplePageVariant contains system messages as well as main content. That would allow the calling element to use hx-select-oob, or for us to add an hx-swap-oob to the response, and display error messages as well as the selected content from the response.

All tests green, including new unit test for this subscriber

System messages in the AJAX system are rendered via MessageCommand, and the same infrastructure is used by BigPipe since 📌 Use MessagesCommand in BigPipe to remove special casing of the messages placeholder Fixed . I'm not sure how that would compare to #8 in terms of final implementation, although presumably we might need to support an HTMX version of MessageCommand for bc anyway?

For the idea in #6 we would need HTMX to send ?_wrapper_format=htmx in the query string of all requests. This looks like it is doable via the htmx:configRequest event. Then, we add a service similar to HtmlRenderer but which can do less work - it wouldn't need to care about display variants at all.

Rendering the system messages in the response would mean that we wouldn't need a command to define the messages. The core systems of defining and displaying messages is available.

We would need to implement in a later issue either

1. Always select and display system messages as additional inserted content
2. Provide an operation for selecting the messages from the response and displaying them to be used with appropriate

@longwave Okay, that's two experienced maintainers recommending a renderer over page variants. Thanks for weighing in!

We don't need the query string as HTMX adds the header HX-Request: true to all requests. I'll start to work on that approach as an alternative. I think we do still want title though so that the HTMX feature of swapping the title is available if appropriate but we turn it off by default.

We do need the query string, as that's how MainContentViewSubscriber decides which instance of MainContentRendererInterface is needed to render the page; without the query string it will fall back to HtmlRenderer.

+1 to #14 it will use seriously less code selecting renderer earlier

btw about messages ...hope it covered with drupal.message since 8.7 →

btw that's exactly a place to extend because attachments also should be delivered and merged, and not sure about "ajax_page_state"

and maybe a middlegroud is to add middleware to append query string when header provided

RE: #16 - yes we have that covered in 📌 Process attachments (CSS/JS) for HTMX responses and add drupal asset libraries Active

Unsure how this interacts with caching as well - if the same route is usable via both standard HTTP and HTMX then we want the cached responses to differ.

If it's a GET request (which it should be for HTMX when possible), then the internal page cache won't differentiate so it could get corrupted, and same problem with varnish/CDNs, so we would have to enforce that the HTMX route is only used for HTMX and throw a bad request exception or something when the header is missing.

That makes me think we should just set the query string on the client side, even if we also have the header set.

#19 reminded me of 🐛 Enable header-based proactive content negotiation with optimizations and opt-outs available. Needs work where Drupal does not use the Accept header for format negotiation, primarily because of external caching issues.

#2364011: [meta] External caches mix up response formats on URLs where content negotiation is in use → was I think the definitive issue for Drupal 8 where accept negotiation got canned. I haven't re-read that issue recently but remember the whole area being extremely painful at the time. So yes, on the basis we would want at least some HTMX responses to be cacheable in edge caches, let's use a query string from the client.

I'm so glad to be working with collaborators who have a historical perspective on the code! This is an enhancement not a requirement that will give a bit of performance boost. I'm going to postpone it and move it down the task list before BigPipe.

In the module, this simplified HTML response is a route option and scanning the linked history that may be a good thing. Let's think about routes we might build to serve requests from HTMX and pick up this work in a while. Ideas that I have for routes are:

• the one I have in the module /htmx/{entityType}/{entity}/{viewMode}
• one to render placeholders as the main content

I don't think the routing concern is necessarily a big pipe conversion blocker. Big pipe just uses render placeholders that return an AjaxResponse object, there's no routing involved.

It might not be, but if we refactor BigPipe to use HTMX we should return HTML - probably with the placeholder as the main content, and I wondered if that might intersect with this use case??