The thing about HTMX is that the mental model about state should tend towards "the server is aware of everything". With the added benefit that you can achieve better RESTful URLs that respect the navigation actions. Without having tried this (but having used HTMX quite a lot), I would try the following (let me know if I didn't understand the problem correctly):

Checkout has the following URLs, one for each step:

  * page.com/checkout   (optionally with ?step=0)
  * page.com/checkout?step=1
  * page.com/checkout?step=2
  * page.com/checkout?step=3

Now you need 2 things:

1) Making sure the server knows how to render all those pages independently (like if the user does a hard-refresh or if they open that URL directly, without navigating to it through a link). Note: I believe this should be the default in any website if you respect the concept of a URL (whether client or server-side rendered).

2) If there's a form input at each step, the server needs to store that info and be aware that the user has an incomplete checkout.

Now the user is at step=2 and presses the back button, or clicks on the step=1 link. In that case, the server should know the information stored in the point no. 2 above, and return an HTML form with the data pre-filled based on the last state. E.g:

  <input type="text" id="name" name="name" value="Foobar">

I think there are 3 main keys:

1. You need different URLs for each step. 2. Each URL should work both with HTMX (maybe using hx-push-url or the HX-Push header) and *without*. That is, any navigation to that page should also render the same HTML. 3. The server needs to be aware of the state. When a user requests page.com/checkout?step=2, the server should know if the HTML form requires pre-filled values.

This increases a bit the complexity on the server, but I believe it reduces the client-side complexity a lot more.