I had an idea for a possible new response header to help with the current limitations of the current HX-Request Header. It should be possible to add a simple new header without impacting any existing use cases and allow future users to simplify their backend logic
dev...MichaelWest22:htmx:new-header
if (target !== getDocument().body) {
const selectOOB = getClosestAttributeValue(elt, 'hx-select-oob')
const select = getClosestAttributeValue(elt, 'hx-select')
if (select) {
headers['HX-Request-Type'] = 'hx-select:' + select + (selectOOB ? ',' + selectOOB : '')
} else {
headers['HX-Request-Type'] = 'partial'
}
}This new response header can fill in the gap we have in understanding the response we need to return. This HX-Request-Type header in my example is only present if the target is not body. So for history restore requests and boosted requests that have no target override or requests that explicitly target body will return nothing and otherwise it will return 'partial'. Then in your backend you can just check if this header == partial as the only simple check you would need. If you happen to use hx-select feature then instead you get a comma separated list of selectors that need to be in your response but this should default to returning full page and not partials for the default use case. The great thing here is the info for knowing the response type needed is all in the client so we can easily expose it in this way.
Another cool feature is that users of hx-select could start out using hx-select for things while returning all simple full page responses and then over time update the backend routes to return partial responses based on the id selectors returned from this header to optimize performance without having to rework the templates to move from select pattern to normal partials.
It also gives htmx a new declarative descriptive power it didn't have before where you can have one full page template route url and multiple active htmx elements on the page with different hx-select tags defined can request from this one url different partial responses.
This Idea could also be made into a simple htmx extension that could then be installed by users who need better full/partial decision making but it would work best as either a core documented extension or as part of the core to make htmx easier to adopt.
There is also a recent change I helped make #3278 that added a new optional config to improve hx-request header behavior and this new header could be a cleaner alternative that could mean we didn't have to ship that new config possibly.
I have been unable to find any major gaps or issues so far with this solution with the only possible edge case being requests sent with hx-swap=none because the request does not expect any response in this case but I don't think this is a major.
I had an idea for a possible new response header to help with the current limitations of the current
HX-RequestHeader. It should be possible to add a simple new header without impacting any existing use cases and allow future users to simplify their backend logicdev...MichaelWest22:htmx:new-header
This new response header can fill in the gap we have in understanding the response we need to return. This HX-Request-Type header in my example is only present if the target is not body. So for history restore requests and boosted requests that have no target override or requests that explicitly target body will return nothing and otherwise it will return 'partial'. Then in your backend you can just check if this header == partial as the only simple check you would need. If you happen to use hx-select feature then instead you get a comma separated list of selectors that need to be in your response but this should default to returning full page and not partials for the default use case. The great thing here is the info for knowing the response type needed is all in the client so we can easily expose it in this way.
Another cool feature is that users of hx-select could start out using hx-select for things while returning all simple full page responses and then over time update the backend routes to return partial responses based on the id selectors returned from this header to optimize performance without having to rework the templates to move from select pattern to normal partials.
It also gives htmx a new declarative descriptive power it didn't have before where you can have one full page template route url and multiple active htmx elements on the page with different hx-select tags defined can request from this one url different partial responses.
This Idea could also be made into a simple htmx extension that could then be installed by users who need better full/partial decision making but it would work best as either a core documented extension or as part of the core to make htmx easier to adopt.
There is also a recent change I helped make #3278 that added a new optional config to improve hx-request header behavior and this new header could be a cleaner alternative that could mean we didn't have to ship that new config possibly.
I have been unable to find any major gaps or issues so far with this solution with the only possible edge case being requests sent with hx-swap=none because the request does not expect any response in this case but I don't think this is a major.