https://htmx.org logo
Join Discord
Powered by
# htmx-general
  • g
    It should already work like that right now.
  • m
    should update the docs
  • m
    to clarify one connect
  • m
    but you can have a child listen for events on multiple sources, if they are on elements above the child in the dom
  • f
    That's interesting ...
  • f
    My system is really braindead right now -- I have a different SSE endpoint for each resource on the server that can be updated.
  • f
    So lots and lots of connections, potentially.
  • f
    I don't know if that's a bad thing. (It might be).
  • g
    First thought: it might be a bad thing.
  • g
    But, you could do it. Each "connect" would just need to be on its own DOM node.
  • f
    It might be better to modify my server so the SSE endpoint represents a 'query' with a list of resources to monitor for changes...
  • g
    Probably better to have a smaller number of connections, then filter things out via EventName, if that's possible with Firebase.
  • f
    I've just got my own uvicorn/starlette python server.
  • f
    So my own logic on back and front end.
  • g
    Yes. That's what I'm doing as well. Each page has (essentially) one SSE connection and UUID. Anything that changes on the server gets linked to the appropriate UUIDs. Lots of things can change on each page, but they're all segmented via EventNames (which are also a UUID)
  • f
    Mostly I generate the HTML on the backend from Python components.
  • f
    Yeah.
  • g
    Oops, sorry @User -- I switched you in my head with someone else.
  • f
    I'm thinking of making the SSE connection just be the concatenation of all the UUIDs that it issues updates for.
  • g
    I'd be happy to share code with you, but it's in Go, and I'm not sure it would translate well.
  • g
    Yes. I think that's the best way.
  • g
    In the real-time server I'm building, different content objects are all linked together. So, if one updates, I know to notify anyone subscribed to it, or its parents or grandparents.
  • g
    That calculation should be easy enough to do on the server.
  • f
    Makes sense.
  • f
    I've got a distributed data-flow thing going on in the back end.
  • f
    Because it's designed to pull information and UI fragments from a fleet of autonomous vehicles.
  • g
    Oh wow. That's a way cooler use-case than my chat app.
  • g
    Super jealous!
  • g
    Does all of the data flow in to a single place, though? I'd still expect a single cluster/db of machines collects the updates before it is sent back out to your browser clients.
  • f
    Not really.
1...767778...1146Latest