Add an additional middleware after this one.... if NOT request.htmx then do something...

I actually tried that, like set some headers in request object in views and then in template_response hook, but Django refused to save them. I wanted to change process_request methods somewhere, but i don't think that'd help

But anyways, htmx actually helped me to do some stuff without even touching javascript, so it is a good tool ;D

Im using separate views for any partial updates, that is one way...

Can you do an outerHTML swap on 'body'?

"` {% if user.is_authenticated %} <a href="{% url 'logout' %}" hx-post="{% url 'logout' %}" hx-target="body" hx-push-url="true" hx-headers='{"X-CSRFToken": "{{ csrf_token }}"}' hx-swap="outerHTML" class="button is-primary is-outlined is-small">Logout {% endif %} '"`

the base template where this link is displayed has my login page has . Whenever I log out the login page is showing the class in the body tag and vice versa when i login.

what am i missing?

I guess I can resolve this with by adding "HX-Refresh":true to the headers....

Nvm I don't know if working correctly or not....

I do inner swap on my body for SPA navigation, so classes are preserved. I feel body is to important a piece to be a moving part, but this is just my opinion

I see you're doing both href and hx-post on the , if this is for progressive enhancement as hinted by the hx-push-url=true, you might need hx-boost https://htmx.org/attributes/hx-boost/

also, logout could be a use case that mandates a full page reload, that might be less of a headache for various reasons

Your opinion has quickly became mine as well. I had hx-boost set as true in the body tag, but have since removed. I will handle each interaction on a case by case basis.

Hey guys! hope you are having a good day. Do you know if there is any way to send two forms at the same time? I could use a custom trigger event and include the second form with hx-include but by doing this it skips the validation of the required fields. Any suggesting is welcome

Do you mean send two http requests, or 1 request with 2 forms in it?

@bitter-beard-2325 does the second form depend on some values of the first ?

@bitter-beard-2325 what’s the use case? Is either form dependent on the other? If so why are they not the same form?

how do you all handle routes that return html fragments? Say I have a route that returns a component to be rendered, should I place it at a subpath?

paths:
/
/app/view1
/app/view2
/components/card1
/components/graph1

Or does this sort of distinction end up not really mattering

With our first htmx project at work, I went with separate endpoints as you’ve shown above. This worked well and created separation between full page and fragment responses, but it resulted in a lot of logic and context duplication. For our second project, I went with endpoints that return either a full page or a fragment depending on whether HX-Request was in the request headers. There were a few exceptions to this, such as opening a modal dialog (which will never be full page) - if e.g.

modal?=open

is requested on page load, the request hits the main endpoint which returns the full page plus a hidden element with

hx-trigger=‘load’

to then hit the modal fragment endpoint.

So I would agree that this distinction doesn’t matter too much - it just depends what you feel the best approach is. Either way, as you said, separating any fragment endpoints from full page ones is a good idea

^ @abundant-dog-96915 that’s my two cents anyway

thanks for the writeup. switching on HX-Request is a good idea. The model pattern as well

I realised that I’d need an endpoint for each fragment when I realised my page could have multiple fragments. I was thinking that there’s a case to be made for an extension that lets you specify an

hx-fragment

attribute that adds a header

That’s what I’m currently doing as well. I use Django-render-block to mark blocks in my template, and I send the block name in a header for most HTMX requests, and then on the Django side I have a type of httpresponse class that is aware of blocks and uses the one from the header (or an override if supplied)

How are you setting the header?

Hx-headers attribute

I realised we also get the ID of the triggering element in the

Hx-Trigger

header as well. That means if your elements had the same ID as your fragment then you could use that.

Might be an interesting pattern to explore.