https://htmx.org logo
Powered by
# htmx-general
  • m
    it is dynamic
  • m
    in fire fox
  • m
    (checking chrome)
  • m
    chrome is dynamic as well
  • m
    So, given that, what do you think of the config option ben?
  • b
    I think that's a wonderful solution @User !! Also see https://github.com/bigskysoftware/htmx/issues/305#issuecomment-754071746
  • g
    I’m still catching up on this thread, and have some learning to do before I state any big opinions. One thing I’ll advocate for now is making things “secure by default”. So, if there is a configuration option, perhaps it could be something more like “unsafeEval:true”
  • b
    I tend to agree @User, but that would mean pulling back some features by default.
  • g
    Like I said. I’m still catching up 😀 what kinds of things would we lose, if “secure” was the default?
  • b
    hx-vars
    , dynamic trigger conditionals and evaluating script tags in the response.
  • g
    Thanks @big-airline-13935 that makes sense. Still digging.
  • m
    I pushed up a config variable to disable eval. I'm going to keep it enabled by default.
  • g
    Yeah. Probably the right thing to do. Wanna make a list of “breaking changes” to consider for a version 2.0 in the distant future?
  • b
    Ohhhhhh yesssssss!!
  • m
    1.1.0 is going to be a pretty large release, not quite sure how this happened
  • m
    @User btw, preload is up on https://dev.htmx.org, but I don't think it's working due to some 
    nocache
    stuff going on
  • s
    Some people (like me) check the stackoverflow-tagtrend to see if a technology is cool. That's why I ask there. For example: https://stackoverflow.com/questions/65569673/htmx-hx-target-swap-html-vs-full-page-reload This has the benefit that google can find the answers.
  • m
    thank you! I need to start directing questions from github issues over to stack overflow
  • a
    Good point!
  • a
    I see what you mean @User. It also seems that the response sizes vary slightly between the preload request and the 2nd request that's fired on click. Why would that be?
  • a
    Also @User I think you said you ended up changing the default behaviour for the 
    preload
    extension to work on 
    mouseover
    , correct? I think the extension's documentation might not yet reflect that change?
  • a
    Hmmmm @User regarding the removal of the headers: 
    HX-Event-Target
    , 
    HX-Active-Element
    , 
    HX-Active-Element-Name
    , 
    HX-Active-Element
    ... I fully understand why you removed them in order to make preload work ... but does that mean there's now no way to know on the server-side which element triggered a htmx request?
  • b
    It would appear so.
  • b
    Although I'm not sure why the element that triggered the event also had to be dropped.
  • b
    In fact, I'm not convinced of why this (breaking) change is even necessary.
  • a
    Hmmm... this might be problematic. I typically relied heavily on the 
    ic-element-id
    parameter server-side to know which button click triggered an intercooler request, so I can do the right thing. How would you go about emulating that behaviour if there is no more 
    HX-Active-Element
    header?
  • a
    @User my understanding of why the headers were removed, was that if you're preloading a hx-get link (say on mouseover), those headers aren't being sent, so if you then subsequently go ahead and click the link, the 2nd requests differs from the "preload" one, which makes the browser actually send a 2nd request to the server, instead of using the cached response of the "preload" request
  • a
    That said ... perhaps @User can weigh in here with a definitive answer.
  • a
    If the headers are indeed not gonna be there anymore, I guess one would have to manually emulate this behaviour through the use of say 
    hx-vals
    , is that right?
  • b
    Why not send them in the preload request though? It may very well be that the server responds differently depending on which element triggered the request, as you alluded to @User.
1...119120121...1146Latest