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

11–20 of 188 posts

Re: URL-Driven State in HTMX

#11

Post by PenguinCoder »

trentnix wrote: post #10
rorylaitila wrote: post #9

Earlier quoted context omitted.

Maybe, I'm not an HTMX user, but looking at hx-swap-oob I think that solves another issue. My need was when other links can exist in any place, and they need to match the URL after its clicked. I didn't want to have the performance hit or remember to add extra swaps just to get links up to date. The feature basically is "when a param is marked to be synced, ensure all links on the page are updated to match the change…

I’ve been building a Golang web platform for my own web apps and I wired up toaster notifications using hx-swap-oob. I just populate a ‘notifications’ slice in my view model and hx-swap-oob makes sure my toaster messages get loaded irrespective of what content is actually being swapped. It sounds like a similar use case to yours.

Are you able to share the code you have for this? I have a similar need use case and using golang and Htmx for my app.

Re: URL-Driven State in HTMX

#12

Post by PaulHoule »

cadamsdotcom wrote: post #3

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

Doesn't react-router do something like this?

Re: URL-Driven State in HTMX

#13

Post by rorylaitila »

trentnix wrote: post #10
rorylaitila wrote: post #9

Earlier quoted context omitted.

Maybe, I'm not an HTMX user, but looking at hx-swap-oob I think that solves another issue. My need was when other links can exist in any place, and they need to match the URL after its clicked. I didn't want to have the performance hit or remember to add extra swaps just to get links up to date. The feature basically is "when a param is marked to be synced, ensure all links on the page are updated to match the change…

I’ve been building a Golang web platform for my own web apps and I wired up toaster notifications using hx-swap-oob. I just populate a ‘notifications’ slice in my view model and hx-swap-oob makes sure my toaster messages get loaded irrespective of what content is actually being swapped. It sounds like a similar use case to yours.

Gotcha, I think I looked at hx-swap-oob before for inspiration, but didn't see it working for this case, I'll look again.

Re: URL-Driven State in HTMX

#15

Post by Twey »

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

Re: URL-Driven State in HTMX

#16

Post by nosefurhairdo »

PaulHoule wrote: post #12
cadamsdotcom wrote: post #3

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

Doesn't react-router do something like this?

Yep, `useSearchParams()`. At work I built a wrapper to incorporate zod schemas for typesafe search param state. Nuqs is the best for this if your application meets its prerequisites: https://nuqs.47ng.com/

Re: URL-Driven State in HTMX

#17

Post by mrits »

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

Re: URL-Driven State in HTMX

#18

Post by t-writescode »

cadamsdotcom wrote: post #3

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

> is fantastic UX but never gets implemented because there’s never time

Wouldn't the change take something like an hour the first time you implement it and then 10s of seconds for calling the centralized function henceforth?

I don't think the problem is "there's never time"; and if that is the problem, I don't think an LLM will "solve" that, especially since studies have shown developers are slower when they use LLMs to code for them.

Post reply on HN