RenΓ© Moser (resmo) レネMar 16

To my younger me: Please use 2 different resource URI for #htmx and non-htmx requests. It makes development much easier later even tough you could destinquish by htmx headers, you definitely have more "control" and less surprises as things grow.

e.g. /todos/<id> and /hx/todos/<id>

Show threadCuboci πŸ³οΈβ€πŸŒˆ   
@resmo Interesting advice. I went the exact opposite way because I found that there was a lot of duplication in my handlers.
But lately, as my project has grown I'm realising that my handlers contain too much business logic anyway and I should refactor them. Doing that would probably make your approach a much better choice.
Mar 16 at 10:51amWeb
Show threadDaneliMar 16
@cuboci @resmo Let the handlers only render stuff, keep the logic separate. I am working with both header based routing and URL path based routing, both works fine as long as the handler only implements a "router backend interface".
Show threadCuboci πŸ³οΈβ€πŸŒˆ   Mar 16
@sontags @resmo I generally try to do that but it's difficult to judge where to draw the line.
I need a lot of different data for my templates (using #templ) and I try to avoid doing a lot of logic in those. But the backend data model doesn't trivially map to the view data model, so something has to do the conversion. It's not always clear where to push that logic.
Show threadRenΓ© Moser (resmo) レネMar 16

@cuboci @sontags

regarding "business" or core logic, it comes usually natural if you also implement a rest or graphql api and share the same logic --> core logic. in my web controller I usually ask myself is this code only releasted to UI? so then it's okay here.

Show threadDaneliMar 16
@resmo @cuboci yeah, that seems about right
Show threadCuboci πŸ³οΈβ€πŸŒˆ   Mar 16
@resmo @sontags And if you don't it gets a lot muddier πŸ˜…
Show threadRenΓ© Moser (resmo) レネMar 16
@cuboci there are a few cases where you may not control if boosted or htmx request and then if you depend on one single resource URI it may get a bit ugly. htmx is still quite new and a few things are not yet fully clear, e.g. hx-location, docs says its like a redirect like you would have clicked a normal a-href but it seems it also adds a hx-request header so it's not really a normal a-href, so what is it?
Show threadCuboci πŸ³οΈβ€πŸŒˆ   Mar 16

@resmo Actually, the docs say it's like clicking a `<a href=... hx-boost="true">` and also "This response header can be used to trigger a client side redirection without reloading the whole page."

So in that case I think it's pretty clear. If you really want a full redirect you can use HX-Redirect.

But I get your point, it may indeed be clearer to separate HTMX and non-HTMX endpoints.

Btw, I don't consider HTMX to be a particularly new project. It's already been at version 2.x for almost two years, 1.0.0 was released in 2020, and its predecessor - intercooler.js - had its 1.0.0 release in 2016. So roughly 10 years in one form or another. That's a lot these days where there's a new hyped client-side JS framework every other week.

Show threadRenΓ© Moser (resmo) レネ6d ago

@cuboci Well, yeah for a js framework it's proably long enough.

there are 2 headers, hx-redirect and hx-location, hx-redirect does a redirect but the issue is (but probably I did it wrong), it also ads a header of hx-request=true so if you have 2 identical URI for hx requests and non-hx requests, it would take the hx entry point and is not what the docs says IMHO.

Show threadCuboci πŸ³οΈβ€πŸŒˆ   6d ago
@resmo I seem to misunderstand something here. HX-Redirect and HX-Location are response headers, aren't they? So it would be you who set either in your handlers.
HX-Request is a request header set by HTMX, and I can't find any HTML attribute hx-location or hx-redirect that would set that. Are you talking about hx-boost?
Show threadRenΓ© Moser (resmo) レネ6d ago

@cuboci no, let me clarify my thoughts:

I set a response header hx-redirect, htmx will trigger a client side redirect. right.

however as written here https://htmx.org/reference/#headers the request header hx-request is always true

that means (IMHO) it is just like a hx-get requests, not a "normal" http get request (only diff is hx-request request header=true)

as a result, your handler for hx requests is the entry point, not a non hx-request entrypoint, which may be unexpected and this is what I see.

</> htmx ~ Reference

htmx gives you access to AJAX, CSS Transitions, WebSockets and Server Sent Events directly in HTML, using attributes, so you can build modern user interfaces with the simplicity and power of hypertext htmx is small (~14k min.gz’d), dependency-free, extendable, IE11 compatible & has reduced code base sizes by 67% when compared with react

Show threadCuboci πŸ³οΈβ€πŸŒˆ   6d ago
@resmo Ah, I see what you mean. But HX-Request being always true applies to HTMX requests triggered by hx-* attributes on an element. It doesn't apply for a request as a consequence of HX-Redirect. That will be a regular client-side request.
I just quickly verified that. HX-Request is not set for HX-Redirect, it is however set for HX-Location (along with HX-Current-URL)
Show threadRenΓ© Moser (resmo) レネ6d ago
@cuboci Hmm, maybe I messed up and used HX-Location instead of HX-Redirect... πŸ€”πŸ«£ let me verify again
Show threadCuboci πŸ³οΈβ€πŸŒˆ   5d ago
@resmo Just out of curiosity, did you find out the cause?
Show threadRenΓ© Moser (resmo) レネ5d ago
@cuboci yep, pebkac πŸ₯³
Show threadCuboci πŸ³οΈβ€πŸŒˆ   5d ago
@resmo Oh how many times that guy reared his ugly head in my code πŸ˜