https://htmx.org logo
Join Discord
Powered by
# htmx-general
  • r
    You have a modal. Probably, you block scrolling with 
    overflow-hidden
    (or some other class) when opening this modal
  • r
    Probably, you set it onto root html element
  • r
    And after the swap, this class is not removed
  • r
  • r
    Case closed
  • r
    You can fix it by either listening to the event and removing your class or by changing the way you block the scroll
  • m
    I'll move this to #974086000307499028
  • b
    @mysterious-toddler-20573 question on 
    head-support
    extension. When a 
    <script>
    tag gets merged into the 
    <head>
    , it executes the javascript as expected. But if I do it a second time, the javascript doesn’t execute, presumably because it’s already in the 
    <head>
    tag. That makes sense. But is there a way to get the javascript to run each time, the same way that if you’re clicking links between vanilla HTML pages, the javascript for that page will run each time? Or should I try something like Alpine’s 
    x-init
    to manually call whatever needs to be called each time that new chunk of HTML is swapped in? Or, is this just not a good idea to use 
    hx-get
    with 
    head-support
    to handle routing between pages?
    m
    • 2
    • 16
  • b
    My experience so far has been, there’s an HTMX equivalent way of doing it. Like there’s little difference between a JSON record and a single HTML table row. The only roadblock I’ve had is using third-party components. Like we use some calendars, Gantt charts, etc that do their own CRUD. The HTMX way would require building our own Gantt chart component that talks HTMX (I think)
  • t
    that was it, thank you very much!
  • m
    maybe when the script is within a tag we should re-eval it?
  • m
    but when it's a 
    src
    script tag, no?
  • m
    or maybe we should support a re-evaluate attribute?
  • g
    are real page navigations a no-go in this case?
  • b
    Not a no-go. Just exploring this approach to compose the page using HTMX. I could accomplish the same (like injecting the same nav bar into every page) using either a static site build step, or SSR templates.
  • b
    Hmm. Still thinking, wondering if this should even be handled in head-support. Is it possible to hook into 
    htmx:afterSwap
    event to call a javascript function? Or can hyperscript handle?
  • g
    yes, and yes
  • b
    I feel like you came to this same conclusion already, but my thought was "If you have control over the JS, and you want it to re-execute when X occurs, listen for an event associated with X and run the code." If you didn't have control over the content of the code in question, then your original thought about 
    head-support
    having a pattern for re-triggering the code makes more sense.
  • b
    re-evaluate in this case is basically the opposite of 
    preserve
    . Instead of never swapping, you want it to always swap, right? So maybe the attribute is 
    spoil
    .
  • m
    🤣 @bitter-machine-55943 I'm starting to think we need a head-specific attribute, hx-head, that could encapsulate the different possible behaviors: * sync - default, syncs head element (if absent, add, if no longer present, remove, otherwise leave) * preserve - add and preserve the element * append - append the element (do not remove current element) * appendIfAbsent - append the element if it does not currently exist * readd/reevaluate - always readds/reevaluates the given head rather than reusing other attributes to try to encapsulate this. What do you think?
  • m
    We could also support "naked" head elements w/ this mechanism, e.g. a response like this:
    Copy code
    html
<script hx-head="append" src="/whatever.js"><script/>
<div>Foo</div>
    wouldn't require an enclosing head tag. You could also hoist the 
    hx-head
    attribute to make all the elements, for example, appended:
    Copy code
    html
<head hx-head="appendIfAbsent">
   <script ...>
    ...
</head>
  • g
    Best idea on this so far.
  • h
    hi all hx-target="closest .someclass" not work or how that class added in hx-target?
  • m
    That should work
  • m
    request for feedback before publishing: https://htmx.org/essays/when-to-use-hypermedia/
  • m
    "closest" means "closest parent", maybe you mean "next"?
  • m
    or "previous"?
  • b
    Random thoughts… * Does 
    <head>
    need different treatment? Or does it make sense to just expand the scope of HTMX beyond 
    <body>
    ? * I can get javascript to run from a new HTML chunk after it’s swapped in, but only using 
    head-support
    so the 
    <script>
    is present. Then, using 
    onload
    I can call 
    refreshMe()
    from the 
    .js
    file, but the first time that chunk of HTML is swapped in, the javascript runs twice. * Possible downside of my existing approach: As I switch from page to page, more 
    <script>
    tags get added to 
    <head>
    without being removed. Not a huge deal, but if I had 100 pages that might start to cause some issue. * As a general case, this is just swapping multiple chunks of HTML, with multiple targets, possibly with multiple merge algorithms, right? * So should the path be: (1) create the generally applicable tool that enables 
    <head>
    to be treated like any other tag? Or (2) is that the DRY approach with too much magic, and the point would be to add some sugar so it’s more LOB and explicit?
  • m
    the head tag is kinda special, you can't parse it "the normal way"
  • m
    you can't place it in a template, etc.
1...867868869...1146Latest