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

41–50 of 188 posts

Re: URL-Driven State in HTMX

#41

Post by delifue »

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…

Yes the simple solution is obviously not perfect in edge cases. It's a tradeoff between simplicity and edge-case-perfectness.

In my opinion the higher priority task is to optimize the query in backend so that it can refresh quickly. If loading is quick enough then that edge case will be less likely to happen.

Re: URL-Driven State in HTMX

#42

Post by the_arun »

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 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?

Re: URL-Driven State in HTMX

#43

Post by oxidant »

the_arun wrote: post #42
nebezb wrote: post #25

Earlier 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?

Not if the items change relative position over time.

Re: URL-Driven State in HTMX

#44

Post by scarmig »

the_arun wrote: post #42
nebezb wrote: post #25

Earlier 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?

This depends on use case and who or what is actually consuming the pages. Most of the time, humans don't actually want the same list for all time (though what follows would work for them).

The only way to have a static list is to have an identifier for the state of the list at a certain time, or a field that allows you to reconstruct the list (e.g. a timestamp). This also means you need to store your items' data so the list of items can be reconstructed. Concretely, this might mean a query parameter for the list at a certain time (time=Xyz). When you paginate, either a cursor-based approach, an offset approach, or a page number approach would all work.

This is not what most human users want: they would see deleted items, wouldn't see added items, and changes to fields you might sort on wouldn't be reflected in the list ordering. But it's ideal for many automated use cases.

ETA: If you're willing to restrict users to a list of undeletable items that is always sorted, ascending, by time of item creation, you can also get by with any strategy for pagination. The last page might get new items appended, and you might get new pages, but any existing pages besides the last page won't change.

Re: URL-Driven State in HTMX

#45

Post by valenterry »

DimmieMan wrote: post #30

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

> 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

Let's not pretend that the Tanstack solution would be good. For example, What if my form changes and a new field is added but someone still runs the old html/js and sends their form from the old code? Does Tanstack have any support to 1.) detect that situation 2.) analyze / monitor / log it (for easy debugging), 3.) automatically resolve it (if possible) and 4.) allow custom handling where automatic resolution isn't possible?

It doesn't look like it from the documentation.

Sorry, frustration is causing me to rant here, but it's a classical thing of the frontend-world and it causes so much frustration. In the backend-world, many (maybe even most) libraries/frameworks/protocols have builtin support for that. See graphql with it's default values and deprecation at least, see avro or protobuff with their support for versions, schema-history and even automatic migration.

When will I not have to deal with that by hand in my frontend-code anymore?

Re: URL-Driven State in HTMX

#47

Post by johnisgood »

scarmig wrote: post #44
the_arun wrote: post #42

Earlier quoted context omitted.

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?

This depends on use case and who or what is actually consuming the pages. Most of the time, humans don't actually want the same list for all time (though what follows would work for them). The only way to have a static list is to have an identifier for the state of the list at a certain time, or a field that allows you to reconstruct the list (e.g. a timestamp). This also means you need to store your items' data so t…

Someone said he is being downvoted for suggesting cursor-based pagination, yet one of your suggestions was the cursor-based approach, and as thus, I do not understand why he is being down-voted if it is a legitimate approach, which I believe it is.

I guess we would have to hear nebezb's solutions.

If you are already sorting by price and you bookmark at the second page (which now would be in the 3rd), what would you do? I personally do not care about the item in a sorted list enough to expect a bookmarked URL to start from there, or I cannot remember when I did and why. Any ideas why would one want this? If I bookmark second page, I know that the items on page 2 may not always be on page 2. Why would anyone expect different? If you want to bookmark an item, just go to the product itself and bookmark that. I do not think I ever bookmarked a specific page expecting that to never change.

Re: URL-Driven State in HTMX

#48

Post by tossandthrow »

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…

Well, this really depends on the intention: are you looking for the cheapest items, excluding the 20 first, or are you linking to a content list.

I use Occams razor to decide this, and conceptually it is simpler to think that you are linking to a content list - so that is likely the right answer.

Re: URL-Driven State in HTMX

#50

Post by ashwinsundar »

rorylaitila wrote: post #5

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

You don't need to do anything different to the other URLs on the page, by default all parameters are passed along in every request, so you just need to retrieve any expected url parameters in the server code

https://htmx.org/attributes/hx-params/

Post reply on HN