4 ms·

it's true that htmx is mainly focused on partial HTML replacement and we usually recommend that people load javascript and CSS up up front and/or adopt inline s

it's true that htmx is mainly focused on partial HTML replacement and we usually recommend that people load javascript and CSS up up front and/or adopt inline scripting solutions for locality of behavior[1], but htmx also has a head-support extension: https://htmx.org/extensions/head-support/ https://htmx.org/extensions/head-support/ for htmx 2.0 i'm integrating this functionality into the core, it seems useful enough to be there. The extension is based on the head morphing algorithm of idiomorph: https://github.com/bigskysoftware/idiomorph/ https://github.com/bigskysoftware/idiomorph/ which 37Signals is going to integrate into Turbo for v8: https://twitter.com/ben_pylo/status/1717975035669876790 https://twitter.com/ben_pylo/status/1717975035669876790 [1] - https://htmx.org/essays/locality-of-behaviour/ https://htmx.org/essays/locality-of-behaviour/

mortallywounded 3y ago
I get it-- that will enable you to resolve the clash (or at least make it possible to detect and do something about it). However, it does feel messy/ugly when compared to how HTMX is generally portrayed (do some action, an HTML fragment in response). Now, you'll return an HTML fragment and/or an optional head element to merge? It feels a bit yucky, but I understand why it will be done. A cleaner approach may be leveraging the HX-Trigger response header in some way? I feel like the app version could be specified and if it changes, HTMX would know and could trigger an event that could be specified by the user. I don't really like either solution.. perhaps the head merging would be more correct, but damn it feels off =/
- recursivedoubts 3y ago
  there are typically three major types of requests w/ htmx: - a full page request via an hx-boost, where head processing makes sense - a full page request via an hx-get, etc. where hx-select is used to pick out a piece, where head processing probably doesn't make sense - a partial of HTML, where head processing doesn't make sense we will optimize head support for the first case, hx-boost based requests, and make the latter cases possible via configuration if the user wants. htmx is much less opinionated than other frameworks on these things, i try to make it a hypermedia swiss army knife, which makes it a little ugly at times, but I don't like forcing people to do things a certain way for better or for worse using HX-Trigger to do a full page refresh on an application version change is a common pattern, but is something you would build on top of htmx, not something htmx would provide out of the box. it is focused on generalizing hypermedia controls and patching a few gaps in HTML, and that's about it.

mortallywounded 3y ago

I get it-- that will enable you to resolve the clash (or at least make it possible to detect and do something about it). However, it does feel messy/ugly when compared to how HTMX is generally portrayed (do some action, an HTML fragment in response). Now, you'll return an HTML fragment and/or an optional head element to merge? It feels a bit yucky, but I understand why it will be done. A cleaner approach may be leveraging the HX-Trigger response header in some way? I feel like the app version could be specified and if it changes, HTMX would know and could trigger an event that could be specified by the user. I don't really like either solution.. perhaps the head merging would be more correct, but damn it feels off =/

recursivedoubts 3y ago
there are typically three major types of requests w/ htmx: - a full page request via an hx-boost, where head processing makes sense - a full page request via an hx-get, etc. where hx-select is used to pick out a piece, where head processing probably doesn't make sense - a partial of HTML, where head processing doesn't make sense we will optimize head support for the first case, hx-boost based requests, and make the latter cases possible via configuration if the user wants. htmx is much less opinionated than other frameworks on these things, i try to make it a hypermedia swiss army knife, which makes it a little ugly at times, but I don't like forcing people to do things a certain way for better or for worse using HX-Trigger to do a full page refresh on an application version change is a common pattern, but is something you would build on top of htmx, not something htmx would provide out of the box. it is focused on generalizing hypermedia controls and patching a few gaps in HTML, and that's about it.