[POC] Implementing some components of the Ajax system using HTMX

Three initial thoughts:

1. Content replacement is probably the simplest case and so one we should include in this POC
2. I have a proof of concept for JS/CSS attachment in the HTMX contrib module.
3. What if we plan to replace the #ajax render array key with an #htmx key? If we did that, then our BC strategy is writing a converter that rewrites the render array to equivalent values

I think those steps are close to what I'm thinking about. I would adjust it like so:

1. Determine where and how to process an #htmx render array property.
2. Agree on a couple of use cases
3. Design a processor that transforms #ajax render array key-value pairs into #htmx render array key-value pairs. This is our BC layer.

For use cases I think we may have agreed on

Content replacement using #wrapper

I would suggest one of the commands that are similar, such as append, for the second.

I've been simmering ideas on my "back burner" and want to get some feedback before making something.

HTMX expresses itself in HTML attributes. What if we extended \Drupal\Core\Template\Attribute to create an HtmxAttribute that has class methods for the various attributes used by HTMX? That would allow us to support something like this:

$htmx = new HtmxAttributes();

$htmx->get(Url::fromRoute(
    route_name: 'htmx.htmx_entity_view',
    route_parameters: ['entityType' => 'node', 'entity' => 27, 'viewMode' => 'teaser'])->toString()
  )
  ->select('article')
  ->target('main')
  ->swap('beforeEnd');

$build = [
  '#htmx' => $htmx,
];

Each class method would call \Drupal\Core\Template\Attribute::createAttributeValue and create the correct attribute. Our process function callback for the render process then just needs to merge the HtmxAttribute object with any existing Attribute object and set the result as the element's Attribute.

Good questions! I'm working backwards from where we need to end up. In the end, we need markup like this

  <button hx-get="/htmx/blocks/add/announce_block"
        hx-target="#drupal-off-canvas-wrapper"
        hx-select="#drupal-off-canvas-wrapper"
        hx-swap="outerHTML ignoreTitle:true" class="button">
     Add
  </button>

So the yes, the Attributes object which arrives in Twig as attributes seems like the natural way to get that. And yes, if we merge HtmxAttribute or if we send it directly, it has all the methods of Attribute either through inheritance or because we've merged into one.

I did a quick search into how we process and render the #id property and I didn't land on how that happens, but it arrives in Twig in the attribute variable so we end up in the same place right?

I've had an inquiry about the appropriate markup to use and have moved that to a related issue: #3456070: [policy, no patch] Choose a markup strategy for HTMX POC Please add your guidance there!

Thank you @fgm for reminding me that we are working on core! I was surprised there wasn’t an interface but I’m so used to working in contrib, I thought inheritance was what we had. We totally need an interface here.

I decided to implement the inheritance version of this strategy in the contrib module so that people can easily try it out. The MR is pending with the extended class and a documentation page with some usage examples for that implementation.

This issue's implementation would use composition, and have a dedicated key, taking care of merging the attributes in processing. That said, feedback welcome over in contrib to refine any of this before we stand it up here in Core.

It looks to me like the Attribute magic happens in template_preprocess found in core/includes/theme.inc. If I add a #htmx key in a render array, and then add

if (isset($variables[$key]['#htmx'])) {
  $variables['attributes'] = AttributeHelper::mergeCollections($variables['attributes'], $variables[$key]['#htmx']);
}

right after the existing #attributes merge, then a breakpoint at the assignment here trips.

As I look more deeply at implementing the idea from @fgm in #17, it seems to me that the interface should be much smaller than the public methods, otherwise we're just moving everything in Attribute to various traits or something as there is only one protected method and it has the logic for creating values before storage. Many of the other existing public methods implement other Interfaces for Attribute.

I looked through all the places we currently test for instanceof Attribute and I propose these methods on the interface:

• ::hasAttribute
• ::toArray
• ::merge

Because in templates we want the full suite of Attribute methods, I'd leave these instanceof conditionals as they are in AttributeHelper

    // If at least one collections is an Attribute object, merge through
    // Attribute::merge.
    $merge_a = $a instanceof Attribute ? $a : new Attribute($a);
    $merge_b = $b instanceof Attribute ? $b : new Attribute($b);
    $merge_a->merge($merge_b);
   
    return $a instanceof Attribute ? $merge_a : $merge_a->toArray();

Here's an initial draft of the attribute changes: https://git.drupalcode.org/issue/drupal-3446642/-/compare/11.x...3446642-poc-implementing-htmx

Well, #20 is not the right solution for where
to merge in '#htmx' because of the nature of template_preprocess_HOOK such as this in form.inc. Probably why existing ajax is doing it's work at the element pre-process level.

/**
 * Prepares variables for select element templates.
 *
 * Default template: select.html.twig.
 *
 * It is possible to group options together; to do this, change the format of
 * the #options property to an associative array in which the keys are group
 * labels, and the values are associative arrays in the normal #options format.
 *
 * @param $variables
 *   An associative array containing:
 *   - element: An associative array containing the properties of the element.
 *     Properties used: #title, #value, #options, #description, #extra,
 *     #multiple, #required, #name, #attributes, #size, #sort_options,
 *     #sort_start.
 */
