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

101–110 of 188 posts

Re: URL-Driven State in HTMX

#101

Post by patates »

valenterry wrote: post #82
fny wrote: post #76

Earlier quoted context omitted.

The same thing should happen that happens with Rails/Django and friends: nothing. Most frameworks only parse URL params, they don't check to see if the params are valid given your app logic. That's your job. Frankly, anything more would be over kill. Why should my url param manager handle new or removed form fields?

> The same thing should happen that happens with Rails/Django and friends: nothing So you can never make any breaking change to your api whatsoever? Or, in practice, you don't care and let users deal with app crashes and invalid state? Yep, welcome to the frontend-world.

why do you think that this must happen on the front-end? you can make a breaking change and when the user submits an invalid state

a) serve an error page, leaving that to the backend (at some point the backend must validate anyway)

b) serve the regular front-end and react to the invalid state with error messages. there are libraries like zod that should make your job easier.

Re: URL-Driven State in HTMX

#102

Post by lyu07282 »

worldsayshi wrote: post #80
bob1029 wrote: post #79

Earlier quoted context omitted.

At some point I hope it becomes obvious that well-engineered SSR webapps on a modern internet connection are indistinguishable from a purely client side experience. We used this exact same technology over dialup modems and it worked well enough to get us to this point. Being able to click a button and experience 0ms navigation is not something any customer has ever brought to my attention. It also doesn't help much i…

What about a feature like query completion?

there probably is a jQuery plugin for that /s

Re: URL-Driven State in HTMX

#103

Post by bux93 »

rbinv wrote: post #96
ac130kz wrote: post #81

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

Also a terrible idea to execute code from the client, even if it's supposedly signed.

https://darkatlas.io/blog/critical-sharepoint-vulnerability-...

Re: URL-Driven State in HTMX

#104

Post by lyu07282 »

eadmund wrote: post #32
PaulHoule wrote: post #28

Earlier quoted context omitted.

I find the whole thing where you configure your web server to serve the same thing from http://example.com/application and http://example.com/application/with/path?and=parameters to be absolutely nerve-wracking. Not hard to do but it's just batshit crazy and breaks the whole idea of how web crawlers are supposed to work. On the other hand, we had trouble with people (who we know want to crawl us specifically ) crawli…

What I would want is to GET http://example.com/item/448828 with an Accept header of ‘application/s-expression,application/json;q=0.1’ instead of retrieving the HTML representation of the resource. HTTP is the API. I also want http://example.com/application/with/path?and=parameters and http://example.com/application to return Link headers with rel=canonical appropriately. I’d also like world peace.

it felt like this was an opportunity for AI craze to adopt on top of the existing standards, instead they all invented their own stuff with llm.txt and MCP *sigh*

Re: URL-Driven State in HTMX

#105

Post by patates »

torstenvl wrote: post #2

Ideally, this is how state management should work all the time, regardless. Holding too much state server-side breaks bookmarks and shares. EDIT: Hmm. Is this comment controversial? Obviously some people disagree strongly. Mind sharing why?

didn't down-vote you but perhaps you mean tech which holds nearly all client state on the server like JSF or webforms and I think that may be not so clear to some :)

for front-end frameworks, not storing the state on the URL usually means storing it on the memory or sessionstorage and server is usually not involved

Re: URL-Driven State in HTMX

#106

Post by yxhuvud »

bubblyworld wrote: post #57
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).

It doesn't have the problem if a timestamp or similar is used.

Re: URL-Driven State in HTMX

#108

Post by efitz »

johnisgood wrote: post #47
scarmig wrote: post #44

Earlier quoted context omitted.

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

+1000.

There are always trade-offs for architectural decisions.

Re: URL-Driven State in HTMX

#109

Post by gwd »

worldsayshi wrote: post #80
bob1029 wrote: post #79

Earlier quoted context omitted.

At some point I hope it becomes obvious that well-engineered SSR webapps on a modern internet connection are indistinguishable from a purely client side experience. We used this exact same technology over dialup modems and it worked well enough to get us to this point. Being able to click a button and experience 0ms navigation is not something any customer has ever brought to my attention. It also doesn't help much i…

What about a feature like query completion?

The query completion can also be SSR. The example below is HTMX for Active Search, but the principle is the same:

https://htmx.org/examples/active-search/

Re: URL-Driven State in HTMX

#110

Post by jiggawatts »

donatj wrote: post #97
podgorniy wrote: post #66

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

The most "special" code that I regularly come across is when a developer takes a JPG in blob storage -- already a public HTTPS URL -- then serves that in a "Web API" that converts it to base-64 encoded bytes inside JSON, sends it to client JavaScript, decodes it, and feeds it to an image in code.

Invariably, it's done with full buffering of the blob bytes in memory on both server and client, no streaming.

Bonus points are awarded for the use of TypeScript, compression (of already compressed JPGs, of course), and extensive unit and integration tests to try and iron out the bugs.

Post reply on HN