1.1 Goals for HTMX

Here's my initial list:

1. A means to dynamically add assets needed by inserted html: 📌 Leverage hx-swap-oob for assets Active
2. Create an HTMX Blocks sub-module that provides Drupal blocks can be configured to respond to an HTMX event (hx-on). When the event triggers, replace itself in the DOM with another block.
3. Create an HTMX Node sub-module that provides an htmx route to render a given node in a given view mode

Let's focus on an initial release of basic features: v1.1

As to what can be built? I've been playing with HTMX Blocks. I wanted to create a bucket of configured blocks that were along side those configured to be placed in the regions. I've been learning how HTMX works by building the admin interface with it and I definitely started with your "fancy things happen when I click a button" so that edit forms are presented via ajax in a <dialog> element and the list of blocks is updated when an edit form is submitted.

A documentation request came in to the issue queue around the same time you posted: create tabs that load other content. They could lazy load using hx-on:load of on mouseover, or when they scroll into view...

Infinite scroll seems high on the list

Multipart forms - anything we use our could use ajax for.

Also excited to see movement in this module!

> Create an HTMX Node sub-module that provides an htmx route to render a given node in a given view mode

This is the thing I'm the most excited about this module offering. A lot of HTMX documentation and examples just kind of punt on how you build a backend that responds with appropriate markup at a lower level than a full page. If this module offers this feature Drupal magically becomes a fantastic backend for supporting HTMX use cases.

This opens up a lot of possibilities in Drupal, but personally I'm just as interested in decoupled use cases. If we solve the problem of adding the necessary assets to these responses, or developers theme using a css framework that can be used consistently across different front end tech stacks (think Tailwind) it becomes much easier to work with components that will look identical both in and out of the context of Drupal. It also makes things like managing layouts in Drupal (Layout builder, layout paragraphs, etc) that are translated to a decoupled app, much much easier.

This reminds me of how the Lupus Custom Elements module supports adding a '_format=custom_elements' query param to any request. Being able to tack something like ?_format=htmx or ?_format=simple_page to any request would be amazing.

> A means to dynamically add assets needed by inserted html: #3436841: Leverage hx-swap-oob for assets

Important to solve this as well obviously. Does the simple_page variant / _htmx_route already provide these assets? Or are they the assets for the full page? Or no assets at all?

There are a lot of other htmx specific features that could be added to this module, but just these two features alone provide so many raw building blocks...

I also maintain a module called View Transitions → that depends on HTMX for some of its current functionality.

At the highest level, I'm happy that I'll be able to remove the library that adds HTMX and instead depend on the library provided by this module.

In the crazy ideas category, the module also offers a Single Page Application mode that converts any Drupal site into a SPA using HTMX's boost mode. → We're doing this due to the evolving browser support of the view transitions spec. I hope at some point the multi page app version of view transitions will make SPA mode unnecessary (or at least not the default).

I'm not sure if this module would want to support boost mode like that (it feels kind of gross!) but perhaps the code could provide a few useful examples: https://git.drupalcode.org/project/view_transitions

The JS for SPA mode might also be interesting when thinking about #1 above - it handles things like retaining css assets during routing events to prevent flashes of unstyled content. Fully expect that there are many cases for real world sites where this falls appart, but it works reasonably well for Olivero and Umami.

Let me know if you have any questions. I plan on following along.

@brianperry also it might be cool to see a case study on how you make your slides with View Transitions. That would be a cool walkthrough.

Added ✨ Proposal: New HTML response service Active based on the discussion above.

Adding a note here to document a conversation in Drupal Slack with @ndf - we are not going to add the complexity of submodules but keep a standard one module structure

I should have branched 1.1.x off when we started. The idea is that we are using patch based branches so that we can update the htmx library in a patch update on the existing minor version while we are working on the next minor version. I didn't but it has been short enough I think that's OK. I'll make the branch now and aim to keep the strategy going forward.

Automatically closed - issue fixed for 2 weeks with no activity.