How to track "in-progress" frontend state?

[adamcunnington-mlg]

By "in-progress" state, I'm talking about a user interacting on some frontend web page and progressively doing stuff; filling out a form, adding rows to a table, deleting rows etc. etc. etc. Eventually they are going to click "Submit" or "Save" but until that point, I'm trying to figure out how one manages such state in an HTMX-app context where I am trying to avoid writing javascript.

In a SPA, frontend manages all state in browser memory via javascript - redux and the like.
In a MPA, backend manages all state. Frontend posts state via html form. This is straightforward though because the page's structure is not dynamic so the HTML form can keep track of "in-progress" state and then post when ready.

With HTMX, as far as I can understand, we're sort of in a half-way house. Technically, it's an MPA but we're refreshing parts of the page via AJAX and thus, my frontend user-input is of a dynamic structure.

As far as I can tell, every time the user does something in the frontend - iterating on their "in-progress" state, the frontend must send this to the backend and the backend must keep track. The backend could store in session cookie, backend in-memory cache or persistent store (likely not this though as the data is not yet "submitted") but aside from other challenges, I am stumbling over the very first hurdle which is how can the backend actually RELATE state from a particular "context". If I open 3 tabs and have 3 concurrent "in-progress" journeys, however I choose the store the "in-progress" state, I need to be able to know which one relates to which. So I need some sort of deterministic key that the frontend can use to only grab it's state. But what could such a deterministic key be? I've not inserted anything into a database yet and some "request id" isn't good enough. I need "tab id"!

The only option I can think of is perhaps using a websocket - I don't know much about this beyond the general way in which it works - but is that the right way to keep track of progressive state?

I feel like my scenario is a really common one but the solution is really unobvious to me. Is the answer simply "well, this is where you actually do need to use javascript and you should do that alongside htmx - perhaps redux".

Help! Thanks!

[adamcunnington-mlg]

Or maybe I'm over complicating this and html forms are fine and I just have to be careful when refreshing PARTS of the form so I don't lose any state. All "in-progress" tab state will be in the DOM and I can just select the bits that I want when posting?

[adamcunnington-mlg]

@Telroshan thanks again for this - I'm clear now that you used the websockets for something slightly different.

Back to the core of the question - if I want my backend to track "in-progress state" from the frontend and I want to impose the following deliberate constraints:

• does not use cookie because not big enough
• don't want to use backend in-memory cache because a) expensive and b) i'd have to emulate a lot of behaviour you get for free when using browser session state

... then what are my options? I think the only option would be to use browser local storage (or better still, session storage) - which presumably has a mucher higher limit than 4KB. I don't think HTMX allows me to interact with localStorage directly - but I could do this via javascript or hyperscript?

Again, I can't help but feel that my use case is not that unorthodox but super unclear how to do this in htmx context. I guess in a frontend framework, the framework would do this stuff for you (e.g. redux via browser local storage).

[Telroshan]

Just to be sure there,

if I want my backend to track "in-progress state"

But what you're describing with your constraints & goals, is having instead your frontend track the in-progress state and not the backend at all, or did I miss something?

Could you by any chance provide a step-by-step usecase defining what you're trying to achieve (as the user, the functional process) ? I'm afraid my mid-tier English is getting in the way here and I can't fully grasp what you're trying to do exactly

[adamcunnington-mlg]

Sure, thanks for the willingness!

So, imagine I have a pagined table in my frontend - the contents are provided by backend, via HTMX request/response.
I want to allow users to edit details in this table as well as do typical table control stuff - click on header to order etc. Each interaction with the table will send request to backend. Backend will merge the "in-progress" state with actual data and return the results (entire HTML table) accordingly.
Imagine a user has edited a row (which is currently in the DOM) but now clicks on a header that would cause this row to be ordered in a latter page. When the backend returns the updated table (page 1), that edit won't be in the DOM and it will be "lost".
Therefore, the backend must keep track of this in-progress state. The backend needs a persistent, fast "cache" that follows session semantics (including ability to correlate information to a given "tab id" - you've solved this by backend persisting some generated ID into the HTML which frontend can include in subsequent requests). Session cookie is a nice idea but it's too small. Backend global cache (e.g. memorystore) is nice but expensive. Backend database is too "heavy" and slow. The right solution feels like using browser local storage / session storage (even better because this has "tab id" stuff built-in). Indeed, this is how I understand most frontend frameworks work. React makes use of session storage.

My question is how I can interact with session storage. I think backend can only return information to client and client must do the interaction. I think this must be by javascript or hyperscript. Am I correct?

[Telroshan]

Ooooh ok I understand now, thanks for the details!
Yeah htmx doesn't provide any session storage utility as it's a pure client-side thing and htmx is really meant for server-side communication.
I'm not a hyperscript user so I couldn't tell you if it already exists in the lib or not, but that's the kind of thing I would expect it to be able to do. The cheatsheet references the following

localStorage.foo value in local storage

sessionStorage isn't referenced in that doc, but I would expect it to be available as well
Otherwise indeed, vanilla JS will do the trick!

In that specific use case you described though, I think I would have personnally used hx-include on the table to include any "staging form" or inputs that are inside. Then get the values from the backend, and restore the "in progress state" from there.
It's rough but here's the idea I was thinking about in this JSFiddle

• hx-include on the headers to include closest table, which will include any input value defined in the table, in the request (imagining clicking on the headers would sort the rows here)
• hx-get on the initial rows, that bring in an editable version when clicking on them (values are not retrieved here ofc since you would get them from the DB typically, but you get the idea)
• In the editable rows, you define a hidden input for the ID of that row, and make each column an input
• Now, when you click on the headers, all "in-progress" rows will be sent along, in order, to the backend
  
• From there, I would retrieve those form values in my backend, and set a boolean in the data I pass (to render the HTML) to render either the initial row or the editable one. Also override the row's values with the "staging" ones before rendering
• The benefit here is that you don't even need to bother using session storage or anything, everything is directly in the HTML, and automatically sent to the backend. But I guess it's a matter of preference here, I prefer moving that kind of work on the server, but you may totally stick to client side logic and use session storage instead!

Hope that makes sense, and helps 😆

[Edit : updated the JSFiddle URL as I of course forgot to save the latest changes]

[adamcunnington-mlg]

Amazing! I will fully digest this but this is much appreciated - kind of you, thank you.