movieListChanged scalable

[nerdoc]

H Benoit,
thanks for this great article, it freed my mind ;-)

A question rose up: You use the movieListChanged custom event and included it into the header. Do you add custom events per page, just for the things that are needed? Or do you recommend to create "generic" events (listUpdated) with attributes - to keep their list a little bit smaller?

I am considering this pattern in a larger (open source) application and just want to make the "right" decision.
Thanks again for your great code.

[bblanchon]

Hi @nerdoc,

I don't have a definitive answer on event naming, and I'm still experimenting with my projects.
For example, here, I used only one event moveListChanged, but I could have used three events movieAdded, movieUpdated, and movieDeleted.
My intuition tells me that the three events are better, but in practice, I could not find any advantage; that's why I decided to use the simplest solution in the video.

However, I would never use a generic name, like listChanged, because my pages often contain multiple lists.

Best regards,
Benoit

[nerdoc]

Ok, so events in this case would be page specific - or topic-specific.
I just ask because - I've been through Django-unicorn, django-sockpuppet, eventstream, turbo-django, reactor, djhtmx, and many others, tried them all. They all have flaws and weaknesses, and in the end I stayed with HTMX (and django-htmx for convenience).
But I really don't understand why noone hasn't created a high-level framework (like Unicorn) using HTMX, this would be really great. everything is there, the pieces just have to be put together.
And your ideas here are a really great milestone for such a framework.

BTW, a generic name like listChanged could have the list id as payload. It's just a design question. Would have the advantage to build the HX-Trigger header into generic Mixins (which I tried around a bit with yesterday).

[bblanchon]

I'd love to read your conclusion about the different frameworks you tried.
I knew about some of them but never had the opportunity to try them.

Frameworks are better implemented in new projects because they are often difficult to fit existing projects.
That's why I prefer relying on HTMX as a library: it allows me to enhance my application progressively.

I'm really satisfied with the Django+HTMX combo. I only miss support for dependent/cascaded fields at the Form level. I made it work by creating custom form mixins, but I wish I could use a less hacky solution.

[nerdoc]

I'd love to read your conclusion about the different frameworks you tried.

Oh yes, and how I tried...

Sockpuppet:

Pros:

• clean, component based setup
• very interesting technology, channels/websockets & morphdom
• friendly community
• good documentation

Cons:

• complicated setup
• buggy
• not possible to piggy-back code, like HTMX' oob-swaps
• albeit community is friendly, sometimes not helpful for beginners, as they expect advanced knowledge.

Django-Unicorn

Pros:

• extremely good integrated into Django
• clean, component based setup
• very clean setup and encapsulation
• very friendly community
• very good documentation

Cons:

• slow. Just clicking on a counter repeatedly and fast overwhelms the ajax requests.
• oob-swaps not possible. Only changeable things are inside the element/component.
• buggy when you try to swap element that has the focus.

Reactor

Pros:

• cool technology: channels, server-side-push & sync
• easy setup
• clean, component based setup

Cons:

• not well maintained, used by almost nobody besides the author (somewhere?)
• almost no documentation

djhtmx

(same author as Reactor)
Pros:

• nice idea: components using HTMX

Cons:

• badly maintained
• bad documentation

turbo-django

A channels using streaming library which adds push messaging possibilities to Django. <turbo-frame>s are like Unicorn components that capture links inside them and reload only the frame, not the whole page.

Pros:

• well-designed API, albeit a bit abstract and sometimes complicated to understand
• more or less good documentation, but could be better
• event driven programming possible: react on Django model updates -> push HTML to client -> update DOM.

Cons:

• Only links and forms can send events to the server, unlike HTMX, where every HTML tag has this possibility. So you can't implement things like "click on that div" without using other Js frameworks.
• <turbo-frame>s are not backend components with methods, no encapsulation like in Unicorn. You have to use normal views.

django-htmx / HTMX

Pros:

• really versatile and mighty tool
• easily to start with django-htmx by @adamchainz
• killer feature oob-swap
• faaaast...

Cons:

• when using Django, poor support for "djangonish" thinking, no components, no support for Python objects (like in Unicorn)
• needs boilerplate code in every component you create, few DRY possibilities
• somehow encourages you to produce spaghetti code

So my conclusion is: I'll probably stay with HTMX, and try to not let my weaker self produce too much spaghetti code.
If there was a fairy with one wish: Why the heck did nobody yet create a django component library like Unicorn, based on HTMX?
This would be the best of all worlds:

• Components using Django's template language (like Unicorn, Sockpuppet)
• Python side components with methods that can be called by the frontend (like Unicorn, Sockpuppet)
• HTMX or Turbo for interaction (existing technology)
• additionally oob-swaps - you need that for e.g. messaging, or just updating other DOM elements when sending HTML over the wire

So if Unicorn components would u
ideally additionally:

• something like eventstream, turbo-django etc to get server-side messages onto the user's screen as push notification. This would even replace oob-swaps. se turbo-django's background technology, everything would be perfect.

Sorry, just woke up from a dream...