🇺🇸United States @fathershawn

New tests now pass after adjusting big_pipe.js.

New test cases fail using beforestart and afterend

On hold pending a bug fix in core

fathershawn → created an issue.

fathershawn → created an issue.

I think the only unresolved feedback relates to message theming and swapping. I would propose that those are handled in the related issues on message theming.

fathershawn → created an issue.

fathershawn → created an issue.

I posted in 🐛 AJAX MessageCommand markup and styling differs from Theme default Active and 🐛 10.3 upgrade now missing status-message theme sugestions Active proposals that would simplify the work in this issue.

I posted the following at #32 🐛 AJAX MessageCommand markup and styling differs from Theme default Active in 🐛 AJAX MessageCommand markup and styling differs from Theme default Active

We use status-message.html.twig to theme individual messages and #theme => 'status_message' when constructing a render array.

If that proposal is agreeable, this issue would be used to add the theme hook core and template to core themes.

We are well on the way to changing BigPipe's placeholder insertion process in 📌 Refactor BigPipe to use HTMX Active . A fundamental difference is that HTMX expects HTML. Which means that we neither need nor want to assemble HTML in javascript for messages. When I commented to @catch that what we really needed was a theme hook for an individual message he sent me here :)

In the refactored BigPipe approach I'm sending messages generated by rendering a placeholder as HTML wrapped in a <template>. At the moment I still need javascript to find the wrapper element for the messages so they can be moved into place. I think that this work could be simplified down to storing a CSS selector in drupalSettings. Here's my proposal:

1. Core stores the CSS selector for the default wrapper element in settings.
2. Themes can store a different selector in their theme.info.yml file.
3. If the active theme has an override in replaces the default.
4. We use status-message.html.twig to theme individual messages and #theme => 'status_message' when constructing a render array.
5. Inserting the resulting html dynamically into the designated wrapper becomes very simple

Please add credit for @jrockowitz and @richgerdes who collaborated on test refactoring at the DrupalNYC Contribution Day

Thanks for the issue link in #22 @catch! I'll go there and chime in!

All tests green!

If this approach is good we should open an issue to theme individual messages to provide a server side way for themes to specify message markup

BigPipeRegressionTest is now completely passing.

`BigPipeRegressionTest::testMessages_2712935` is now passing

Returning to this - we aren't using any headers in 📌 Refactor BigPipe to use HTMX Active

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

The fix in this issue is also contained in 🐛 Admin Page `admin/config/services/jsonapi` is not loading in test environment Active which also fixes other issues

I still need to deal with Messages and Redirects, but this approach is simpler and over a 10 request sample results in a mean time of Load of 178.6 ms compared to 185.4 ms for the existing 11.x branch.

Here's an MR into @nod_'s branch moving the bigPipe command JS into bigPipe scope. It looks like the test setup scripts don't like MR's into a feature branch. The tests generally pass locally - 2 failures involving noJS exceptions. Not sure if that's a false negative as all of these changes are in JS.

If this is an acceptable direction then I think the next level of refactoring is to create the needed bigPipe Command classes to replace the AjaxCommands and update BigPipe.php to work without the Ajax API classes.

fathershawn → changed the visibility of the branch 3526267-bigpipe-with-htmx to hidden.

We need this only if if there is an existing capability we cannot implement using the tools provided by htmx - let's keep it a placeholder.

All green is super - nice work! This is direction really simplifies the changes in big_pipe.js and that’s a real plus.

Because bigPipe as we have it re-uses existing javascript from the ajax system, to remove the ajax system we need to replace that.
@nod_ had this list in a Slack discussion:

We need the equivalent of those 3 commands to implement bigpipe

• use Drupal\Core\Ajax\MessageCommand;
• use Drupal\Core\Ajax\RedirectCommand;
• use Drupal\Core\Ajax\ReplaceCommand;
• Add_css/add_js and the settings but that’s mostly available already

I think we need to identify the pieces of this list that htmx is not going to do, and implement those in general scope. Then the items that htmx does just fine in an ajax context, we need to have as helper methods in big_pipe.js and leverage the htmx api where we can.

