I see. Now I think it is out of Drab scope, but we might build something like in a future, as it may be useful, especially for beginners!
Also, what I am still thinking of, and may be connected with your idea, is to build some abstraction (session) over the socket, which would be used to survive disconnections. So the handlers, instead of socket, would get some session (browser or even user) id, and if you run the background process (not linked to the handler) you may proceed even in case of the disconnection in the meantime.
You may do something like this now, just broadcasting to the topic, but it is one-way communication only - trying to read from the browser on disconnected socket returns {:error, :disconnected} and you must deal with it yourself.
It may also store the messages sent during disconnection, so after reconnect browser will run all remaining code.
Also, we could provide a âwaiting for reconnectâ API, like:
defhandler handle_event(session, _payload) do
spawn fn ->
do_some_long_process()
x = query_one(session, "#input1", :value) do
on {:ok, x} -> x
after 50000 -> raise "gone forever"
end
end
end
But, as I said, it is rather a future stuff.
Yep, it was added after you persuaded me to do it 