| ▲ | devnull3 3 days ago |
| This should be trivial with the HTMX alternative: datastar [1] In datastar the "Out Of Band" updates is a first class notion. [1] https://data-star.dev |
|
| ▲ | spiffytech 2 days ago | parent | next [-] |
| Unrelated: datastar doesn't use a two-way connection for interaction <-> updates. It uses two unconnected one-way channels: a long-lived long-lived SSE for updates, and new HTTP requests for interaction. I didn't see guidance in the docs for routing one tab's interaction events to the backend process managing that tab's SSE. What's the recommend practice? A global, cross-server event bus? Sticky sessions with no multiprocessing, and an in-process event bus? If a user opened the same page in two tabs, how should a datastar backend know which tab's SSE to tie an interaction event to? |
| |
| ▲ | chuckadams 2 days ago | parent | next [-] | | It appears to be a SSE channel for each event stream returned, not one channel for all subsequent updates. So a PHP backend for instance could batch all the updates from one request, would open a new SSE channel, send the updates over that, then close it. With an in-process server like swoole or most things not PHP, you could presumably reuse the channel across requests in whatever framework-specific way makes that happen. Would probably need sticky sessions in any scaled-out deployment. This is just what I can glean from the docs, I've never actually used datastar myself. | |
| ▲ | devnull3 2 days ago | parent | prev [-] | | With DS (and HTMX) the backend is the source of truth. In the context of the blog post, the state will be made-up of: step no, file content, file path, etc. This can be stored against the session ID in a database. So when opened on a different tab, the backend would do authentication and render the page depending on the store state. In general, the backend must always compare the incoming state/request with stored state. E.g the current step is step 2 but the client can forces it to go to step 4 by manipulating the URL. DS v1.0 now supports non-SSE (i.e. simple request/response interaction as well) [1]. This is done by setting appropriate content-type header. [1] https://data-star.dev/reference/actions#response-handling |
|
|
| ▲ | meander_water 3 days ago | parent | prev | next [-] |
| HTMX has out of band updates too [0], what's the differentiator? [0] https://htmx.org/attributes/hx-swap-oob/ |
| |
| ▲ | devnull3 3 days ago | parent [-] | | In DS, with SSE you can paint different parts of the page with ease. So in this case, it can update <form> and <label> separately. So instead of one update the backend fires 2. There is not separate marker or indicator for OOB. I think it is best seen in examples on DS website. | | |
|
|
| ▲ | sgt 2 days ago | parent | prev [-] |
| Doesn't datastar require an async backend? I prefer Django without async. |
| |
