https://htmx.org logo
Powered by
# htmx-general
  • g
    If a child element have different target and select yes.
  • g
    but if you only want to boost a nav bar you can set the hx-boost and target / select there instead of on the body to not turn every link into a boosted one
  • p
    yeah overriding breaks the lazy loading hx-get behavior
  • p
    no hx-boost has to be default everywhere in this case
  • p
    also looks like adding hx-boost in the sidebar works (with hx-select/hx-target) but it breaks scroll behavior (doesn't scroll up)
  • g
    I guess that could be related to this: https://github.com/bigskysoftware/htmx/issues/456
  • g
    I haven't had any issues with scrolling since the fix for adding show:top by default for boosted links was added. But I'm not sure I understand the problem in that issue...
  • p
    yeah hx-boost on the body (default) works, adding hx-boost to sidebar does not (i.e. no scrolling happens)
  • p
    could be css or something, but odd that the correct behavior is broken unexpectedly
  • g
    Hard to tell without looking at the code / page 🙂
  • p
    is there a way to set hx-select="false"?
  • g
    Another topic... Has anyone done anything with checking what has actually changed after a swap? We are doing some highlighting effects when some content gets changed. But it's a bit tedious to write js for everything. Trying to come up with something that gives me elements whose content has actually changed after a swap
  • g
    Yes. There should be something to help you out.
  • g
    Without looking, I think you're looking for a class "hx-settling" (or something like that)
  • g
    Ah... crap. I now realize that this part is not doing stuff with htmx.
  • g
    When htmx puts new content into the page, it adds this class for a small amount of time (configurable). You can use the css class to change the way it looks.
  • g
    We have a small script that does this with html that is sent over websockets
  • g
    IF, of course, you're swapping things out with htmx. Otherwise, you're on your own 😛
  • g
    But.. Isn't the hx-settling class applied to the top level target? Or is it on all nodes that are being changed?
  • p
    I think re scrolling : I think if hx-target="#content" it scrolls to top of content, not body
  • g
    Heh... I use the settling stuff on another part of the site:
  • g
    #js-online-bidders-unlocked-count { transition: opacity 100ms ease-out; &.htmx-settling { opacity: 0.5; } &.htmx-swapping { opacity: 0.5; transition: opacity 100ms ease-out; } }
  • g
    I think it's applied to the item that's swapped. https://htmx.org/reference/#classes
  • g
    We push some content that is not changing as we want parts of the site to be consistent. So one websocket message contains multiple "directives" for elements that should be replaced with html from the server.
  • g
    I think I follow you. I'm doing something similar with SSE. The messages from the server just contain the ID of the item to be updated, then I have to update them "manually" separately. Does this sound like what you're doing, too?
  • g
    Or, are you having htmx listen to the websocket, then swapping content directly with an oob-swap?
  • g
    we send something like this (we call the library html-push): actual html that should replace the target.. and so on"
  • g
    Using pusher.com as the websocket provider
  • g
    Ok. That makes sense. For reasons I couldn't render the content on the server directly, so I needed to do the round-trip first. Your way is going to be quicker/more efficient.
  • g
    then we add an element with a data-html-push-subscribe="channelname" on the page that should listen for messages on a specific channel
1...244245246...1146Latest