🇺🇸United States @fathershawn

Patch re-rolled for v1.8

Setting back to RTBC per #20

The MR is great, thanks!

The code you are proposing to change reverse engineers the form markup apart from any attached assets so that we can get the assets to the right place. I'm very cautious about changing it so I will need more detailed steps to reproduce so that I can manually test it.

Please add details in the issue summary about how a test form that reproduces the error is set up in FormAssembly.

Documenting for myself and others that wFormContainer is used 3 times in the module:

1. src/ApiMarkup.php:166 to add an error display if no form is returned from FA.
2. src/Entity/FormAssemblyEntityViewBuilder.php:112 as a filter to get markup from the response.
3. src/Entity/FormAssemblyEntityViewBuilder.php:123 in the code you propose to change.

documenting how it has been done in the past - wrapper first

Thank you! Would you move your patch to an MR?

Would you move your patch to an MR?

Added the composer.json noted in #7

I come from the same days @mlncn. I'm sure I used drush gen to stand those up and that generator does like final classes!

This looks fine. Let's get the tests passing and I'll merge

@mrebel Even though the implementation is simple, we still need to document these for those unfamiliar with HTMX

HtmlCommand
We will not need this command. Default HTMX behavior (innerHTML) to return the new inner markup.
InsertCommand
We will not need this command. We choose the appropriate swap (beforebegin/afterbegin/beforeend/afterend/outerHTML) and return HTML.

"We will not need" as I understood it would be for commands that we will not provide guidance or documentation for how to replace or refactor its use, such as the CSS/JS commands.

Can you revert your changes and add the documentation?

Thanks for pushing me to open 1.6.x! We have things to remove that have been added in 11.3 to core.

Let's add a folder for extensions in docs. I'll move the debugging extension page there as well.

I think you are on the right track in #3. I'm doing that manually here: https://git.drupalcode.org/project/htmx/-/blob/1.5.x/modules/htmx_debug/... but now we have the Htmx object.

Thank you for prompting discussion of scope @sokru! The issue summary is a bit confusing for scope so perhaps we can come to agreement on that first. Our situation would be served by a configurable prefix value to the item id. What we need is to avoid collisions on entity id as we are serving two Drupal sites as one combined site.

A switch to UUID would be quite disruptive for existing users as it would require a re-index.

Do the maintainers want to support something as extensive as what search_api_solr is doing?

Update how to help

We are working with 8.0.0-alpha5 currently and Elastic 9.0.7. A field to prefix the document ID is important to our use case. Do the maintainers have guidance about how this issue could move forward? We're happy to help.

I know that predicting the future is hard. I'm wondering if 📌 Return only main content for endpoints designed to service htmx requests Needs work lands how many dedicated routes we will build. Will most requests use such dedicated routes? If we think that is likely, should we reverse the polarity of the data attribute added here and make the default to be no wrapper format parameter?

Nice! Thank you @nod_

All tests passing after applying suggestions.

Marking RTBC after implementing the test change from @larowan as he suggested. All tests passing

I think we also have to try to forecast our use of dedicated routes that will be made possible by 📌 Return only main content for endpoints designed to service htmx requests Needs work .

I would like to bring over this route from contrib /htmx/{entityType}/{entity}/{viewMode} and we should do something similar for blocks. Views uses dynamic routes. If we have all of that, I'm not sure how often we will need the wrapper format query parameter.

Added a simple functional test that installs the module and verifies the settings page loads. Test passes in D10 and D11.

Autoloading hooks in the file (modules/views_url_alias/views_url_alias.views.inc) is deprecated in drupal:11.2.0 and is removed from drupal:12.0.0. Move the functions in this file to either the .module file or other appropriate location. See https://www.drupal.org/node/3489765

The referenced CR → has the simple fix as moving these functions to the .module file. That seems appropriate for the scope of this issue.

fathershawn → created an issue.

I found myself wondering tonight if we should be building a clean url using URL::fromRouteMatch if we are going to build them for people as a convenience?

Here is what I see in a plain D10.5 site.

Since the change to the info.yml is the only change on the 3.x branch after 3.1.0 would you reconsider and make a 3.1.1 release? We could then upgrade to D11 and continue to work on the outstanding issues.

Fixed in 1.0.0

fathershawn → created an issue.

Thanks for the +1 on the route option!

