Problem/Motivation

When we intentionally build responses to service HTMX requests it is the main content that we want to send. We don't want or need all the surrounding blocks that Drupal generates. In such cases we need to be able to produce a simple response with the main content.

Proposed resolution

Use the new renderer created in #3522597: Return only main content for selected htmx requests to render these responses.

Create an EventSubscriber that runs before \Drupal\Core\EventSubscriber\MainContentViewSubscriber which uses this renderer if the route is designated as an _htmx_route.

Remaining tasks

Implement

User interface changes

None.

Introduced terminology

None.

API changes

TBD

Data model changes

None at this time.

Release notes snippet

Issue fork drupal-3544632

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

fathershawn’s picture

Status: Needs review » Needs work
fathershawn’s picture

Issue summary: View changes
fathershawn’s picture

Issue summary: View changes

fathershawn’s picture

Status: Needs work » Needs review

Test passes. CR created.

nod_’s picture

Instead of a custom _htmx_route, maybe we can use _format: drupal_htmx or _format:htmx in the route definition.

See how lupus_renderer handles that, creating a new _format:custom_elements for api responses.

fathershawn’s picture

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.

fathershawn’s picture

nicxvan’s picture

I'm not quite following the comment on 8 and I'm not sure 9 fully addresses it.

I assume _nod meant something in here https://git.drupalcode.org/project/lupus_ce_renderer/-/blob/2.x/src/Even...

There are several event subscriber but I didn't see one that he meant.

Maybe we can get some clarity here.

fathershawn’s picture

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.

nod_’s picture

I think I found the sweet spot for using/cleaning the extra parameters in #3538544: Ajaxify the user interface translation forms. If wrapper format is not a problem we still have to manage ajax_page_state.

Also if we avoid dedicated endpoints for views, we should be able to simplify the backend too.

I agree that using _format is a bit of a stretch so I don't mind a dedicated key.

fathershawn’s picture

Thanks for the +1 on the route option!

With the display having it's dyanmic route method, this route option was an advantage in the contrib module:

  /**
   * {@inheritdoc}
   */
  protected function getRoute($view_id, $display_id) {
    $route = parent::getRoute($view_id, $display_id);

    // Explicitly set HTML as the format for Page displays.
    $route->setRequirement('_format', 'html');

    if ($this->getOption('use_admin_theme')) {
      $route->setOption('_admin_route', TRUE);
    }

    // This is an HTMX route.
    $route->setOption('_htmx_route', TRUE);

    return $route;
  }
godotislate’s picture

Status: Needs review » Needs work

Couple small comments on the MR. I also reviewed the CR and made a couple small edits.

fathershawn’s picture

All tests passing after applying suggestions.

fathershawn’s picture

Status: Needs work » Needs review
godotislate’s picture

1 small suggestion to remove constructor docblock. OK to self-RTBC after that.

godotislate’s picture

Status: Needs review » Reviewed & tested by the community

lgtm.

larowlan’s picture

Status: Reviewed & tested by the community » Needs review

Just one question on the MR, fine to self RTBC

fathershawn’s picture

Status: Needs review » Reviewed & tested by the community

Setting back to RTBC per #20

  • larowlan committed 0fdac146 on 11.3.x
    Issue #3544632 by fathershawn, nod_, godotislate, larowlan: Return only...

  • larowlan committed 2fa6a5b7 on 11.x
    Issue #3544632 by fathershawn, nod_, godotislate, larowlan: Return only...

larowlan’s picture

Version: 11.x-dev » 11.3.x-dev
Status: Reviewed & tested by the community » Fixed

Committed to 11.x and backported to 11.3.x
Published the change record
thanks!

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

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

Maintainers, credit people who helped resolve this issue.

Status: Fixed » Closed (fixed)

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

gábor hojtsy’s picture