thomaseizinger
commented
1 year ago There is the preload extension which could help with the list > details workflows that you mentioned: https://htmx.org/extensions/preload/
Open frederikhors opened 1 year ago
thomaseizinger
commented
1 year ago There is the preload extension which could help with the list > details workflows that you mentioned: https://htmx.org/extensions/preload/
thomaseizinger
commented
1 year ago 2. I'm really productive with code like frontend calculation only, example: the sum of invoices rows; I mean, list of something to calculate on frontend only without backend calls at all.
I'd say the way to think about this is that the webserver serving your HTML is your frontend. The sum of invoice rows is not going to change without an invoice being deleted or added which needs a server-roundtrip anyway. That roundtrip sends you back the new HTML to render.
In a way, you need 0 backend calls and avoid writing an API to start with because your server can just render HTML based on what is in its database.
danielkeller
commented
11 months ago I had a similar idea of an "hx-local" or "hx-template" attribute: it acts like hx-get, except instead of a url it takes an element reference, and the "ajax response" instead comes from the innerHTML of the element. This would work well with elements (since they hold a dom fragment without it being visible). After being inserted into the real dom, the template's contents would fetch the fresh data from the backend and update itself.
The stale data in the could be populated in a number of ways. For example it could start with an empty ui, or be preloaded with Cache-Control: only-if-cached, etc.
thomaseizinger
commented
10 months ago Isn't this already possible by adding an hx-get to a regular div?
The content of the div will be immediately rendered, the AJAX request runs in the background and updates the UI as soon as it is finished.
On the first page load, this isn't very useful because the UI is already coming from the server (assuming the DB query isn't super expensive).
But if the HTML is served from the local browser cache (if the user presses back for example?), then I think this would trigger a new AJAX request and update the data.
However, I do think the whole SWR pattern isn't as useful as for SPAs because you typically just get the new UI from the server anyway.
frederikhors
commented
10 months ago Do we have an example? @thomaseizinger
nickchomey
commented
10 months ago It seems to me that something like this would be best done as part of a broader effort to build some sort of pwa integration/extension into HTMX - there's a lot of useful caching strategies aside from stale-while-revalidate.
There's already Google's Workbox library for implementing caching strategies (and much more). But it's somewhat large and also seemingly abandoned. So, there's probably an opportunity to create some sort of htmx-workbox extension that could implement select features of workbox - be it by directly porting code, or re-writing as-necessary.
I'd be open to contributing to this in a few month's time, if others are interested in collaborating.
thomaseizinger
commented
10 months ago Do we have an example? @thomaseizinger
Of what exactly? Adding hx-get to a div? I'd say the reference explains that pretty well: https://htmx.org/attributes/hx-get/
This blog post discusses more ideas of what you can build with that: https://anto.pt/articles/rust-server-components
frederikhors
commented
10 months ago I better explained what I need here: https://github.com/bigskysoftware/htmx/discussions/1706#discussioncomment-6807043.
Isn't this already possible by adding an
hx-getto a regulardiv?The content of the
divwill be immediately rendered, the AJAX request runs in the background and updates the UI as soon as it is finished.
Maybe this can work with service-workers?
thomaseizinger
commented
10 months ago I better explained what I need here: #1706 (reply in thread).
I see. The following could be interesting, I think it is possible to implement as an extension:
htmx::afterRequest event. You might want to inspect the Cache-Control header to see if caching is allowed.htmx::beforeSend event, look in the cache and swap in the last item you find, perhaps together with a small indicator, telling the user that the data is being updated.The above implies that you are already offloading certain components in your HTML page using hx-get. You'd probably also want to make the above behaviour conditional based on same attribute on an hx-get node.
I think that HTMX will still run the AJAX request in the background and perform the swap with the actual, fresh data.
cc @1cg would know more about the inner workings.
frederikhors
commented
10 months ago @thomaseizinger It would be amazing to have a repl online for this! :smile:
andryyy
commented
10 months ago I usually send the most recent data in the first full page response and only then use Ajax calls to refresh. I don't think it's cool to render any page and then have 20 requests properly loading the site. This is more of a UX fail than the other way round.
Seeing old data and suddenly have it changed/replaced is also a bit strange. This would drive me mad as user.
thomaseizinger
commented
10 months ago I usually send the most recent data in the first full page response and only then use Ajax calls to refresh. I don't think it's cool to render any page and then have 20 requests properly loading the site. This is more of a UX fail than the other way round.
Seeing old data and suddenly have it changed/replaced is also a bit strange. This would drive me mad as user.
Definitely for the initial load yes. I can see some value in refreshing parts of the page if you've for example restored a page from a history entry or loaded it from the cache in general.
I do agree that it doesn't fit that well into HTMX and it might introduce weird, inconsistent states that make you do a full page reload anyway.
SWR is nice for SPAs that differentiate between the shell and actual data being displayed. That isn't really the case in HTMX because you can just load the full page with fresh data using little bandwidth.
@thomaseizinger It would be amazing to have a repl online for this! :smile:
I don't have a use for it at the moment but the above should give you enough starting points to attempt an implementation yourself :)
Please share if you have something, I'd be curious how the UX works out.
frederikhors
commented
2 weeks ago @thomaseizinger do you have news for this eventually?
thomaseizinger
commented
2 weeks ago @thomaseizinger do you have news for this eventually?
No, I have not been using HTMX for anything lately.
I just found out htmx and I would like to try it as soon as possible.
I also agree that SPAs are a real fatigue.
I'm using SPAs mainly for two features:
I'm obsessed with perceived speed of rendering between pages transition. Especially with list > details workflows I'm using the stale-while-revalidate pattern a lot to increase the perceived speed of data fetching (using graphql normalized cache packages like Apollo and urql).
I'm really productive with code like frontend calculation only, example: the sum of invoices rows; I mean, list of something to calculate on frontend only without backend calls at all.
I searched a lot on Google and here on GitHub about htmx and stale-while-revalidate but nothing showed up.
I was thinking about using service worker for this but found nothing ready.
Can you help me find a way?
What do you think?
UPDATE:
I better explained what I need here: https://github.com/bigskysoftware/htmx/discussions/1706#discussioncomment-6807043.