Can I use the browser local cache with HTMX?

[hrstoyanov]

I am looking for some easy element attributes to swap out chunks of the Dom with something from the local browser cache. Also , some more sophisticated scenarios:

1."Swap out the inner/outer html with chunk from local cache with key X, or fetch it from the server"

2. "Swap out the inner/outer html with cached chunk under key X but only it is older than Y milliseconds"

3. "Swap out ... From http request, but then also store the response in local cache"

Note:

1. This is different from server response cache mechanisms in http.

2. It is like an "htmx magic dust" sprinkled over the browsers cache api

[dz4k]

What advantage would this have over normal caching in browsers with the Cache-Control header?

[binaryfire]

@dz4k I think the problem is cache invalidation. Let's say you're caching fragments of a dashboard for 5 minutes to prevent unnecessary requests and keep things snappy while a user is navigating around. And then one of those cached fragments needs to be invalidated because the user has added new data.

The only way (that I know of) for a server side webapp to clear the browser cache is using Clear-Site-Data. But that's not viable until it's supported in Safari. And knowing Apple that could be years away...

But if you implement caching in JS via local storage you can clear it whenever you want. Eg. when a form is submitted.

[HeyHugo]

@binaryfire / @hrstoyanov You should check out this article on caching https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching
Section regarding validation may be of particular interest.

[binaryfire]

@HeyHugo I'm familiar with that article. But it doesn't change what I said above? Clear-Site-Data seems to be the only way a server can programmatically invalidate browser cache and it's not supported on Safari yet (unfortunately). And you'd still need to hit the server on every page load to check if the content has been modified.

Maybe I'm missing something... I'm coming from building dashboards with Tanstack Query where things like stats graphs, data tables etc. are cached client side until the user does something that needs them to be invalidated. At which point the the cache is purged from the store.

There's noticeable latency for users far away from our server (eg. Australia -> US) when the server needs to be hit on each page load to check for stale content. There probably isn't any way around it since state is server-side with HTMX. Which is fine: the hybrid approach of HTMX + a lightweight JS framework works well too.

[Nasjoe]

Something like an hx-cache with parameters that would allow the three scenarios mentioned by @hrstoyanov in the first post would be great.

This could also open up possibilities for building web and mobile applications with an easily configurable offline mode.

Personally, I'm also very interested.

[nickchomey]

A service worker is probably the best option for implementing any of this (and opens up lots of other possibilities).

It will intercept all requests before going out to the network and returning to the dom. So you can store the responses in any of the browser storage apis - cache, local storage, session storage, indexeddb etc.

I'd suggest indexeddb as it offers the most possibilities. There's plenty of libraries made for working with all of this - Google workbox, idb, dexie, rxdb, etc

[Nasjoe]

I would sponsor this feature without hesitation!