The server can respond with HTML having the id="chat_room" hx-swap-oob="true" attributes which will tell htmx to swap out the #chat_room element with the new HTML.
The part I find most interesting is that there are no special requirements for the server at all. Not even for the websocket support. Any server which can reply with HTML will work.
Work on intercooler 2.0 (renamed to htmx) has begun. See htmx.org for more information!
It seems to be an improvement over Intercooler without any external dependencies and with fewer but stronger core concepts backed by a powerful extension system.
We at Bizneo have been using Intercooler.js for multiple years now. It has been really stable and a joy to work with. Our backend responds with HTML and Intercooler picks and replaces the selected elements in the page.
We want to make a few changes in the README and documentation before pushing the package to hex.pm, but it can be already used by fetching it from GitHub. We have been using it for some time without any problem.
# In your mix.exs
{:intercooler, "~> 0.1", github: "bizneo/intercooler"},
Looking at the similarity between HTMx and Intercooler.js, and since both come from the same author I will probably try to update the plug to support both libraries instead of Intecoooer only.
Is there a way to use HTMX with Phoenix and websocket, without using LiveView. Maybe with channels. Or do I have to code a basic websocket server into Phoenix for this ?
Phoenix web sockets work with channels and htmx likes to work with websockets without channels.
I have had a great experience using Server Sent Events (SSE) instead of web sockets. It works really nice with phoenix and htmx.
It can be barebones at time compared to other solutions (i.e. LiveView / Turbo)
You’ll want to rewrite 302s to 303s to avoid browser issues when implementing DELETE. Another option is to set the HX-Redirect header when it is a 302(?), which I have not tried. Here is more context. Hotwired/Turbo does the same thing. To make the mental model easier (even if Not Proper™) I just rewrite all 302s to 303s when sent to the browser so I don’t have to reason about whether or not it’s the proper response status. This will affect your browser tests though, so it would be worth looking into the HX-Redirect alternative:
defmodule HTMXRedirect do
import Plug.Conn
def init(default), do: default
def call(conn, _opts) do
register_before_send(conn, fn conn ->
if conn.status == 302 do
put_status(conn, :see_other)
else
conn
end
end)
end
end
Some issues I’ve ran into:
Scroll position is not properly restored when the current page you’re on doesn’t have the same height as the previous page.
Sometimes dynamically loaded scripts in the body do not load. I just disable hx-boost to those pages.
Overall, it’s fine.
It’s rough around the edges, maybe optimized for Django? No clue.
I like how everything is an attribute, while in Turbo you have to create custom elements and massage your markup differently.
Being able to html-swap different parts of the screen helps (flashes, for example)
I did have to reinvent the wheel for other things, like asset digest mismatch (i.e. turbo-track-reload).