Is a delete request allowed to have more than one parameter and still be considered restful? Like /deleteBookPage/1/5 where on the backend I would be deleting page 5 of book 1

I don't think there was a limit on the number of parameters in requests

However, delete request should be idempotent, so make sure, that 5 is identifier, not a page number

Umm...I think I understand. 5 identifies the page, but is not the row id.

how to remove the modal classes and styling from the body on successful post request? (without resorting to hx).

Thinking about template fragments: is there some value in an

hx-fragment

attribute? It would just add a new header to the request with the fragment name. At the moment I define multiple routes on the server - one for each fragment. Having a header to inspect in a single route could simplify the code. Does that sound useful to anyone?

Say you have a couple of different forms on a page, and the submit buttons end up being outside of the forms for some layout reason. Is there something in htmx I've missed that says, this button submits form#foo and that button submits form#bar

hx-include

confirmation happens before we gather all the request value. Best option is probably to look up the values manually in your confirmation code, sorry 😑

table elements are the bane of oob swapping, and I hope to come up w/ a good solution for this in htmx 2. In the meantime, you can wrap them in

template

tags and you will get the behavior you probably want

no good reason, sessionStorage would probably be a better option but I wasn't familiar w/ it when I built the feature in intercooler.js (not sure it was around then) and hadn't thought about it in a long time

Thanks, that works. I tend to scan the doc code examples to see what the thing does and the example given made it look like you could just pass in various form name attributes found on the page.

Reading properly, it's much cooler.

I have this login form:

<div id="login-form">
        <template
          hx-ext="restored"
          hx-trigger="restored"
          hx-get="/auth/login"
          hx-swap="outerHTML"
          hx-target="#login-form"
        ></template>
        <form
          action="/auth/login"
          method="post"
          hx-swap="outerHTML"
          hx-target="this"
        >
          <div class="error">{this.formError}</div>
          <label for="username">Username:</label>
          <br />
          <input type="text" id="username" name="username" hx-preserve />
          <br />
          <div class="error">{this.parseErrorMsg('username')}</div>
          <label for="password">Password:</label>
          <br />
          <input type="text" id="password" name="password" hx-preserve />
          <div class="error">{this.parseErrorMsg('password')}</div>
          <input type="submit" value="Login"></input>
      </form>
</div>

The purpose of having a

template

tag in it is to prevent the user to log in again if he clicks the browser back btn. It works like this: if the user clicks the browser back, the

restored

event is emitted and

GET /auth/login

request returns

hx-location

header if he already has a session. This works fine, however, I'm not sure if there is a better way to achieve the same goal. The problem I have with this approach is when the user is authenticated and does a page refresh. In this case, if he goes back to

login

by clicking browser back btn, the

restored

event is not emitted. Is this a bug?

Ok, this looks like something really powerful. Why isn’t it advertised more? 😀

I really like this discord server, I can learn about so many interesting htmx patterns and use cases

Here’s a puzzle for htmx experts: You’re sending messages over web sockets. These messages are updates on the progress of some process. Simple enough. But, these belong in a wrapper that can be hidden by the user for their current browser window. If the user had dismissed the wrapper in the current window, we shouldn’t render anything. However, if they open another window - we should render the update. Inside the wrapper. Both the message and the wrapper should be generic.

I don’t mind using a bit of JavaScript here as long as I’m not forced to make API calls to the backend with axios or something. Also, the messages are ephemeral. There can be more than one process running.

Am I interpreting your question correctly?

oh, wait, you were talking about browser windows

Yes. Awesome drawing skills!

It's just https://excalidraw.com/

Yeah it’s the same effect though, clicking a link basically is a new server-side rendered page (in the non-htmx context).

The question is: Is this update’s wrapper currently visible? If yes, simply render the update inside the wrapper. If no, has it been dismissed? If not, render the wrapper and the update.

I'm puzzled about third question. "If no, has it been dismissed?" - does that imply that the wrapper can be hidden, but not dismissed?

Dismissed means closed or hidden. Sorry.

yes, I understand that, it's not my question. You say "Is this update’s wrapper currently visible? ... If no, has it been dismissed?" - as I read it, being not visible and being dismissed/closed/hidden are not the same thing and it is possible for the wrapper to be the former, and not the latter, and that's what I'm confused about

Here’s the requirement: in a single browser window, if a user clicks “x” icon on the wrapper, it should no longer be visible to the user. And in that window, they shouldn’t receive updates regarding the process this wrapper is updating about. Whether it’s technically closed/hidden/destroyed is an implementation detail. Did I get you right this time?

Yes, that sound simple enough

Wait