removed stubbed room, but thing compiles and maybe will work?
lot's of pain with trying to store Topic inside Ref together with Room.
storing them together in a tuple means for the room there should always
be a topic
but then modifying the room in side of ref is uncomfortable, because i
want to do F[Unit] send updated room together with room modification,
but Ref seems to take in only pure function to update the value
there got to be maybe some semaphors or something like that?
and storing topics where? in a separate state?
that would maybe simplify things, but i'm coding well into the night and
that's not a good idea really
now before testing this with front end, i need a way to create a room.
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