Funny to see query parameters used as intended ... few decades ago
URL-Driven State in HTMX
91–100 of 188 posts
Re: URL-Driven State in HTMX
#92> SEO is built in since search engines can crawl every state combination.
This isn't always a plus - bots can find a very large number of pages to crawl and swamp your server with traffic. Maybe they would get stuck on all the combinations of listing page filters and miss the important pages.
Not saying the conclusion is wrong - just something to consider.
Re: URL-Driven State in HTMX
#93The 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 typ…
Nuqs[0] does a very good job at parsing and managing search params. It's a complex issue that involves serialization and deserialization, as well as throttling URL updates. It's a wonderful library. I agree, though, that it would be nice to see more native framework support for this. Forms are also hard because they involve many different data-types, client-side state, (client?) and server validation, crossing the ne…
I prefer how Angular handles it. It's just HTML with bindings to an object
Re: URL-Driven State in HTMX
#94It's just how web works – storing data in URL params to restore the same state later. With React or whatever library you do the exactly same thing. In this case HTMX doesn't particularly stand out or enable anything new here.
> With React or whatever library you do the exactly same thing. There are many React SPAs where the address bar URL rarely changes, and I have to find some "share" button on the page itself to get the page's URL.
This is a generalization from personal exposure, availability bias. It just points out that some people implement things poorly — ignoring that many well-designed SPAs do use URL state effectively. React itself does not prevent or discourage URL-based state, it's just the developer's choice whether to use routing or no.
Re: URL-Driven State in HTMX
#95I think people are now ready for php. I bet it will be reinvented on top of nodejs.
Indeed, the Platformatic folks announced just that last week:
https://blog.platformatic.dev/laravel-nodejs-php-in-watt-run...
Re: URL-Driven State in HTMX
#96>URLs up to ~2000 characters Exactly, this approach doesn't scale well without trickery involved. You have to have some sort of weird encoding in place to compact it down.
Yup, ASP's "__VIEWSTATE" hidden form parameter comes to mind. It was base64-encoded and POSTed because it could get loooong (hundreds of KB).
Terrible for browser navigation/refresh though, because pretty much everything was a form POST. Thus no URL state sharing, either.
Re: URL-Driven State in HTMX
#97I think people are now ready for php. I bet it will be reinvented on top of nodejs.
As a long time PHP developer, it never fails to amuse (amaze?) me the lengths people go to in order to get the things the browser will give you for free.
Re: URL-Driven State in HTMX
#98The 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).
> The example URL here, though, is still not (helpfully) bookmarkable because the contents of page 2 will change as new items are added. Why is the content changing between refreshes not "(helpfully) bookmarkable"? The HN front page (ie. "page 1") does that but it's a very useful bookmark.
Indeed, thats weird.
He probably wants to freeze the state of the page. Maybe he should consider saving it via ctrl s
Re: URL-Driven State in HTMX
#99Earlier quoted context omitted.
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 cannot think of any other way to bookmark anything static unless I convert it into pdf/screenshot before sharing. Are there better ways to bookmark a list page which guarantees same list forever?
archive.org
Re: URL-Driven State in HTMX
#100> SEO is built in since search engines can crawl every state combination. This isn't always a plus - bots can find a very large number of pages to crawl and swamp your server with traffic. Maybe they would get stuck on all the combinations of listing page filters and miss the important pages. Not saying the conclusion is wrong - just something to consider.
That's why you can give guidance to crawlers using sitemaps.