With the display having it's dyanmic route option, here's how I dealt with exposed for data in the contrib module:

function htmx_form_views_exposed_form_alter(&$form, FormStateInterface $form_state, $form_id): void {
  $view = $form_state->get('view');
  if ($view instanceof ViewExecutable && $view->getDisplay()->getPluginId() === 'htmx') {
    foreach ($form['actions'] as &$action) {
      $type = $action['#type'] ?? '';
      if ($type === 'submit') {
        $htmx = new HtmxAttribute($action['#attributes'] ?? []);
        $htmx->get(Url::fromUri('internal:' . $form['#action']))
          ->include('form.views-exposed-form')
          ->select('div.views-element-container')
          ->target('div.views-element-container')
          ->swap('outerHTML');
        $action['#attributes'] = $htmx->toArray();
      }
    }
    $form['#attached']['library'][] = 'htmx/drupal';
    // Remove the action and method elements: we will send via htmx.
    $form['#action'] = NULL;
    unset($form['#method']);
  }
}

From Structure of routes → :

_format: Use this to check the type of the request. For example, you can have _format: json and only match requests where the '_format' query parameter is 'json'.

The intent of this issue is to be able to designate in a route definition that the route should always render its responses using HtmxRenderer. There is no dependency on the request. Also, the format for responses from HTMX requests is HTML.

We already see the need for such routes in the experimentation @nod_ is doing with Views. The wrapper format query parameter is extra baggage in filtered views along with all the filter parameters.

In the contrib module I have a dedicated View display that has a path. In ::getRoute I explicitly set the _htmx_route option. If we could do that based on the "use ajax" checkbox then none of the HTMX requests added in the view would need to add the wrapper format query parameter.

@nicxvan The plan for this MR is to add the trait and then include the trait in the FormBase class. We are not adding it to the ControllerBase in core because of concerns about BC but it could then be added to specific controllers as appropriate.

data-hx-get="attr(href)" is creative @nod_! Is it recreating the functionality of hx-boost?

If it helps, I also did some views work in the contrib module. There is a mini-pager: https://git.drupalcode.org/project/htmx/-/blob/1.5.x/src/Plugin/views/pager/HtmxMini.php and https://git.drupalcode.org/project/htmx/-/blob/1.5.x/htmx.module?ref_type=heads#L63

There's a display which makes use of the route option to always return a simple response: https://git.drupalcode.org/project/htmx/-/blob/1.5.x/src/Plugin/views/display/Htmx.php

And the exposed form is configured to update the view via htmx: https://git.drupalcode.org/project/htmx/-/blob/1.5.x/htmx.module?ref_type=heads#L17

test is passing

I looked at \Drupal\Core\Routing\RequestFormatRouteFilter and _format seems more about matching a requested format with routes that serve that format. I'm looking for something definitive on the route rather than dependent on the request.

I don't see a method nor a property for Request on ControllerBase. Am I missing something? Does this push us towards an argument resolver?

Test passes. CR created.

Thanks @larowan. That's +2 for a trait, plus where to start with it in core! I think the trait is easier for contrib developers to understand who might be doing something of controller/form context. Controller/form will be a 90% use case I bet.

This looks good to go to me.

@nod_ My concern is about a conflict with the state stored in the form and the state stored in the request URL. Consider a form with an input A that responds to user interaction and sends the values in a get request.

Focusing only on values for clarity

1. User sets A to 1
2. The input regenerates, containing data-hx-get="/path?A=1

Now if I set the value to 2 I am explicitly declaring that I will send 1. Isn't that confusing? It seems like the state encoded in the form should be the source of truth.

I have a concern with current url and query parameters.

If the form is using get, won’t the url for a new request contain the prior request parameters?

fathershawn → created an issue.

fathershawn → created an issue.

fathershawn → created an issue.

fathershawn → created an issue.

fathershawn → created an issue.

Problem/Motivation

Document how to implement ReplaceCommand using htmx

Proposed resolution

Document at https://www.drupal.org/docs/develop/drupal-apis/htmx/ajax-api-to-htmx/replacecommand →

Remaining tasks

Edit linked page and add documentation

User interface changes

None

Introduced terminology

None

API changes

None

Data model changes

None

Release notes snippet

None

fathershawn → created an issue.

fathershawn → created an issue.

fathershawn → created an issue.

fathershawn → created an issue.