https://htmx.org logo
Powered by
# htmx-general
  • g
    If you find one, let me know. That’s what I do too. I think it works pretty well because I know there’s only ever one modal.
  • g
    You might try this: use the HX-Retarget header when you know you’re delivering a modal. That means that the client-side HTML doesn’t have to use hx-target and doesn’t need to care if it’s opening a modal or a regular link.
  • g
    I know this is my future, but I just want to stay a kid for a little longer. ..
  • c
    does this actually work today for use like binding?
  • m
    @User I do something similar, but instead of manually appending divs to the body, I do it programmatically in the 
    htmx:afterProcessNode
    event. If the processed node has an 
    hx-target
    attribute and the target selector, in this case using an id, doesn't exist, then I create it and append it to the body.
  • g
    idk, didn't test it
  • g
    Interesting. I may need to play with that, too.
  • g
    Draft of Issue 12 of This Week in HTMX: https://d05c7bfa.this-week-in-htmx.pages.dev/issue/12/ -- Feedback welcome. @User @User @User This issue features messages from you. Please feel free to reach out if you'd like them left out/amended/any other issue. My DMs are open.
  • f
    Is it possible to use hx-push-url without snapshotting the current DOM? I want an entry created in the history, but if the user clicks on Back I want the browser to get the page from the server (and not from htmx's localstorage cache).
  • m
    set htmx.config.historyCacheSize to 0
  • a
    I've been thinking of something like: On first click, fetch the dialog and append (not replace existing dialogs) it to the body. On subsequent clicks, just re-open that dialog. That way you only fetch each dialog once. Your DOM will keep growing and growing, but depending on the use case that might be not an issue.
  • a
    you need each dialog to get it's own dynamic id or some way to tell them apart, so it starts to get complex... I might just go with a simple "replace dialog" approach for this first version
  • a
    what does "initialize" mean exactly on this context? > This event is triggered after htmx has initialized a DOM node.
  • a
    lgtm! 🙏
  • c
    Looks really good! Thanks for doing this this is awesome. It is funny to some degree this newsletter does really help surface things that would normally get lost in chat 👏😊
  • a
    I am getting a bit confused by OOB. I have this on my current DOM:
    Copy code
    <div triggering an htmx-request id="bar"></div>
<div id=foo></div>
    And my response is:
    Copy code
    <div>X</div>
<article hx-swap-oob="innerHTML:#foo"><p>Foo!</p><article>
    I would expect the end result to be:
    Copy code
    <div>X</div>
<div id=foo><article><p>Foo!</p><article></div>
    But instead I end with:
    Copy code
    <div>X</div>
<div id=foo><p>Foo!</p><div>
    If instead I use 
    outerHTML:#foo
    , I end with:
    Copy code
    <div>X</div>
<article><p>Foo!</p><article>
    That I understand, but the innerHTML cases is confusing me, as I would expect the element containing the hx-swap-oob attribute to also be put inside the target element.
  • a
    should I be using 
    afterbegin
    to accomplish that, and my understanding of innerHTML is just wrong?
  • m
    Think of the oob element as a vehicle for transmitting your content: you want the stuff inside it to be the content to be sub'd
  • a
    wouldn't then be a more consistent behavior that the element with the hx-swap-oob attribute is always omitted? Because when using outerHTML it is not, but when using innerHTML it is.
  • b
    I got confused by this behavior today as well. Why have a semantically useless container? I guess it might be confusing if that container also needs other hx- attributes for later in its life cycle. I see the 
    id
    of the container also has non-standard meaning. Why not make that be an hx- attribute? But it seems to be an inconsistent choice, when so much of HTMX passes "the law of least suprise" with flying colors Also I noticed that if the swap-oob element came first in the fragment, the other data was not swapped at all. Didn't see this behavior documented.
  • a
    I'm fine with the behavior, as long as it doesn't change depending on the value of the hx-swap-oob
  • a
    right now it is not only changing what on the target element is swapped (the whole element vs the inner part of it), but it also changes what gets put in there.
  • b
    I think you mean "not only", where you have "not". Yes that part bit me too.
  • a
    fixed 🙂
  • g
  • m
    pronounced twhatmux
  • r
    if this community is considering a forum, the best options are pretty much: 1. Discourse (A lot of projects tend to land on this one). 2. Flarum (Personally I would recommend this one, it's the next iteration of FluxBB, the software behind the Arch Forum). 3. A classic such as PHPBB. I realise there's a severe lack of forum software, oddly enough, in 2022. It's the reason I brought it up in the #929014829212123156 channel.
  • r
    It's not like it would be super complex to build one, especially on htmx, there's certainly a market for something new.
  • m
    the reality is that we are going to build it ourselves
  • m
    and, by we, I mean @User and whoever else is interested
1...609610611...1146Latest