4 ms·

everytime i check out some htmx source, it feels like it would be a complete nightmare to maintain at scale. e.g. hx-delete="/chat/{{ chat.id }}" hx-target="#

• nop_slide 3y ago
  I barely know htmx but this example seems quite easy to parse. This snippet deletes a chat from the backend and removes the corresponding element in the UI. - send a DELETE request to /chat/chat.id - the response is going to swap the content of the #chat-chat.id element
  • hu3 3y ago
    Hi! Thanks for parsing it. How could I implement an error flash message in case the delete fails in this case?
    • wild_egg 3y ago
      I've found the simplest option is to have the server respond with the markup for the flash message. The server can include a couple response headers to override the placement of the message to not affect the existing page state https://htmx.org/docs/#response-headers https://htmx.org/docs/#response-headers This allows the error to either be added inline in the UI somewhere or (my preference) displayed as a toast by appending to the end of the <body>
      • hu3 3y ago
        Perfect thanks!
• TheUndead96 3y ago
  I think that snippet is perfectly reasonable if you are an individual or a small team in charge of the whole stack. This line of code is unlikely ever to change. Contrast this with React+Redux, where the code must constantly change to accommodate schema changes from the backend. The React project thus changes more often, but this is a false sense of maintainability. Further, imagine the 200+ dependencies a starter React app requires and how all of these must be kept up to date.