I am trying to integrate Htmx with django and achieve single page application behaviour. I am rewritting Djangoproject.com poll app with htmx. When I click on detail page link, content loads, htmx push a new url in address bar. When I press back button, it took me to index page perfectly for the first time, after that if I again go to detail page and click back button, url shows of the index, but index content doesn’t load, content remains same as detail page. Here is my code -

views.py

def index(request):
    latest_question_list = Question.objects.filter(pub_date__lte=timezone.now()).order_by('-pub_date')[:5]
    context = {'latest_question_list': latest_question_list}
    if request.headers.get("Hx-Request") is not None:
        return render(request, 'main/index/index.html', context)
    else:
        return render(request, 'main/index/index-full.html', context)
    
    
def detail(request, question_id):
    question = get_object_or_404(Question, pk=question_id)
    print(request.headers.get("Hx-Request"))
    if request.headers.get("Hx-Request") is not None:
        return render(request, 'main/detail/detail.html', {'question': question})
    else:
        return render(request, 'main/detail/detail-full.html', {'question': question})
    

index.html

<div id="index" class="">

    {% if latest_question_list %}
    <ul>
        {% for question in latest_question_list %}
        <li><div class="has-text-link" hx-get="{% url 'main:detail' question.id %}" hx-push-url="true" hx-target="#index" hx-swap="outerHTML">{{ question.question_text }}</div></li>
        {% endfor %}
    </ul>
    {% else %}
    <p>
        No polls are available.
    </p>
    {% endif %}

</div>

index-full.html

{% extends 'base.html' %}
{% block content %}
{% include 'main/index/index.html' %}
{% endblock content %}

detail.html

<div id="detail" class="">

    <form action="{% url 'main:vote' question.id %}" method="post">
        {% csrf_token %}
        <fieldset>
            <legend><h1>{{ question.question_text }}</h1></legend>
            {% if error_message %}<p>
                <strong>{{ error_message }}</strong>
            </p>
            {% endif %}
            {% for choice in question.choice_set.all %}
            <input type="radio" name="choice" id="choice{{ forloop.counter }}" value="{{ choice.id }}">
            <label for="choice{{ forloop.counter }}">{{ choice.choice_text }}</label><br>
            {% endfor %}
        </fieldset>
        <input type="submit" value="Vote">
    </form>

</div>


detail-full.html

