Readit NewsThere was a cambrian explosion of tools to customize the look and feel. TweakXP pro is the one I remember. All pirated off-course.
This does not have the benefit of being usable across different tabs or even closing and re-opening the page. Besides, (a minor point) shoving all the state in the cookie makes code simple i.e. don't have use URL params.
You might need async if there are lot of concurrent users and each of them using long duration SSE. However, this is not DS specific.
So, when /upload is requested, the backend in response sets a cookie with a random uploadId (+ TTL). At the backend, we tie sessionId and uploadId.
With every step which is called, we verify sessionId and uploadId along with additional state which is stored.
This means even if the form is opened on a different tab, it will work well.
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?
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
I think it is best seen in examples on DS website.
Why not use cookies?
In datastar the "Out Of Band" updates is a first class notion.
A sample of bad ringtone (auto-tuned baby crying) which was trending back then (2007-2008) was [1]. Thankfully I never used it.
[1] https://www.youtube.com/watch?v=SVvFRzMWdL8