https://htmx.org logo
Powered by
# htmx-general
  • m
    we'd rely on the baked in browser caching mechanism
  • a
    My best solution to this so far is:
    Copy code
    <input name="expire<%= deal.id %>" type="hidden" value="<%= deal.id %>">
    <button hx-swap="outerHTML"
      hx-include="input[name=expire<%= deal.id %>]"
      hx-post="/expire"
      value="<%= deal.id %>"
      <%= deal.expired ? 'disabled' : '' %>
    >
      Expire
    </button>
    If anyone has a better idea, please lmk. I'm still unclear why the button's value isn't sent by default... I'm guessing it only does that for 
    <input>
    types? The one other option I tried is creating separate forms for each element, but then ended up being bulkier. Finally, what about posting to 
    /expire?dealId=123
    ?
  • m
    you can use hx-vals to include the value: https://htmx.org/attributes/hx-vals/
  • g
    You’ll probably need to call 
    processNode
    on the root element of the web socket (ie, the tag with the 
    hx-ext
    attribute)
  • c
    Hello to all.. I'm getting the following error "Uncaught SyntaxError: Unexpected token '<' (at htmx.min.js:1:1)" while testing for the first time htmx.. I checked the script downloaded as per the instructions and the first line of the htmx.min.js has a googletagmanager reference.. Is that normal? if so, why is it there?
  • m
    Sounds like you might have the “browse” unpkg URL added, instead of the direct .js file?
  • c
    hmm.. let me check for that, thanks!
  • m
    It looks like 
    hx-target
    only swaps the first element it finds, is there a way to target multiple elements?
  • m
    mm maybe oob is the answer?
  • m
    not currently unfortunately, although you could write your own swap extension
  • m
    oob should work if you have IDs you can target
  • m
    I have two interactive elements, one displayed on desktop and one on mobile and I'd like them to be able to update each other
  • m
    What I mean is that it's the same element, displayed in two different positions
  • m
    So basically I'd have to return twice the html, each version with its hx-swap-oob, right? Something like:
  • m
    Copy code
    <div hx-swap-oob="#mobile-element">...</div>
<div hx-swap-oob="#desktop-element">...</div>
  • m
    yep
  • m
    for now
  • m
    Mm not a big fan of this approach, I guess I'll pass an id argument to the components and handle them separately. Maybe I'll look into creating a swap-all extension later on. Thanks!
  • e
    I think you can use a class? So something like:
    Copy code
    <div hx-swap-oob=".my-class">..</div>
    IDs should be unique to an element, so I think the current behavior of 
    hx-swap-oob
    makes sense.
  • m
    Would this swap all the elements with that class? Because the normal 
    hx-swap
    doesn't do that. I'm using another approach right now btw
  • e
    Yes it seems like it does. Here's this from the docs:
    Copy code
    The value of the hx-swap-oob can be:

true
any valid hx-swap value
any valid hx-swap value, followed by a colon, followed by a CSS selector
If the value is true or outerHTML (which are equivalent) the element will be swapped inline.

If a swap value is given, that swap strategy will be used.

If a selector is given, all elements matched by that that selector will be swapped. If not, the element with an ID matching the new content will be swapped.
  • e
    So you should be able to use any CSS selector.
  • m
    Ah interesting! I'm getting a bit lost by trying different approaches and rewriting bits over and over.
  • m
    thread on the dawning realization that GraphQL might not be The Answer: https://twitter.com/htmx_org/status/1522610957670776832
  • j
    I have stories about this from my current gig, where my team has inherited a React/Rails app where Rails is mostly there to provide a GraphQL API. The upshot: if you don't really think about access controls on the entities your API provides, someone will very much find every winding path to pulling data they shouldn't be able to access.
  • m
    me, arguing w/ the facebook people on orange site many years ago about exactly this: https://news.ycombinator.com/item?id=11107438
  • m
    😑
  • j
    Also, GraphQL mutations are, to me, hideous. YMMV.
  • g
    > Gosh, and API migrations, too. > GraphQL feels okay at the start and then eats up so much time and thought later. It might work super well for Facebook's case (ask them not me) of having a graph and an enormous number of eng to support it but few others have that -- https://twitter.com/jmhodges/status/1522387231033335808 they don't know about facebook's allowlist of queries created by analyzing the frontend codebase :wojak:
  • m
    chasing FAANG tech
1...663664665...1146Latest