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

61–70 of 188 posts

Re: URL-Driven State in HTMX

#61

Post by tempfile »

chii wrote: post #58
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 infli…

The example they used for "in progress" state was form inputs. Don't you count those as in-page state?

Re: URL-Driven State in HTMX

#63

Post by crabmusket »

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

Datomic + put the database version in the URL :)

Re: URL-Driven State in HTMX

#64

Post by chii »

tempfile wrote: post #61
chii wrote: post #58

Earlier quoted context omitted.

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

The example they used for "in progress" state was form inputs. Don't you count those as in-page state?

until you pressed enter, this progress is understood to be ephemeral. It has only been recently that the user has been 'conditioned' to expect the form inputs to be retained when they click a link, and it's because the app is trying to retain the state of ephemeral progress.

So you cannot have both a webpage that is not an app, but maintain an app-like behaviour. Trying to do so is a cursed problem, and it might succeed with high effort, but ultimately not worth it.

Re: URL-Driven State in HTMX

#65

Post by actionfromafar »

mrits wrote: post #17
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…

When people start using or buying your software you are going to quickly find out that 64K won't work

640K oughta be enough for everyone.
Post reply on HN