I'm going to take them in order.

MessageCommand
In the ajax context, I would have implimented this in HTMX using a header and a custom event handler that calls our Drupal.Message function. This is actually the example in the trigger headers documentation.

HX-Trigger: {"showMessage":{"level" : "info", "message" : "Here Is A Message"}}

One thing that Drupal.Message does client-side is determine the selector for the message container. If there is a way to do that server-side then this could also be implemented as an extra out-of-band swap on the response without any additional javascript.

We do need a helper method for this that we can use in big_pipe though.

RedirectCommand
HTMX has both the HX-Redirect and HX-Location response headers. We don't have a response so we need a function for that in bigPipe.

ReplaceCommand
We also just need the bigPipe use case for bigPipe. This is one of the core competencies of htmx in an ajax request context.

addCSS and addJS
In the ajax context using htmx, these feel like out of band swaps as well.

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

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."

fathershawn → created an issue.

What ever we implement, if there is configuration we should collect in via \Drupal\dynamic_yield\Form\FeedSettingsForm and store it in the general settings.

We already to not load DY on admin routes. The presenting issue is that some pages often use the admin theme, such as entity edit forms. This seemed like a simple way to exclude certain path patterns.

We could programmatically detect the active theme, get then name of the admin theme and compare to exclude DY.

I think all questions have been addressed.

Thank you @catch. I wanted to layout the concerns expressed to me, and I'm comfortable with our original course. I think it is cleaner to create and transition to a parallel system. The HtmxInterface that I propose in the issue summary offers two paths for a developer.

A developer does not need to know anything about how HTMX works. Choosing from a defined set of operations, such as Replace or Insert, the developer adds the required data to the operation and inserts it into the Htmx object.

Alternatively, a developer can dive completely into the world of HTMX using the attribute and header subsystem objects that are part of the Htmx object. I guess there is also a third path which is to create their own implementation of HtmxOperationInterface to package these into something reusable.

This offers both simplicity and power in something that I think is straightforward to manage. Creating all the operations will be our final task in the initiative. I'm confident that we can offer a migration guide that maps ajax commands to htmx operations.

Tests revealed some issues

That's the right idea :). When I have time I'll inspect the render array there.

And in fact I did that in \Drupal\htmx\Render\HtmxBlockView::build. So now to figure out why is didn't do that for the caching

fathershawn → created an issue.

It sounds to me like what is needed is that the dedicated render controller for the HTMX block needs to use the context of the requesting page.

This is ready - let's get it in!

Added: https://git.drupalcode.org/project/me_language_visibility

Looks like there are over 60 projects on d.o using this approach now.

This module uses the https://github.com/ddev/ddev-drupal-contrib approach for module development. This makes the module easy to maintain. Drupal CMS also has a committed `.ddev` directory although their setup isn't for a contrib module: https://git.drupalcode.org/project/drupal_cms

Fixed in ✨ Single-Directory Components Active

All threads resolved - all tests passing :)

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.

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!!

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.

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

I had a conversation in Slack with @cilefen about how much we should present an abstract interface to the rest of the system and keep the HTMX implementation interface encapsulated. This alternate architecture would argue that we should name the facade class Ajax as that is the concept we are implementing. We would not provide direct access to the HtmxAttribute and HtmxHeader subsystems. The means of altering these subsystems would be to use an operation.

Such an architecture only exposes HTMX concepts to developers that need to create a combination of attributes and headers that is not available as an operation. In that case, the developer would create a new operation to encapsulate that combination. Of course such a developer could forsake the facade altogether and deal with the attribute and header subsystem directly.

This idea could be take further in 📌 Define and process an #htmx render array key Active and rather than define a new render array key, only add a new callback. The existing ajax callback would make an early return if the #ajax key did not point to an array and similarly the new callback if it did not point to an instance of the facade.

What is the right architecture?

fathershawn → created an issue.

Nice use of once property to verify the behavior had done its work +1!

With 10.2-alpha1 out should we move the tag to 10.3 and release all the functionality together?

fathershawn → created an issue.

New test passes.

Missed bringing over the Twig function

All tests green

All tests green

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??