Next you'll tell me the URL can contain information which can be used to auto-scroll you to a specific heading.
URL-Driven State in HTMX
21–30 of 188 posts
Re: URL-Driven State in HTMX
#22The 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).
Dunno why you've been voted down; you're totally right. The method you mention is called token/cursor/keyset-based pagination.
Re: URL-Driven State in HTMX
#23Next you'll tell me the URL can contain information which can be used to auto-scroll you to a specific heading.
Sorcery!
Re: URL-Driven State in HTMX
#24Our dealership listings page is largely run with this pattern, as well as most of our plugins. Nothing new and very dependable. Forgo HTMX for one less dependency.
Re: URL-Driven State in HTMX
#25The 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).
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”. The latter isn’t something you’d bookmark.
Re: URL-Driven State in HTMX
#26This 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…
> never gets implemented because there’s never time
In my experience that time is saved and more when you find you no longer need to manage Zustand/redux stores to track application state. This pattern works beautifully when incorporating the query parameters as query keys with tan stack query too.
Re: URL-Driven State in HTMX
#27This is a great pattern to follow, and I highly recommend understanding it even to those working on projects that are full client-side SPAs.
Its too easy to jump right in to react, NextJS, etc. Learning why URLs work the way they work is still extremely useful. Eventually you will want to support deep linking, and when you do the URL suddenly becomes really important.
Remix has also been really interesting on this front. They leaned heavily into web standards, including URLs as a way of managing state.
Re: URL-Driven State in HTMX
#28This is a classic pattern of web applications from the 1990s. Works amazingly well even w/o HTMX
One of the legitimate grievances of SPAs is that they made this pattern less obvious.
I find the whole thing where you configure your web server to serve the same thing from
http://example.com/application
http://example.com/application/with/path?and=parameters
http://example.com/item/448828
http://api.example.com/item/448827
http://api.example.com/item/448828
http://api.example.com/item/448829
Re: URL-Driven State in HTMX
#29This 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…
At work we have a hook for that with various backends (memory, local storage, redux, and search params). Supports page, offset, and cursor pagination.
https://stackblitz.com/edit/github-8ssor8-rqkyew8w?file=src%...
Re: URL-Driven State in HTMX
#30The JS world leaves me more and more perplexed.There's a similar rant about forms, but why is this so hard? Huge amount of dev time spent being able to execute asynchronous functions to the backend seamlessly yet pretty much every major framework is just rawdog the url string and deal with URLSearchParams object yourself.
Tanstack router[1] provides first class support for not only parsing params but giving you a typed URL helper, this should be the goal for the big meta frameworks but even tools like sveltekit that advertise themselves on simplicity and web standards have next to zero support.
I've seen even non JS frameworks, with like fifteen lines of documentation for half baked support of search params.
The industry would probably be better off if even a tenth of the effort that goes into doing literally anything to avoid learning the platform was spent making this (and post-redirect-get for forms) the path of least resistance for the 90% of the time search params are perfectly adequate.
I don't use HTMX but i do love how it and its community are pushing the rediscover of how much simpler things can be.
[1] https://tanstack.com/router/latest/docs/framework/react/guid...