{% extends 'base.html' %}
{% block content %}
{% include 'main/detail/detail.html %}
{% endblock content %}

I found no error in browser console, no error in terminal

Now, I know I can put a back button in detail page that can took me to index page. But user won't use that, they will just use the back button on their device. Note- I am on Android and talking about the back button in mobile phones

HTMX fails with the following error in the console:

Uncaught TypeError: Cannot read property 'toUpperCase' of undefined
    at $t (htmx.min.js:1)
    at Fe (htmx.min.js:1)
    at htmx.min.js:1
    at X (htmx.min.js:1)
    at htmx.min.js:1

...when scrolling quickly. The code to replicate can be found at https://github.com/wiverson/htmx-demo - and the specific code generating the view can be found at:

Starting Thymeleaf View Java Spring Boot Controller

For reference, this is using the WebJAR version of HTMX, v1.3.2.

Replicated on macOS on both Safari and Chrome.

This patch adds files to websocket sends. By default it does the more efficient thing, sending each file afterwards in a separate message and adding pointer to this. This is more efficient since it relies on primitives inside the browser. The other encoding possibility requires hx-encoding to be set to multipart/json-files-inline. In this case, the files are included inline either as text or base64 depending on the mimetype.

How does this approach seem? If it suits I will add short additional documentation to the effect of the above.

I noticed that htmx does not reconnect after the connection has been dropped for various reasons.

I added this functionality because during development/deployments, server restarts are quite common and page reloads add unnecessary delays to the feedback loop.

This patch also adds the possibility to configure the reconnect interval since different use-cases and stages requires different latencies, e.g. dev: 3sec, prod: 20-30sec (in my case). If you think of a chat-like web app, you might want even have 5-10 secs, whereas message boards/issue trackers could live with up to 60 secs or more.

So, I leave this here open for discussion.

EDIT:

As an addition, one could randomize the reconnect period (reduced server startup load). We then might need an additional config variable such as (wsReconnectMinInterval and wsReconnectMaxInterval). In the wild, a constant should work pretty well for smaller projects. If you think, that the scope of htmx is also for larger projects, we could add it easily if you are okay with the additional config var.

EDIT2:

Just to make you aware of it: https://github.com/joewalnes/reconnecting-websocket (if you prefer pulling a third-party). I would rather go with a simpler solution but especially this field has a lot of opinions on what resembles the perfect solution.

EDIT3:

OK, my fault. I didn't check on existing issues nor pull requests. So to link things up: #148 #150

EDIT4: A well-described analysis can be found from AWS: https://aws.amazon.com/blogs/architecture/exponential-backoff-and-jitter/

I've just tried to import htmx into our build (webpack), and while it builds fine, in the browser I get the following JS error:

Uncaught TypeError: Cannot read property 'logger' of undefined

It's entirely possible that the JS is being mangled by webpack, perhaps the minification routine, but I'm not importing it any differently than any other package (flickity, alpine, etc).

Any tips would be appreciated!

This pull request updates SSE content to swap HTML into the current page, just like WebSockets, without removing the existing hx-trigger behavior that also uses SSE data.

I believe it addresses issue #66, although it does not use the syntax that you described there. Instead, it looks like this:

<div hx-sse="connect /my-events EventNameToListenFor">

Now, the hx-sse attribute takes a third (optional) parameter that specifies an event name to listen for. When events using this name come through the SSE channel, that is treated as an "out-of-band swap" and swapped into the underlying DOM (just like WebSockets do now).

To do this, I added the optional event handler to the processSSEInfo function, and moved some of the existing WebSockets code into a common place -- a new function called processFragments -- that is called by both the WebSockets implementation and the SSE implementation.

Hopefully, this code fits the style and spirit that you're building in HTMX. I'm excited to see all of the potential applications of this toolkit and will be happy to work on any enhancement suggestions, corrections, improvements to this code.

🤘

One of the differences between htmx/intercooler and unpoly is that unpoly by default assumes that the backend is serving full pages in responses rather than page fragments. As I am using htmx to enhance a site that should otherwise be perfectly functional without JS, the backend always serves full pages and never partial templates.

Additionally, I'm not sure what your typical sites look like, but I find that I almost never want to swap the element that is being clicked but rather some other element (this is also made easier by the fact that the entire page is served up by the backend, so things like buttons that have text that needs to be changed depending on the context are usually swapped out altogether with the element that is being affected by simply swapping a parent of the button and the results). As a result, all my htmx usages end up extremely verbose and redundant (especially because of #23 and #24), e.g. to simply swap a single element when a checkbox is altered:

<label><input type="checkbox" name="hideIncomplete" hx-get="/Registrations" hx-push="true" hx-target=".registrations" hx-swap="outerHTML" hx-select=".registrations" /> Hide incomplete registrations</label>

I wonder if there's a configuration option that could be added or else an alternate syntax that could be used that would bundle all this in one to reduce the boilerplate (and chance for error).

Opening from #245, since that issue was resolved and closed.

This issue is concerned with this note from @1cg:

That said, what you have looks like an excellent start to a head extension. Please let me know if you are interested in pursuing that, I'd be happy to help out.

Specifically, I'm interested in an extension/framework to alter the HEAD tag when boosting the entire page. When using boosting, the BODY swaps, but only the TITLE changes in the HEAD (if supplied by the response). I would like to create a way to manage elements in the HEAD that are specific to the new page.

As mentioned in #245, this model seems to work:

htmx.on("htmx:beforeSwap", function(evt) {

	var incomingDOM = new DOMParser().parseFromString(evt.detail.xhr.response, "text/html");           

	var path = "head *[data-page-specific='true']";
	document.querySelectorAll(path).forEach(function(e) {
		e.parentNode.removeChild(e);
	});
	incomingDOM.querySelectorAll(path).forEach(function(e) {
		document.head.appendChild(e);
	})
	
});

Any incoming element with an attribute of data-page-specific will...

1. be removed from the existing DOM
2. be added from the incoming DOM

I have this running on a product site, and it is working. Some META is perpetual from page-to-page, but anything specific to the incoming page like og:title gets a data-page-specific attribute. Those elements will get removed on the next load, and the new page specific elements will be added.

(Note: I'll likely change the attribute to something more inline with convention, like ht-boost-swap.)

One question for @1cg or @bencroker before I start writing something --

Is there any official way to detect a boost reload? I actually had to surround the above code with this...

if(evt.target.nodeName == "BODY")
{
  [above code here]
}

...otherwise it executed on every htmx request.

Is there a cleaner/more official way for me to determine that this is an entire page reload rather than a partial?

I have an input that represent the qty of an item in an invoice. I need to start it empty and only fire the trigger if the user change de value. So this are the sequence of steps:

<input name="qty" placeholder="old.qty">
load: ""
change: "1" -> fire
change:"" -> not fire
change: "1" -> fire
change: "10" -> fire

Just discovery HTMX, download .js file, create HTML index file but it do nothing. Got %subj% in F12 developer tools.

<html>
<head>
<meta charset="utf-8">
<title>
HTMX - elementary example
</title>
<script type="text/javascript" src="js/htmx.min.js">
</script>
<link rel="icon" type="image/x-icon" href="/HTMX/favicon.ico">
</head>
<body>

<button hx-post="cgi-bin/answer.cmd" hx-trigger="click" hx-target="#answer-div">
    Retrieve answer!
</button>

<div id="answer-div">
    DIR output list here
</div>

</body>
</html>

Fix for #1076.

Safari on iOS skips history state entries when using navigating backwards/forwards IF they were created using history.pushState() more than approx 500ms after the last user interaction (link click, select menu change etc). This makes back/forwards buttons behave unpredictably with htmx applications on all current iPhones and iPads, given that network conditions and application response times may vary.

Currently htmx executes a history.pushState() once a response has been received. This PR moves the pushState to before the response has been received, and then updates the final intended URL with a history.replaceState() (since replaceState doesn't create a history entry, this isn't subject to the user interaction limit). This change has a knock-on effect on cache management, which is also addressed. There may be some other implications around error handling and redirects initiated by the response that will require review (since we can no longer assume that pushState is possible after waiting for a response to be received).

Some automated tests relating to hx-push-url are failing, and any help with that would be much appreciated. Manual tests seem to work as expected.

Bumps flat to 5.0.2 and updates ancestor dependency mocha. These dependencies need to be updated together.

Updates flat from 4.1.1 to 5.0.2

Updates mocha from 7.2.0 to 10.2.0

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

keyup only works with a keyboard, and ignores pasting with a right click or programmatically updating the value with JS.

input is a better event for detecting any "inputs to the input".

The getStartTag function, which is used for generating the html fragment from the server, uses a regex to identify the start tag.

The main issue with this is HTML comments, and the secondary issue is that regex are slower than a highly domain specific, optimized parser.

Consider the following server response:

<!-- <p>my commented paragraph</p> -->
<div>my div</div>

the getStartTag function thinks that the p tag is the first element.

Adding hx-disable to an element (e.g. myElement.setAttribute("hx-disable", ""); htmx.process(myElement)) doesn't disable the element.

Using htmx.logAll.() I didn't see any events triggered after running htmx.process(...).

I think that when the htmx.process(myElement) is run, it sees that the element has "hx-disable" and stops processing it, instead of removing all triggers.

Why Add hx-disable Dynamically?

I feel like adding "hx-disable" more is more inline with hypermedia principles than doing evt.preventDefault() inside an htmx:confirm event when i want to prevent an event. For example, when I click a dropdown button when the dropdown menu is already visible, I don't want to re-fetch the menu.

Docs on the website for this page are currently rendering incorrectly because of faulty escaping of curly braces (line 80 is rendered has <p> and and </> htmx - high power tools for html and </p>). Unfortunately, this fix breaks the rendering of the file on github (there are extra {% raw %} directives), but I think it's better than the other way around.