function template_preprocess_select(&$variables) {
  $element = $variables['element'];
  Element::setAttributes($element, ['id', 'name', 'size']);
  RenderElementBase::setAttributes($element, ['form-select']);

  $variables['attributes'] = $element['#attributes'];
  $variables['options'] = form_select_options($element);
}

Some additional adjustment to FormBuilder is needed, and I could use guidance as to where. The POC is on admin/config/development/configuration/single/export

Here's the problem sequence:

1. Load the form
2. Change the type
3. Select a name
4. Change the type

At this point the form class is called to build the form, but this but doesn't run:
FormBuilder.php:1294

      // Detect if the element triggered the submission via Ajax.
      if ($this->elementTriggeredScriptedSubmission($element, $form_state)) {
        $form_state->setTriggeringElement($element);
      }

so the name is not reset.
Then the code above is executed but the form is not rebuilt.

I feel like we therefore need to set a rebuild if our request is htmx but I'm not sure the correct place to do that in form builder.

Here is a diff with 11.x of the current state of the work.

Critical thinking is a valuable means of understanding something new. I recognize that the author of the critique works regularly with HTMX and I'll watch for some of the edge cases called out, but I wonder if there are some a priori assumptions from working in single-page-applications when I read

An attractive future direction might be to re-implement Htmx in React

I have a working POC on the Single Config Export form: https://git.drupalcode.org/issue/drupal-3446642/-/compare/11.x...3446642...

Feedback invited!

@nicxvan asked in Slack for steps to review functionally. Also posting them here:

1. Check out my branch in core development setup
2. Install an empty site
3. Browse to admin/config/development/configuration/single/export

For convenience:

git remote add drupal-3446642 git@git.drupal.org:issue/drupal-3446642.git
git fetch drupal-3446642
git checkout -b '3446642-poc-implementing-htmx' --track drupal-3446642/'3446642-poc-implementing-htmx'
drush si -y
drush uli admin/config/development/configuration/single/export

The dynamic features in the form are using htmx

Thanks for the extra eyes @nicxvan! I missed a variable change moving some JS over from the HTMX module. Updated the branch.

The markup format is discussed and decided in #3456070: [policy, no patch] Choose a markup strategy for HTMX POC

Added support for HTMX Response Headers which allowed me to implement a missing feature in ConfigSingleExportForm. The route and the form are built to take parameters for configuration type and name. However the implementation via core ajax does not update the url.

This htmx implementation now does so that the result can be captured via a link.

Our second part of the POC is to replicate a more complex command. I first thought of an Htmx object composed of the attributes and headers as a organization tool, but I realize it has more power than that. More complex behaviors will use both toolsets. In particular, we can achieve any behavior not available natively in HTMX using one of the trigger headers to invoke our own javascript.

Proposed architecture

1. Create an HtmxInterface to make it easy for contrib to create additional behaviors
   • Accessors for each of the composed attribute and header objects
   • A method for both attribute and header that takes appropriate objects or render array snippets and returns that data merged with the data managed in the corresponding property.
   • A method for merging another HtmxInterface object that returns an HtmxInterface object.
2. Create a method on the Htmx class that implements each of the current ajax behaviors by creating a method that configures the appropriate attributes and/or headers.

Implemented architecture

• Accessors for each of the composed attribute and header objects
• A method for both attribute and header that takes appropriate objects or render array snippets and returns that data merged with the data managed in the corresponding property.
• A method for merging another HtmxInterface object that returns an HtmxInterface object.
• Use HtmxOperationInterface objects that implements each of the current ajax behaviors by configuring the appropriate attributes and/or headers.
• Compose these HtmxOperationInterface objects into the HtmxInterface object and process them at render so that they can be altered.

The example implementation in ConfigSingleExportForm is updated with this approach

Two HtmxOperationInterface implemented:

• Insert
• Replace

Passing tests:

• core/modules/config/tests/src/Functional/ConfigSingleImportExportTest.php
• core/tests/Drupal/Tests/Core/Render/Hypermedia/HtmxOperationsTest.php
• core/tests/Drupal/KernelTests/Core/Template/HtmxAttributeTest.php
• core/tests/Drupal/KernelTests/Core/Http/HtmxHeaderTest.php

Rebased on this week's changes. Looking at test failures next

Linting complete.

Most tests fixed.

Only 1 failing test: ActiveLinkResponseFilterTest. Suggestions welcome from anyone else who has worked in this area. I'm going to fire up xdebug to step through and puzzle out what is needed

I feel like this issue did it's job. We are now taking the learning from this work into new child issues on #3404409: [Plan] Gradually replace Drupal's AJAX system with HTMX

Resetting status and moving to "Fixed" at @jurgenhaas suggestion so someone can comment and assign issue credits. Thought we needed to commit something to do that :)

@jurgenhaas pointed out that we should call this "fixed" since it accomplished it's purpose!