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
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:
- 3544632-return-only-main
changes, plain diff MR !13283
Comments
Comment #2
fathershawnComment #3
fathershawnComment #4
fathershawnComment #5
fathershawnComment #7
fathershawnTest passes. CR created.
Comment #8
nod_Instead of a custom _htmx_route, maybe we can use
_format: drupal_htmxor_format:htmxin the route definition.See how lupus_renderer handles that, creating a new
_format:custom_elementsfor api responses.Comment #9
fathershawnI looked at
\Drupal\Core\Routing\RequestFormatRouteFilterand_formatseems 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.Comment #10
fathershawnComment #11
nicxvan commentedI'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.
Comment #12
fathershawnFrom Structure of routes:
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_routeoption. 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.Comment #13
nod_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.
Comment #14
fathershawnThanks 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:
Comment #15
godotislateCouple small comments on the MR. I also reviewed the CR and made a couple small edits.
Comment #16
fathershawnAll tests passing after applying suggestions.
Comment #17
fathershawnComment #18
godotislate1 small suggestion to remove constructor docblock. OK to self-RTBC after that.
Comment #19
godotislatelgtm.
Comment #20
larowlanJust one question on the MR, fine to self RTBC
Comment #21
fathershawnSetting back to RTBC per #20
Comment #25
larowlanCommitted to 11.x and backported to 11.3.x
Published the change record
thanks!
Comment #28
gábor hojtsy