moving websocket into being managed by the room component.
if the partent would want access to "user signal" it can ask via
observer.
that would mean bidirectionality, and i already hear screeching of my
intuitions from react, but maybe that's ok and in react i would still
scope the websocket to the room page, plus callbacks
getting stubbed session #1,
with auth module stubbed to accept that session in.
and stubbed method for streaming room state,
but that's enough to start testing room calling api's for other actions
next - pass in observable from parent to re-toggle subscription
websocket after successful login
without it app starts in same jvm and we're told that Ctrl+C will not
always kill the Ember server:
https://typelevel.org/cats-effect/docs/2.x/datatypes/ioapp
WARNING: If you run your IOApp program from sbt, you may observe cancellation and resource releasing is not happening. This is due to sbt, by default, running programs in the same JVM as sbt, so when your program is canceled sbt avoids stopping its own JVM. To properly allow cancellation, ensure your progam is forked into its own JVM via a setting like fork := true in your sbt configuration.
efim