Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

URL-Driven State in HTMX

lorenstew.art

Post reply on HN
Print view View original

51–60 of 188 posts

Re: URL-Driven State in HTMX

#51

Post by ashwinsundar »

trentnix wrote: post #10
rorylaitila wrote: post #9

Earlier quoted context omitted.

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.

I have something similar setup for toast notifications in Django (Python). I have a notifications "partial" defined, which gets returned as part of an out-of-band swap by any view function that desires to use it. This includes other partials as well. It's how I chain fragment replacements together.

As an aside, I love that we can have this conversation - people in entirely different stacks can talk a similar language, through the glue of HTMX. This is why htmx is good for web development

Re: URL-Driven State in HTMX

#53

Post by ashwinsundar »

NegativeLatency wrote: post #8
o11c wrote: post #7

Note 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.

They failed as a company?

Re: URL-Driven State in HTMX

#54

Post by bravesoul2 »

nebezb wrote: post #25
wackget wrote: post #22

Earlier quoted context omitted.

Dunno why you've been voted down; you're totally right. The method you mention is called token/cursor/keyset-based pagination.

He’s being downvoted because suggesting cursor pagination in an example describing sorting by price (descending) is plainly wrong. While neither is bookmarkable, cursor pagination is much worse. The UX went from “show me _almost_ the most expensive items” to “show me everything less expensive than the last item on the page I was on previously — which may be stocked out, more expensive, or heavily discounted today”. T…

I agree. Most people won't expect urls to provide a wayback-machine style snapshot. Although you could add that as an option "save results as link".

Re: URL-Driven State in HTMX

#55

Post by mediumsmart »

wredcoll wrote: post #34
NegativeLatency wrote: post #8

Earlier quoted context omitted.

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.

Oh boy, hashbangs are back. The first one that comes to mind was twitter...

I think LinkedIn won the stuffedURLbufferOverflow Olympics back in the day.

Re: URL-Driven State in HTMX

#56

Post by johnisgood »

Arch-TK wrote: post #21

Next you'll tell me the URL can contain information which can be used to auto-scroll you to a specific heading.

Not even only that, but it can auto-scroll to ANY parts these days, see: "URL Text Fragments".

https://www.lexo.ch/blog/2025/01/highlight-text-on-page-and-...

In any case, yeah, what was suggested in the submission is nothing esoteric, but I guess everything can be new to someone.

Re: URL-Driven State in HTMX

#57

Post by bubblyworld »

Twey wrote: post #15

The example URL here, though, is still not (helpfully) bookmarkable because the contents of page 2 will change as new items are added. To get truly bookmarkable list URLs, the best approach I've seen is ‘page starting from item X’, where X is an effectively-unique ID for the item (e.g. a primary key, or a timestamp to avoid exposing IDs).

Yeah, solving this edge case properly can add a lot of complexity (your solution has the same problem, no? deletes would mess it up as would updates, technically). I've seen people using long-lived "idempotency tokens" point to an event log for this but it's a bit nuts. Definitely worth considering not solving it, which might be a more intuitive UX anyway (e.g. for leaderboards).

Re: URL-Driven State in HTMX

#58

Post by chii »

btown wrote: post #35

> treating URL parameters as your single source of truth... a URL like /?status=active&sortField=price&sortDir=desc&page=2 tells you everything about the current view Hard disagree that there can be a single source of truth. There are (at least) 3 levels of state for parameter control, and I don't like when libraries think they can gloss over the differences or remove this nuance from the developer: - The "in-progres…

> All of those questions and more will vary between applications. One size does not fit all.

all of those come from the fundamental "requirement" set out earlier to have no in-page state, but still require the webpage to behave as tho it did.

If you remove this requirement, then it will be like how it was back in the 2000's era web pages! And the url does indeed contain the single source of truth - there are no inflight requests that are not also a full page reloads.

Re: URL-Driven State in HTMX

#59

Post by franky47 »

cadamsdotcom wrote: post #3

This 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…

> Still the boilerplate makes me wonder if it belongs in a library, eg. a React hook that’s a drop in replacement for `useState`

That’s exactly what `nuqs` does (disclaimer: I’m the author).

> Backend logic would still need to be implemented

Assuming your backend is written in TypeScript, you can use nuqs loaders to reuse the same validation logic on both sides.

https://nuqs.47ng.com

Re: URL-Driven State in HTMX

#60

Post by aitchnyu »

cloudking wrote: post #20

I like the simplicity. I've been building some web apps with Alpine.js recently, another lightweight React alternative. It's pretty powerful and capable for building reactive SPAs, only ~16kb. https://alpinejs.dev/ https://github.com/alpinejs/alpine

There is Alpine Ajax, their HTMX counterpart.

https://alpine-ajax.js.org/

Post reply on HN