https://htmx.org logo
Powered by
# htmx-general
  • g
    So, it seems like overkill if you really only need to update individual rows, but wrap them all in their own TBODy tag, and it should work beautifully. I do something similar for infinite scrolling in a table (each body of 60 rows just knows when to load the next body of 60 rows) and it feels like butter.
  • g
    Yeah, if you can just update the whole table, that's probably best. It turns out that it's probably not much extra work to just update everything, but you can really start complicating your app if you try to get really granular. I'd try to avoid it if you can 🙂
  • f
    If I treat the one source of truth as the db, then indeed, enforcing full table update is probably the way to go.
  • f
    Then I only have to worry about, are all my updates in place, now update the table. Rather than anything more complicated.
  • f
    So I need a way to have db updates occur on the back end while the page with table live. and a way to trigger an update of the table to the page itself on completion.
  • f
    Just thinking aloud
  • f
    If I use the hx-trigger 'every' dsy set to 30sec, I worry that I will wait for 30 seconds before triggering a referesh set of API calls, whereas what I think I want are
  • f
    Load page with exisitng values, immmeadiately trigger a set of API calls, update db, update table in page, then wait 30 seconds and repeat.
  • f
    Bur I suspect I am missing the point.
  • f
    The first thing I will have to likely do is get htmx based polling and table replace working at all, using dummy but obviously changing data.
  • f
    Really wish there was a relavant example for me to chew on, but I understand I may be a corner case...
  • f
    anyway, greatly appreciate the chance to muse on thoughts and any / all pointers appreciated, I will go break my app and see if I can put it back together....
  • g
    Yeah, chances are it will be fine just like this.
  • g
    It will definitely be fine if you can make a batch update (or a transactional update) on the table, but that may not be practical.
  • g
    Instead of polling, you can also consider server push -- WebSockets is better known, but SSE is lighter and easier. Htmx supports both.
  • g
    Then, you can have your back-end app do all its updates, then trigger a push update that gets dropped into every connected client's page instantly. No polling. Tons of saved bandwidth.
  • g
    It takes a bit of work to make your server able to send SSE (or WebSocket) updates, but it's absolutely worth it.
  • f
    Sounds good, any advice on where I can start reading, I do think it makes more sense to have a server update push, but not clear to me how to have flask trigger the relevant background API calls when the relevant page is in scope ( and stop them when not ))
  • f
    Guess the first thing I should try is to set up a htmx behaviour on the overall table, have it render the true data on the first pass, then some trigger to render obvious junk, that will at least be my frist htmx PoC
  • j
    so, will there be multiple users running your app simultaneously?
  • j
    and will they be looking at the same info, or is the query dependent on the user?
  • g
    Both are possible with SSE, by the way. I wrestled with this for a while, because different users might be looking at different "views" of a particular record.
  • g
    My solution (for now, anyway) was to NOT keep this state information on the server. Although it's possible to do, it was more complexity that I wanted to deal with at the moment. So, my SSE server just sends a message to the client saying that "something about record #123 has changed." Then that triggers a reload via 
    hx-trigger
    and the client can reload their personalized view of the page (with URL parameters and everything else).
  • g
    Like I said, I could save a round-trip to the server by pushing the correct data as soon as a row is updated, but this just shows that there are lots of ways to skin this cat.
  • j
    yeah, i was thinking about server-side caching. "every 30 seconds" can sometimes be wildly unevenly distributed depending on user pattern. if you're serving the same info (like a sensor feed) to every viewer, schedule it on the server, cache the result somewhere between the sensor and the user. but if every user might be making a different request every 30 seconds, there's a different set of constraints.
  • f
    at this time, multiple concurrent users, with sepertate data trees, however, I would envisage that tables could end up shared in the future
  • j
    i would look hard at SSE if that was my use case.
  • f
    exactness in time domain is not critical, consider it an indicator only, but I do want it to be timely if reasonable
  • f
    Right now I am unfrotuantely struggling to get the basics of htmx working, I set up what I thought woudl be a polled call from the web page back into the server side every X seconds, but I don't hink I have my basic tagging correct
  • f
    {% extends "base.html" %} {% block app_content %} <!-- --> Systems <div id="systems-table" hx-get="systems_table/{{ current_user.username }}" hx-trigger="every 10s"> {{ render_partial('systems/_systems_table.html', systems=systems) }} {% endblock %}
1...493494495...1146Latest