DX object to manage htmx attributes

All tests green

Missed bringing over the Twig function

New test passes.

The Needs Review Queue Bot → tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

Applied a suggestion and will refactoring some improvements inspired by @larowan review. A maintainer should add him to the credits.

All tests green.

There are two open questions:

1. The best way to ensure a string is returned in AttributeJson
2. Single/double quoted syntax. See also filtering setup for strings in AttributeHtmxString.

I don't understand why we need the single quote. If you add a JSON::encode(), to the process assets MR it just works.

    $build['replace'] = [
      '#type' => 'html_tag',
      '#tag' => 'button',
      '#attributes' => [
        'type' => 'button',
        'name' => 'replace',
        'data-hx-get' => $url->toString(),
        'data-hx-select' => 'div.ajax-content',
        'data-hx-target' => '[data-drupal-htmx-target]',
// add this part
        'data-hx-vals' => Json::encode(['test' => 'ok']),
      ],
      '#value' => 'Click this',
      '#attached' => [
        'library' => [
          'core/drupal.htmx',
        ],
      ],
    ];

It doesn't matter that the source html doesn't look pretty. Once it's in the JS it's the correct value.

That's a great question! I didn't think it would but I didn't try. I'll repeat the experiment with an attribute value selector and remove the complexity. Simpler is better!!

Confirmed! I can now remove a trait and a class - thank you @nod_ :)

I altered the render arrays in the test module to

    $build['replace'] = [
      '#type' => 'html_tag',
      '#tag' => 'button',
      '#attributes' => [
        'type' => 'button',
        'name' => 'replace',
        'data-hx-get' => $url->toString(),
        'data-hx-select' => 'div.ajax-content',
        'data-hx-target' => 'div[data-drupal-htmx-target="insert-here"]',
      ],
      '#value' => 'Click this',
      '#attached' => [
        'library' => [
          'core/drupal.htmx',
        ],
      ],
    ];

    $build['content'] = [
      '#type' => 'container',
      '#attributes' => [
        'data-drupal-htmx-target' => 'insert-here',
        'class' => ['htmx-test-container'],
      ],

Which produces data-hx-target="div[data-drupal-htmx-target="insert-here"]" through the standard string attribute. HTMX worked as expected.

All threads resolved - all tests passing :)

We agreed in Slack to pause on this builder while we work on 📌 Refactor BigPipe to use HTMX Active using attributes that are "hand-rolled."

Coming back to this now - we needed the htmx javascript API in 📌 Refactor BigPipe to use HTMX Active but not attributes.

Tagged \Drupal\Core\Template\HtmlAttributeInterface as @internal as that seems consistent with the policy on Attribute class internals → .

Discussed and agreed in Slack that a single change record and release note will cover:

• 📌 DX object to manage htmx attributes Active
• 📌 DX object to manage htmx headers Active
• 📌 DX object to collect and manage HTMX behaviors Active
• 📌 Define and process an #htmx render array key Active

Based on #26 and the description of the tag (A change record needs to be drafted before an issue is committed.) I'm removing the CR tag from this issue as these are sequential dependencies and the tag belongs on final component.

Reading through the governance doc I am marking this for framework manager review since it is blocking other work.