it looked like you rolled your own header detection

right now, my library is more of a half-baked idea with only ~200 total lines of code, so the extent of my header detection is this:

python
def is_hx_request(request):
    return request.META.get("HTTP_HX_REQUEST") == "true"

so, I'm not really breaking a sweat there 😆

the django-htmx library integrates django and htmx, I'm hoping my library can integrate django-rest-framework and htmx in a way that doesn't step on the toes of django-htmx, and also doesn't depend on django-htmx

Ideally, users can install one or the other or both depending on their needs, but for now I'm just not listing django-htmx as a dependency until I need to for some reason

I've done a lot of drf work, but It's always been w/ json

if you render a form to a user and expect them to submit to the endpoint

would they use formenc or json?

DRF has all that content-negotiation already built-in. So, you know how when you are in the browsable api, it will show you a little form that you can fill out and submit? That form is sending data as formenc to the same endpoint as the one you are writing for json; the endpoint already can handle both

for some reason I thought that form was converting to json and ajaxing it in

I guess the only wierdish thing there then would be if you use a form or a serializer?

forms could theoretically autogenerate the html but I don't normally do that anyway

Again, drf already handles it! When you pass

template_name

as a kwarg to the

Response

constructor, drf passes

data

(first argument to the constructor) as context to the template behind the scenes if the request if for the content type of

text/html

So:

python
@api_view
def foo_view(request):
  return Response({'message': 'hello!'}, template_name="foo.html")

html
<h1>{{ messgae }}</h1>

If you make a request to that view with a

Accept: application/json

header, it will return

b'{"message": "hello!"}'

, but if you send a request to the same view with

Accept: text/html

, it will return

b'<h1>hello!</h1>'

The only caveat being that by default, the renderer for

text/html

is the BrowsableAPIRenderer, so actually by default, it would give the whole browsable api UI for

text/html

requests, but that behavior can be easily changed with settings

Hi I am trying to render a list again using the solution 3 here : https://htmx.org/examples/update-other-content/ It’s nearly working but after adding a new item to the list, there is a new ul inside the previous ul. Does someone have a working example with Django ? Thanks a lot in advance

maybe you need to use an

outerHTML

swap?

@User thanks but no it does not work. Basically, I am including the list like: {% include "account/addresses/addresses_list.html" %} Which looks like this: <ul id="addresses-list" hx-get="{% url 'account_addresses_list_hx' %}" hx-trigger="newAddress from:body" hw-swap="outerHTML" role="list" class="grid grid-cols-1 gap-6 sm:grid-cols-2 lg:grid-cols-3"> {% for address in addresses %} {% include "account/addresses/address.html" with address=address %} {% endfor %} And that view does: def account_addresses_list_hx(request): context = {} addresses = Address.objects.filter(user=request.user) context["addresses"] = addresses return render(request, "account/addresses/addresses_list.html", context) So nothing really complex. What am I getting wrong ? Thanks a lot in advance.

I think the problem is just that you wrote hw-swap instead of hx-swap.

@User Indeed, I just need a new pair of glasses. Thanks a lot !

Was this talk recorded anywhere?

Interesting. Did you btw explore how viable it is to use a DRF serializer as a form-serializer?

@User yeah, DRF serializers already have a lot of support for rendering forms: https://www.django-rest-framework.org/topics/html-and-forms/

this is why the amount of work for a htmx + rest framework library is not really much. The only thing I'd hope to see is a content negotiator that is responsive to the

Hx-Request

header (i.e., it returns a partial page for htmx and something else for normal requests), and a revamp of the browsable renderer where the something else returned for normal requests is a UI component explorer thing (alongside a BrowsableAPI data view). Everything else in terms of content negotiation, rendering, and the API a library user would interact with is already there in DRF. So, my vision for the library is just to drop-in a content-negotiator class and a render class that is a UI component explorer; quite minimal

My question may have been asked before, and if so I apologise. I am using django-tailwind package (which is awesome for minimizing css without scss). I have used htmx for dynamic reactive forms, and alpinejs for "vue-like" ui/ux. My question is: are htmx and alpinejs mutually exclusive? Has anyone done a matrix of where they overlap and when to use one or the other? Will developers in django always use both? I would prefer to use htmx only, to simplify the code, but also think that if it would compromise the ui/ux experience then I'll stick with both.

Hello, there is a spanish video on youtube: , source: https://twitter.com/hernantz/status/1453106733669363712?s=20 , other links: https://twitter.com/hernantz, http://hernantz.github.io/, https://github.com/hernantz/django-htmx-demo.

No they're not – they're complementary. HTMX simply handles AJAX requests and Alpine.js enhances frontend UX.

Thank you for your response, this is what I thought without tl;dr; research. 😂

Using tabs (described in htmx examples), I’ve loaded fetched content and it works great! However what doesn’t seem to carry over is the running of custom js module to process the fetched content -

Before the change to tabs, I loaded everything into a template file and at the end, the

extra_js

block looked like this:

{% block extra_js %}<script type="module" src="{{tree_populator_js}}"></script>{% endblock extra_js %}

A DOM node (filtered with

|json_script

) is passed to a function of

tree_populator_js

. With the tab pattern, can't seem to call the said function anymore. Hoping for tips in the right direction

Maybe this helps: https://htmx.org/api/#process