3 ms·

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 c

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.

3 ms·

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 c

by mortallywounded 3y ago

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.