Yeah that makes more sense to me abstractly, but I think the Django built-ins are mostly POST focused

Here is my opinionated way to use django and htmx. Maybe it helps you. Feedback is welcome: https://github.com/guettli/django-htmx-fun/blob/main/README.md#naming-pattern

I think CBV is a better approach for HTMX; especially when working with forms, as it easily allows you to re-use the initial rendering logic. An exemplary CBV HTMX-approach I also adopted can be seen here https://github.com/Tiny-Tiny-App/tinytinylog/blob/develop/log/views.py On top of that I have a function-based

xapi/

where I swap out global partials.

Shameless plug: I'm giving a talk at pycon argentina tomorrow about JS fatigue and how htmx can help, here is the blog post it is based on (with all the research on the topic) http://hernantz.github.io/djangonauts-dont-let-djangonauts-write-javascript.html

Something curious is that I had this on my notes since 2017 back when htmx was known as intercooler.js, and now everyone seems to be talking about htmx at pycon/djangocon 😄

Thanks for the examples - that was really helpful

The CBV model is exactly what I had in my head for template management - one template for vanilla requests, and another for htmx ones

I think the piece I want to think more about is what verbs each CBV should handle

EG https://github.com/Tiny-Tiny-App/tinytinylog/blob/develop/log/views.py#L106

that to me feels like it should be right next to https://github.com/Tiny-Tiny-App/tinytinylog/blob/develop/log/views.py#L57

as a delete verb

and then a CBV becomes very close to a viewset in DRF terms, just handling html vs json

Like that's three urls, three classes to handle three verbs for a single datatype

I guess the devil is in the details of the forms since those are going to be somewhat different for each verb

Although for deleting the template might be very different.. hmm might be tricky

tweeted it out: https://twitter.com/htmx_org/status/1453059384272113667

Thanks, appreciate it 🙂

Hey, if I want to add some sort of callback for when an element gets swapped -- would I use something like 'htmx:afterSwap'?

that's the one

Hi! your Django htmx demo project does not appear in your great article : https://github.com/hernantz/django-htmx-demo.

Yeah! I was hoping to add some more features to test before sharing it, it's on my list 😄 thanks!

Hey folks, I have an idea for a tiny library to integrate the django rest framework and htmx. I call it

django-htmx-rest

(https://github.com/jdevries3133/django_htmx_rest) It'll be a pretty small library, because the two already go together very nicely, but there are a few key features: - content negotiator that also is responsive to the

Hx-Request

header - implement a

BrowsableHTMXRenderer

, which extends the DRF browsable API with frontend component development tooling, like viewport resizing, etc (think [storybook](https://storybook.js.org/)) - integrating the existing django-htmx library (https://github.com/adamchainz/django-htmx) with DRF, if there's anything to be done there (I'm not sure) - other misc. niceties, like maybe testing support Plus, strong documentation, to illustrate how Django + DRF + htmx can make REST dreams come true. I have gotten off to a very small start and hope to keep building it out to the extent that it supports another project I'm working on primarily, but if you're interested in the idea, it's MIT licensed and I welcome anyone who'd like to contribute! Any feedback on the idea is much appreciated too! Here is the repo link if you're interested in contributing: https://github.com/jdevries3133/django_htmx_rest

is your idea that you'd use a viewset and serve html from it?

So, DRF already has support for receiving and rendering html templates by passing a

template_name

kwarg to the drf

Response

constructor. Then, under the hood, drf has a content negotiation process which this library could hook into for determining what actually gets rendered based on the content_type and presence/absence of htmx headers

huh I didn't realize that

I've never used that property

Because of DRF's design, therefore, there are actually a lot of niceties you can build in that would make it easy to benefit from the library without actually importing anything from the library, necessarily. For example, replacing DRF's browsable API with something better for DRF + htmx, or serving htmx partials only in the presence of the

Hx-Request

header

Have you seen https://github.com/adamchainz/django-htmx speaking of that

I have, I mentioned that in my first message 🙂