https://htmx.org logo
Powered by
# htmx-general
  • b
    Can someone explain me how to handle network errors as asked in my post on Stackoverflow? https://stackoverflow.com/questions/67089234/handle-connection-errors-in-htmxjs (I post my questions on Stackoverflow so that answers may be useful to a large number of users (or potential users))
  • c
    Thanks for sharing! 😊
  • m
    I haven't dealt with this particular situation, but maybe you can wrap the form in a div with 
    hx-get="/some-error" hx-trigger="htmx:sendError"
    so when the error event bubbles up it can be catched by this outer div.
  • m
    There is a django-htmx plugin being managed by adam johnson: https://github.com/adamchainz/django-htmx
  • m
    hmm, looks like it doesn't automatically populate the CSRF token, based on the example here: https://github.com/adamchainz/django-htmx/commit/5879ba661e21df8e8e5468a92e62365cde4fafa9
  • m
    thank you for asking on Stack Overflow! answered: https://stackoverflow.com/a/67092407/14288140
  • m
    I particularly appreciate that nice introduction! 🙂
  • b
    ah, that's useful. I was doing it like this, but now I'm not sure if that's working as expected. I'm not really a web dev, so I'm kind of doing all sorts of weird workarounds to get things working
  • g
    Is it possible to add / remove the hx-get attribute via js?
  • g
    It seems like if I remove it it is still active...
  • g
    You're correct. You can't do it with simple JS.
  • g
    The problem is that htmx parses these values and then uses the information to populate its own (semi-secret) data structure in the node itself. So, if you change the 
    hx-get
    attribute via Javascript, you're not really changing what htmx will do.
  • g
    But, you can tell htmx that there's new data to process. Try using the 
    htmx.process(node)
    function. It's usually used to tell htmx that you've made changes to the DOM that it doesn't know about.
  • g
    I'm not positive, but might also re-process an existing node whose arguments have changed.
  • g
    Tried using process but it didn't seem to work
  • g
    Shoot. That's what I was afraid of. I was going to the code to check, but you beat me to it.
  • g
    I don't think it reprocess
  • g
    I know that (eventually) we're aiming to have tighter integration between htmx and hyperscript, though hyperscript is still too new for that work to begin.
  • g
    This seems like something that you should open as an issue on GitHub, so that the 
    process()
    function WILL work to re-process a node that has been changed. There's probably a performance implication to it, which is why it doesn't do this already.
  • g
    Sorry I wasn't more helpful.
  • g
    No problem. Thanks for the quick response
  • g
    Of course. Chatting on discord is always more fun than doing my real work 🙂
  • g
    Hehe
  • g
    I think what I actually wanted was to just use htmx.ajax. That was easier than adding and removing Hx-get attributes
  • g
    There you go. I’m also hoping to get JavaScript access to 
    htmx.swap
    some day, which might make it easier to switch things up in the future.
  • g
    We’re still on the bleeding edge of what this technology can do. There is still so much more to explore and create with it.
  • m
    You can also change the path of hx-get, etc. programatically in the 
    htmx:configRequest
    event by changing 
    evt.detail.path
    . So you could set the path in a made up attribute, and change it, then always use whatever you have in that attribute.
  • m
    I use this approach to use only an action name in the request attribute, instead of very ugly URLs needed when working within a CMS.
  • g
    Great suggestion, @most-jelly-15242. It should be simple enough to change the request before it goes to the server.
  • g
    So simple, I think, that we should be able to make it a standard feature eventually. 🥸
1...217218219...1146Latest