https://htmx.org logo
Powered by
# htmx-general
  • w
    Hmm, I can do a server side redirect and then add 
    HX-Retarget
    to the response to also change the target then, right? Seems weird, but it's for a create account/login form and then either 1) payment form or 2) profile response
  • m
    Yep that should work
  • w
    Is it possible that HTMX wouldn't pass on a 
    HX-Retarget
    if it came from a 3xx? My understanding is: 1) A form with 
    hx-post
    and 
    hx-target="#login-form"
    is submitted by HTMX 2) My login view reads it, verifies the form, logs the user in 3) I create a HttpResponseRedirect, which is just a 302 and a 
    Location
    header. I add in the 
    HX-Retarget
    header: 
    response['HX-Retarget'] = "#content"
    this is returned 4) HTMX sees this response and then makes a new (GET) call to the 
    Location
    header (Profile view) 5) In my Profile View, everything goes as expected, but if I examine the request, it doesn't have 
    HX-Retarget
    in it, it still has 
    HX-Target
    as 
    #login-form
    . 6) The entire profile page gets swapped into the 
    #login-form
    div. Trying to figure out where the 
    HX-Retarget
    header gets removed.
  • m
    The regather would need to come from the final end point
  • m
    Retarget
  • d
    We are currently in the process of evaluating htmx for a a UI rewrite at work. One of the features of the current UI is an always-running global watcher for keyboard events - we have a barcode scanner which can be used "whenever" no matter where input focus currently is. Is something like that likely to be interfered with by the keystroke hx-triggers?
  • m
    What does the global listener look like? Do you listen for other keys that would drive htmx requests?
  • m
    Broadly, you should be able to make anything work w event filters or even writing your own keyboard handler and dispatching custom events to trigger htmx requests, so it should be doable
  • d
    Good to know, thanks so much @User , we're going to POC it soon and see how it looks 🙂
  • a
    Just starting with htmx and I'm wondering if it's possible to post a form before changing to a new record? In other words, list of records on left and edit form on right and we'd like the form to save before a new record is loaded. At the moment we're doing this with vanilla javascript AJAX calls but we'd like to go htmx all the way if possible.
  • s
    You should be able to do this using a custom event on the 
    hx-trigger
    attribute of the form - https://htmx.org/attributes/hx-trigger/
  • a
    I'm not sure how. If the user changes a field on the form (say surname from "Smith" to "Jones") then clicks another contact on the grid on the left then nothing on the form has been triggered to let it know to save the record before another is loaded. If I trigger a save as soon as Smith is changed to Jones (i.e. before the user moves on to another record) the option to cancel edits is lost. I must admit I'm a bit stuck on this one.
  • s
    You said before that you're doing this with vanilla ajax calls at the moment - so I would look at replacing those with raising an event to trigger htmx to do its thing.
  • b
    @User Does the inline-validation example help? https://htmx.org/examples/inline-validation/ Put an 
    hx-post
    on the 
    <input>
    and have that commit things to the server.
  • a
    Thanks for responding again Craig but I'm not sure I like the idea or raising an "artificial" event to achieve what I'm looking for. We're looking at htmx as a way of simplifying code, making it more readable and I think - in this one instance perhaps - using htmx might have the opposite effect.
  • a
    I'm afraid not as that is posting back to the server when the user changes a field which isn't what we're looking for as it denies the user the chance to reset the form to revert to "last saved". We're looking at this in the same way as a lot of desktop UI's at the moment which don't require you to click Save when you've made changes. This leads some users to make changes to a record then move to another record without clicking Save as they assume it's done automatically.
  • s
    That's fair 🙂 I was just thinking that the simplest option might be to slightly change your existing code if you've already got something working. Essentially, the form needs to be told to save - and one way of doing that is to listen for a relevant event and act accordingly. It seems that the user navigating to or selecting a different contact is the main action you'd be wanting to wait for, so seems like a natural place to put it.
  • b
    ah - I think @User has it right. Have the form with an 
    hx-post
    but also an 
    hx-trigger="new-contact-loaded"
    (or whatever). Then have the 
    click
    handler on your contact list that fires that event. How are you letting them reset the form btw? Asking the server for the existing version?
  • m
    I would make the navigation click on the right hand side include the contact form via 
    hx-include
    and then have a hidden input dirty flag that was triggered when an input was modified in the form. Since navigation can cause an update, I would use 
    hx-post
    with it.
  • m
    I wouldn't try to coordinate multiple requests, for simplicities sake
  • m
    from a hypermedia perspective, the navigation is mutating, so a POST is appropriate
  • a
    Thanks both. Looking at our code (which dates from about 10 years ago) it's a fairly straightforward setup. needSave is set to false when a user selects a record. Once the form is loaded a loop assigns an onkeypress event to each input to set needSave to true if there's any keypress. When the user clicks on a different contact the onlick event in the grid row basically checks needSave and saves if required then loads the requested record. There's a good old fashioned reset button to revert the record if required which also sets needSave back to false.
  • m
    That all sounds reasonable. I would just store that needSave as a hidden input and then make the navigation a POST, including the form. Check the hidden input, save if necessary, rerender the whole deal w/ the new contact.
  • m
    The save and reset buttons can use pretty much the same code, just slightly different logic
  • m
    maybe make the reset a GET of the current contact being edited to differentiate
  • m
    as a useless, subjective aside: I dislike the "save automagically pattern" in most situations. Apple started it, as far as I can tell, and it is an extremely unintuitive UI pattern for me unless the settings have an obvious visual side effect. I much prefer the save button and warning when a form is dirty pattern.
  • a
    Thanks again @User . I think we'll have to take a slight step back from htmx for the time being. Your idea makes sense but the script saving records accepts data from 30 odd forms on the company site so we can't faff with that until we know exactly what we're doing with htmx. Usual issue with the bosses: "How long will it take and how do we benefit?" sort of thing. Completely agree on the save button thing (I constantly find myself going back to the last record to make sure it did actually save) but who am I to argue...
  • m
    no prob, we are pragmatic here
  • m
    i wanted to play around w/ this tool, so I did a diagram explaining the approach I was advocating:
  • b
    Balsamiq?
1...537538539...1146Latest