[Plan] New Features for 1.4

Here are three suggestions that are top of mind for me:

1. Simplify site builder workflow. Currently a site builder must first create an HTMX block to then reference a standard block. Can this step be eliminated and instead add a HTMX configuration tab to standard blocks?
2. Reduce the markup payload. This was discussed in Slack here. You indicated that what's being returned is standard and expected. You know more about this stuff than I do but it still feels odd/unnecessary as we're hell bent in only delivering to the browser what is absolutely needed. Noting that the current state also causes the admin toolbar to appear because it is not rendered as a block. You indicated that building a new page variant would be the way to solve this but is also a big effort.
3. Paragraphs support. Many websites are built with Paragraphs. Would be great to be able to configure Paragraph to use HTMX.

Not sure how this next bit would fit into a roadmapping feature, so here it goes:

Our use case is narrow, we want to lazy load the entity, and I've experimented by writing Twig code to do the HTMX magic but I'm running into an issue where the very View Mode (Default) that is only rendering an HTMX placeholder is then needing to call the Default View Mode to actually rendering the markup... so its a self referencing loop. I was thinking that I might have a "swappable" View Mode that gets dynamically created to allow this passthrough. I imagine that this is why the blocks site building workflow requires an HTMX block which is what is placed in a region and which then calls the standard block?

@capellic To reduce the markup payload, I think what you are asking for two things:

1. To find a way to supress the admin toolbar when rendering a \Drupal\Core\Render\Plugin\DisplayVariant\SimplePageVariant
2. To be able to render part of a twig template, what HTMX calls a fragment.

It doesn't look hard to remove the toolbar from a render array.

The linked HTMX reference points out that Twig can render named blocks within a template. This would be an alternate render pipeline. I can look at the default "render the whole template" pipeline and see how difficult such a task might be.

As to your paragraph question and the general question of rendering dynamic elements that replace themselves, yes one needs an alternate source for the replacement. That's one reason for how I implemented HTMX blocks as I did. Plus inserting into or taking over the block building process seemed like a challenge. With your paragraphs, I would suggest adding an HTMX view mode that has your lazy loading attributes on an otherwise empty div, and call for the render of the paragaph in default as your HTMX request.

To find a way to supress the admin toolbar when rendering a \Drupal\Core\Render\Plugin\DisplayVariant\SimplePageVariant

For sure! :-)

To be able to render part of a twig template, what HTMX calls a fragment.

Interesting. I can't say I'm understanding the implementation details here but the outcome is a very lean response and I like that. The example deals with buttons within a component, which is more granular than my use case, I'm basically interested in slimming down the HTML response for entity rendering (Blocks, Paragraphs).

As to your paragraph question and the general question of rendering dynamic elements that replace themselves, yes one needs an alternate source for the replacement. That's one reason for how I implemented HTMX blocks as I did. Plus inserting into or taking over the block building process seemed like a challenge. With your paragraphs, I would suggest adding an HTMX view mode that has your lazy loading attributes on an otherwise empty div, and call for the render of the paragaph in default as your HTMX request.

Good to know that my inclination of why HTMX Blocks exist in the site builder workflow as correct. :-) I'm going to think on this. I do think that
using View Modes is the key here, and my interest is making this transparent to the editor. I imagine that a site builder can designate a Paragraph to load lazily (and possible other ways using the more of the HTMX API than I'm currently thinking about). Let's assume that's the Default View Mode. Then, when the Default View Mode is rendering, I'm thinking that if it is designated to load lazily, a "HTMX" View Mode is swapped in to deliver the HTML that will then reference the View Mode that was requested. I'm thinking we can send an argument on that second request to tell Drupal to actually return the the component markup instead of the HTMX placeholder. 😬

Yes you can do that now. I would probably reverse the funtionality of your named view modes but that's for the chef to choose! I would configure one view mode for display in the rendered entity settings for the paragraph field. I would build a Twig template for that view mode that just had the article tag with HTMX properties to get the HTML for the paragraph from our endpoint in the fully configured view mode, triggered on load and swapping itself with outerHTML strategy (replace).