https://htmx.org logo
Join Discord
Powered by
# 🔥-django-htmx
  • b
    no problem! in the non-htmx case though wouldn't you need a submit button?
  • n
    Yes, which is what I want to be rid of, from the UX point of view
  • b
    so if you kept the submit button and didn't want the fancy stuff of auto updating when you type it will all work the same too with htmx.
  • b
    and to be fair there is probably a cleaner way to do this (im pretty new to htmx)
  • n
    If the current url is ...?color=red and I change to blue and click Submit, I get a clean ?color=blue, and my form doesn't need to restate the URL since is sufficient. (Because I'm using render tags for the field it's kind of annoying to pass the URL down to the tag to include in hx-get="...")
  • b
    ah I see - ya if its pretty straight forward if you use the url template tag 
    <form hx-get="{% url 'test' %}" ...>
  • n
    I need to get the url down to the text-input fields though, and they're inside a render tag
  • n
    for the selects, I can pull the behavior up to the form level, and provide the url once
  • b
    have you tried https://github.com/jazzband/django-widget-tweaks - it allows you to pass in html attributes
  • n
    Yes I've been using that. It's good for modifying an existing widget-template, but in my case I'm pretty much replacing the template anyway
  • n
    In my dream, I could just say (no equals on the hx-get), and it would find the current URL as if I was explicit. And also in my dream, it would not repeat any existing query-params in the URL. Then I feel it would have the same "shape" as the before-htmx version, and that would make it a clean dropin
  • n
    I will consider constructing a simple example and open a ticket
  • b
    Ya I've never run into that as I just write all my html by hand - I didn't even know you could have an empty hx-get. I see what you mean though. It should append the query parameters to the root url insead of the full url.
  • n
    Or merge them
  • n
    Say I have five inputs in this form. In the non-htmx version if I set two of them and leave the others in their default/none state, when I click "Submit" the resulting URL has exactly two query parameters. If I adjust a third input and Submit, I end up with three qp's.
  • n
    Since Submit is a "batch" operation, in that case there's no difference between merge qp's versus "apply qp's to the root url"
  • n
    (that is, in the second Submit, three of the five inputs are set to non-default at the time of the click)
  • n
    With htmx making everything live, we'd need a merge (i.e. delete any matching param before adding the new one). I'm trying to decide if https://simpleisbetterthancomplex.com/snippet/2016/08/22/dealing-with-querystring-parameters.html has any relevance, since it deals in a similar QP substitution (non-htmx cases)
  • n
    Anyway, done for the night, it's late here.
  • n
    Thanks for the help and the chat
  • b
    Cheers!
  • m
    Hello 👋 I'm trying to use htmx.ajax to send json data to a View (I assume that's a normal use for it) and I'm having trouble getting the data inside the View.
    Copy code
    htmx.ajax('PATCH', url_tests_save_order, {
                target: '#page-errors',
                values: result, // this is a JavaScript array of objects
            })
    When I look at the request payload in Chromium dev tools, it looks like it htmx has taken the JavaScript object (the one I assigned to 'values' in the ajax context) and turned it into a string - or an array with a single character in each item, and submitted that as the payload. Any idea what I'm doing wrong?
  • m
    Looking in Django, I can see the content type is 'application/x-www-form-urlencoded'
  • m
    Oohh - I think I get it now. The docs say htmx.ajax "Issues an htmx-style AJAX request." - which would be a request with a "values" that look like form data. E.g. values: { name: 'bob', age: 102 }
  • m
    I didn't know what a "htmx-style AJAX request" was so ignored that bit of the docs 😉
  • s
    Please create a pull request for the docs, if you see a way to improve then
  • b
    Quick question: are people using template inheritance to differentiate between htmx and non-htmx requests? I keep thinking that there would be a top level 
    extends
    statement that includes a base template when it's non-htmx and just returns the template content when it is an htmx request. (i.e. no inheritance). I'm just wondering whether this is how it plays out in practice. e.g. are there times when you end up needing lots of other blocks in order to recreate the full page when someone refreshes.
  • b
    (I think this is my emberjs showing through - they have a hierarchy of routes that all get embedded in each other. This is possible with django templates (and jinja) but we would/could get a situation where a template doesn't have the information to render itself correctly. In ember, code is run for each level of the template but that isn't how it would work in django etc)
  • p
    I use the same 
    base.html
    template for all "full page" requests with some 
    {% if request.htmx %}
    logic to determine whether to include e.g. HTML header and footer tags. But I can see that getting unwieldy in more complex applications.
  • b
    Cool. I was musing on whether there was a way to reduce some of the boilerplate when you're doing the htmx approach. I think I've over-thought it and the inheritance is best left to the dev.
1...434445...100Latest