- ๐ณ๐ฑNetherlands idebr
@Wim Leers this issue was marked fixed but the merge request is still open. Could you merge it and tag a new release?
Automatically closed - issue fixed for 2 weeks with no activity.
- ๐บ๐ธUnited States FatherShawn New York
@kevinquillen At the request of @nod_ we are discussing that in ๐ [POC] Implementing some components of the Ajax system using HTMX Active
- ๐บ๐ธUnited States kevinquillen
What is the easiest or smallest POC to proof out here?
- ๐ฌ๐งUnited Kingdom Rob230
My problem was stage_file_proxy was capturing the requests and presumably fetching an old file from the production environment. I had to update the module (to resolve a bug) and then add css and js to excluded extensions.
- ๐บ๐ธUnited States agarzola
Assuming youโve removed the
version
key from the library definitions in your modules/themesโ*.libraries.yml
files, then I suggest looking into some of the issues linked in the comments from earlier this year. - ๐ฌ๐งUnited Kingdom Rob230
This doesn't work.
I have the change to nginx to pass CSS generation to Drupal (otherwise it has a 404).
The change discussed in this issue is added in Drupal 10.1. I can see it in AssetGroupSetHashTrait.php - it checks for the version being -1. The version is -1 if it's explicitly set to that, or if there is no version specified. I've stepped through it with Xdebug and it's hitting it, and adding a hash of the file contents as the version.
Yet, the generated CSS does not contain the CSS of the file. It's old and contains none of the new CSS that has been added.
I don't understand what to do any more. Since upgrading to Drupal 10 I can't get new CSS changes to appear. The changes exist in the source .css file, but never appear in the aggregated CSS generated by Drupal.
- ๐บ๐ธUnited States FatherShawn New York
Some more thoughts on the questions raised in #43 ๐ฑ [Plan] Gradually replace Drupal's AJAX system with HTMX Active , #44 ๐ฑ [Plan] Gradually replace Drupal's AJAX system with HTMX Active , and #45 ๐ฑ [Plan] Gradually replace Drupal's AJAX system with HTMX Active above:
However, Drupal pages have long been dependent on a strong relationship between
<head>
and<body>
content, with different JS/CSS bundles from page to page, for example.I think the existing concepts of
ajax_page_state
ought to workI think I do have this working with
ajax_page_state
in my contrib implemenation. HTMX includes a header,HX-Request
with every request it makes. I have a response subscriber that only processes the response if this header was included on the request. On HTMX requests, the response is processed using logic adapted from our currentAjaxResponseAttachmentsProcessor
. The resulting asset data is attached to the response as JSON.Now, you can indeed push changes to
<head>
using multiple response top-level element with the hx-swap-oob attribute, but that needs an ID on each modified target, which needs to pre-exist on the source page, which seems like a lot of potential trouble.Perhaps HTMX has evolved it's capabilities as all my exposure is recent. The
<script>
tag containing the JSON asset data is wrapped with<div hx-swap-oob="beforeend:body"></div>
as part of the response processing. The value on hx-swap-oob defines the swap strategy and target that is used for the inner HTML of the<div>
. The result is a script tag appended to the end of the body. HTMX fires an event,htmx:oobAfterSwap
, after it has processed and inserted our asset JSON. Currently I have a listener for this event that uses theloadjs
library we already use to process and attach the assets.which is likely to interfere with our use of behaviours
HTMX fires another event,
htmx:load
after each response has finished processing. I'm currently using an event listener on this event to call ourDrupal.attachBehaviors()
. All of this is verified in a test.I have less experience with the JS side of our core code and @nod_ said the JS here could be improved ๐ฑ [Plan] Gradually replace Drupal's AJAX system with HTMX Active so please offer improvements either in ๐ [POC] Implementing some components of the Ajax system using HTMX Active or in the HTMX module issue queue โ .
A related issue will be history support. If we enable back/forward navigation with the hx-push-url we probably need to make it so that the cacheability headers, among others, be updated for updated pages, because the result will often not match the source. Think, for example, of a search page filled with results: the results will at least carry cache tags for the results but the original page will not.
If we did enable history support, what I think is important is that the url that is updated in the browser should be able to recreate the current display. Using the example of a search page, we commonly add query parameters to such urls containing the search terms. I don't believe that we are currently updating anything in the header on ajax responses, other than header JS included in the differential assets payload. If we find that we do want to add fully harmonizing the head section, we could explore adapting the HTMX head-support extension for our specific needs.
- ๐ซ๐ทFrance fgm Paris, France
big pipe placeholders (which would be another thing to try a conversion of fairly early on
Indeed, that reminds me of another potential difficulty, which is the use of the
hx-trigger="load" or "revealed" or "intersect"
relying on the default browsers events or the intersection API, which is likely to interfere with our use of behaviours to support multiple loads per context like document or other node e.g. with BigPipe. - ๐ฌ๐งUnited Kingdom catch
However, Drupal pages have long been dependent on a strong relationship between and content, with different JS/CSS bundles from page to page, for example.
So this is true, but for AJAX requests we already deliver assets separately outside the
head
markup and it's also the case for big pipe placeholders (which would be another thing to try a conversion of fairly early on since that relies entirely on the AJAX system with a small amount of custom js)..I think the existing concepts of ajax_page_state ought to work - i.e. we track the libraries that have already been sent, and when new libraries are sent, they go through the asset rendering system and are sent as a new aggregate - both script and stylesheet link tags are allowed in the body of the document so they can be sent with the HTML (or injected via js wherever). Drupal settings and HTML head links (favicon, feeds etc.) are a bit different though so definitely need to figure out those.
- ๐ซ๐ทFrance fgm Paris, France
Before doing a lot with that, there's an issue with HTMX which I would not know how to solve for now : HTMX basically makes the assumption of a stable
<head>
section across pages, except for the title: when elements are swapped by ahx-boost
, possibly inheriting if from<body hx-boost="true">
, all<head>
content in responses is dropped except for the<title>
element.However, Drupal pages have long been dependent on a strong relationship between
<head>
and<body>
content, with different JS/CSS bundles from page to page, for example.Now, you can indeed push changes to
<head>
using multiple response top-level element with thehx-swap-oob
attribute, but that needs an ID on each modified target, which needs to pre-exist on the source page, which seems like a lot of potential trouble.Even without using
<body hx-boost="true">
, partial replacement responses are often likely to require<head>
changes.I think this is something which needs to be solved earlier than later for a PoC, to outline the patterns that can be used to work around that discrepancy between the HTML model and the Drupal model.
- ๐ฆ๐บAustralia sime Canberra
My first encounter with htmx was watching theprimeagen review it through non-drupal lens. To me it felt like the DX is better than Drupal core and very much made me think about how comparitively hard Drupal ajax is.
- ๐ซ๐ทFrance nod_ Lille
Thanks! That's an interesting project. Haven't had time to dig into the code but happy to see alternative takes being explored.
I'm personally for htmx because the philosophy is aligned with Drupal and what we try to do. And I like that a lot of things live in the markup instead of hidden away In a js object somewhere.
- ๐ฌ๐งUnited Kingdom hugronaphor
Glad to hear there is a consensus that existing approaches to handle ajax are outdated and not DX friendly.
This is the exact reason why a while ago when I needed to build an SPA-like app, I needed something more mature and modern.I did look at that time at htmx but it felt to me that it's not the right solution to use especially that I have found out about Livewire. As a result I have ported it to Drupal as Wire.
The main benefit is that it's architecture has been tested and iterated for years already by Laravel community and it can handle any task mentioned here including form submissions, reacting/emitting events, web-socket, ... in fact Symfony ecosystem got their own Livewire inspired Live Components
To be clear, I'm not saying that I want my Wire in core instead of playing with htmx but I think we should look at the scope broader and consider something in between Wire and Symfony's Live components. Huge benefit on top of being able to create dynamic interfaces with ease, Laravel and Symfony developers would have a familiar tool in Drupal's core.
- ๐บ๐ธUnited States FatherShawn New York
Thanks for the support and clear guidance @nod_ :)
I opened ๐ [POC] Implementing some components of the Ajax system using HTMX Active
- ๐ณ๐ฟNew Zealand quietone New Zealand
The functions in the title were removed from core and replaces in the ThemeHandler service. And the rebuilding of the theme data is deprecated in Drupal 10, to be removed in Drupal 12. There is more information int the following change records.
https://www.drupal.org/node/2150863 โ
https://www.drupal.org/node/3413196 โTherefor, closing as outdated.