URL-Driven State in HTMX
lorenstew.art
URL-Driven State in HTMX
1–10 of 188 posts
Re: URL-Driven State in HTMX
#2Ideally, this is how state management should work all the time, regardless. Holding too much state server-side breaks bookmarks and shares.
EDIT: Hmm. Is this comment controversial? Obviously some people disagree strongly. Mind sharing why?
Re: URL-Driven State in HTMX
#3This pattern - saving the query to the URL with the history API - is fantastic UX but never gets implemented because there’s never time. Luckily an LLM can build this quickly as it’s straightforward and mostly boilerplate.
Still the boilerplate makes me wonder if it belongs in a library, eg. a React hook that’s a drop in replacement for `useState`. Backend logic would still need to be implemented. Does something like this exist?
Re: URL-Driven State in HTMX
#4This pattern - saving the query to the URL with the history API - is fantastic UX but never gets implemented because there’s never time. Luckily an LLM can build this quickly as it’s straightforward and mostly boilerplate. Still the boilerplate makes me wonder if it belongs in a library, eg. a React hook that’s a drop in replacement for `useState`. Backend logic would still need to be implemented. Does something like…
Agreed I love this pattern! I'm a big fan of using nuqs for this in nextjs, but really stoked to try out rust / loco / htmx for my next project.
Re: URL-Driven State in HTMX
#5I didn't see if you were doing this, but there is an additional use case that I had when using hot swapping like HTMX: updating other links on the page to reflect the URL state, when those links are outside of the swapped content.
While the server can use the URLs to update the links in the new HTML, if other links outside that content should also reflect the changes params, you need to manually update them.
In my progressive enhancement library I call this 'sync-params' https://github.com/roryl/zsx?tab=readme-ov-file#synchronize-...
Re: URL-Driven State in HTMX
#6I didn't see if you were doing this, but there is an additional use case that I had when using hot swapping like HTMX: updating other links on the page to reflect the URL state, when those links are outside of the swapped content. While the server can use the URLs to update the links in the new HTML, if other links outside that content should also reflect the changes params, you need to manually update them. In my pr…
Isn’t that what hx-swap-oob is for?
Re: URL-Driven State in HTMX
#7Note that you can store longer state (at least 64K; more not tested) in the fragment (`location.hash`); obviously only the client gets to see this, but it's better than nothing (and JS can send it to the server if really needed).
For parameters the server does need to see, remember that params need not be &-separated kv pairs, it can be arbitrary text. Keys can usually be eliminated and just hard-coded in the web page; this may make short params longer but likely makes long ones shorter.
You absolutely should not restore state based on LocalStorage; that breaks the whole advantage of doing this properly! If I wanted previous state, I would've navigated my history thereto. I hope this isn't as bad as sites that break with multiple open tabs at least ...
Re: URL-Driven State in HTMX
#8Note that you can store longer state (at least 64K; more not tested) in the fragment (`location.hash`); obviously only the client gets to see this, but it's better than nothing (and JS can send it to the server if really needed). For parameters the server does need to see, remember that params need not be &-separated kv pairs, it can be arbitrary text. Keys can usually be eliminated and just hard-coded in the web pag…
I've seem a largish company everyone here knows of, try this and have it fail, because of various weird client things, and also eventually run out of space in the hash. It's a neat hack but I wouldn't rely on it.
Re: URL-Driven State in HTMX
#9I didn't see if you were doing this, but there is an additional use case that I had when using hot swapping like HTMX: updating other links on the page to reflect the URL state, when those links are outside of the swapped content. While the server can use the URLs to update the links in the new HTML, if other links outside that content should also reflect the changes params, you need to manually update them. In my pr…
Isn’t that what hx-swap-oob is for?
Maybe, I'm not an HTMX user, but looking at hx-swap-oob I think that solves another issue. My need was when other links can exist in any place, and they need to match the URL after its clicked. I didn't want to have the performance hit or remember to add extra swaps just to get links up to date. The feature basically is "when a param is marked to be synced, ensure all links on the page are updated to match the changed param"
Re: URL-Driven State in HTMX
#10Earlier quoted context omitted.
Isn’t that what hx-swap-oob is for?
Maybe, I'm not an HTMX user, but looking at hx-swap-oob I think that solves another issue. My need was when other links can exist in any place, and they need to match the URL after its clicked. I didn't want to have the performance hit or remember to add extra swaps just to get links up to date. The feature basically is "when a param is marked to be synced, ensure all links on the page are updated to match the change…
I’ve been building a Golang web platform for my own web apps and I wired up toaster notifications using hx-swap-oob. I just populate a ‘notifications’ slice in my view model and hx-swap-oob makes sure my toaster messages get loaded irrespective of what content is actually being swapped.
It sounds like a similar use case to yours.