Problem/Motivation

Adding interactivity with HTMX will sometimes involve displays that depend on which element triggered the request. HTMX intends to return such data in a request header HX-Trigger and HX-Trigger-Name.
HTMX also provides information on the target of new markup in the HX-Targetheader.

We are assigning the value of HX-Trigger-Name to the _triggering_element_name input value in #3535173: Support dynamic forms using HTMX.

Challenges

  1. HTMX is designed to work with any element and the name attribute is added only to form elements.
  2. HTMX provides the HX-Trigger and HX-Target headers. HX-Trigger and HX-Target both use the ID attribute but these can be programmatically altered in Drupal. In the HTMX contrib module we adjusted these header values in our javascript to use the data-drupal-selector value.
  3. Developers will want to access this information both in both form building and display building.

Proposed solutions

Create a trait and add it to FormBase.

The data-drupal-selector system seems to grow out of the Ajax API that we intend to deprecate.

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

Issue fork drupal-3544486

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Comments

fathershawn created an issue. See original summary.

fathershawn’s picture

Title: Add a methods to get info about which elements involved in an HTMX Request » Add a methods to get info about which elements are involved in an HTMX Request
fathershawn’s picture

Issue summary: View changes
richgerdes’s picture

@fathershawn,

Per our conversation at DrupalNYC Contribution day, i think it would be helpful to have a trait to parse the request headers. Something like...


trait HTMXHeaders {
  public function getHtmxTrigger(): ?string;
  public function getHtmxTriggerName(): ?string;
}

These functions can look for the request ($this->request ?: \Drupal->getRequest()) and then get the headers.

We also talked about the helpfulness of a getHtmxTriggerElement($build): ?array function which could locate the render element and to allow access to properties or data, but decided this wasn't critical at this time.

fathershawn’s picture

Title: Add a methods to get info about which elements are involved in an HTMX Request » Add methods to get info about which elements are involved in an HTMX Request
fathershawn’s picture

Issue summary: View changes
larowlan’s picture

Would the primary use case for this be in controllers and form builders?

In which case I think a trait and adding that trait to FormBase and ControllerBase (that already have the request) feels reasonable.

The alternative is we add a new argument resolver to http_kernel.controller.argument_resolver and a HtmxHelper value object that can resolve from the current request.

That would allow people to typehint their controllers with `HtmxHelper $helper` and it would magically resolve like you can do for Request.

fathershawn’s picture

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.

fathershawn’s picture

Issue summary: View changes
fathershawn’s picture

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?

fathershawn’s picture

Issue summary: View changes

fathershawn’s picture

Status: Active » Needs review

test is passing

fathershawn’s picture

fathershawn’s picture

Issue summary: View changes
smustgrave’s picture

Status: Needs review » Needs work
Issue tags: +Needs Review Queue Initiative

Left some minor comments on the MR.

fathershawn’s picture

Status: Needs work » Needs review
nicxvan’s picture

Two questions on the MR.

I the plan to introduce the trait here and then add it to form and controller etc later?

Can we create follow ups for those with some notes for how to test it in deeper requests?

fathershawn’s picture

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

nicxvan’s picture

Status: Needs review » Reviewed & tested by the community

I think this is good, @fathershawn pointed out I missed this was already added to FormBase

larowlan’s picture

Status: Reviewed & tested by the community » Needs review

Just one comment on the MR, fine to self RTBC after that I think

fathershawn’s picture

Status: Needs review » Reviewed & tested by the community

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

  • nod_ committed 5edaa75e on 11.x
    Issue #3544486 by fathershawn, richgerdes, larowlan, smustgrave, nicxvan...
nod_’s picture

Status: Reviewed & tested by the community » Fixed

Hey a HTMX issue I can commit, yay!

Committed 5edaa75 and pushed to 11.x. Thanks!

Now that this issue is closed, please review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, please credit people who helped resolve this issue.

Status: Fixed » Closed (fixed)

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