How to get a refreshed content on navigating back?

[Alireza-Farahani]

Suppose I have two pages, "Articles List" and "Article Detail". If I change an article in "Article Detail" and go back to "Articles List", I expect too see the applied changes.
However with Htmx and hx-push-url I lose this, since it just restores the previous state of the DOM. As a workaround I can:

• Redirect user to "Articles List" after applying/saving the change in "Article Detail" --> Not good in UX terms in my case.
• Avoid using Htmx and hx-push-url and use full-page requests so let browser's back button load a refreshed page --> I do love SPA feel and faster load time Htmx provides.

Is there a way I can tell Htmx that on navigating back, retry the hx-get request? Is this a reasonable thing to do with Htmx?

[David-Guillot]

Hm that's an interesting point @Alireza-Farahani . Makes me think that htmx should comply to HTTP headers and avoid caching the current DOM when pushing history if server sent Cache: no-store in the first place. This way, you could mark your list page as non-cachable, push the URL change, and htmx would fetch the list page when hitting Back button as it would get a Cache:Miss in internal cache. What do you think @1cg ?

[gnat]

Wild guess but would "trigger on load" or "lazy loading" work for your purpose? hx-trigger="load, submit"

[Alireza-Farahani]

No unfortunately not. To provide more context, I return a full page html but use hx-select and hx-target to just swap the changing part. (I know It could be handled better, but anyway...). So basically I want some way to when I hit back, Htmx performs the last operation again, to get a refreshed content and swaps that again with Cached page.

[Satyam]

I found myself in a similar situation. From the list I can navigate to the details of any item, where I can edit it and, though I have provided the user with a link to go back to the listing, where it forces a refresh, there is nothing preventing the user to simply press the back button on the browser which recovers the last view from the cache and shows a stale view. On the other hand, the user might decide not to make any changes to the item and simply go back, which does not warrant a page refresh since nothing was changed.

My solution was to invalidate the cache on the client, where a snapshot of the page is stored when navigating away, and restored when returning. If HTMX doesn't find the cache entry for a URL it wants to go back to, it simply fetches the page again.

On the server side, in my case an Express server, I have a function to ask the client to invalidate one or more entries in the history cache:

export const invalidateCache = (res: Response, ...urls: string[]) => {
  res.header('HX-Trigger', JSON.stringify({ invalidateCache: urls }));
};

I can call that function from the handler for the POST of the changed data, thus it doesn't do anything if a change was not actually done.

On the client side, I have the following listener, most of it based on the code in https://github.com/bigskysoftware/htmx/blob/master/src/htmx.js#L1887-L1912 :

        const invalidateCache = (url) => {
          const historyCache =  JSON.parse(localStorage.getItem('htmx-history-cache')) || [];
          for (let i = 0; i < historyCache.length; i++) {
            if (historyCache[i].url === url) {
              historyCache.splice(i, 1);
              localStorage.setItem(
                'htmx-history-cache',
                JSON.stringify(historyCache)
              );
              return;
            }
          }
        };
        document.body.addEventListener('invalidateCache', (evt) => {
          evt.detail.value.forEach(invalidateCache);
        });

The server side function accepts multiple URLS so the event listener on the client loops through each. For each one, it deletes the entry in the cache corresponding to that URL and, if found, saves it. I haven't changed it much from the code I copied from HTMX's source. I'm still working on it, perhaps optimizing the loop, or allowing wildcards for whole subtrees of URLs. It should also ensure the URL starts with a slash. I'm just starting to work on the idea so I'm sure I'll bump into plenty of issues.

Of course theinvalidateCache function can be called directly within the client, I didn't explore that yet, it would probably work just fine. A htmx.invalidateCache function perhaps. I'm just starting to work on it so I'd appreciate any suggestions on this or alternate solutions.