Possible race condition in playCtrl

[veloce]

this.round and this.gameSocket are initialised at null and an asynchronous xhr populates them. But the view depends on those objects.

They should be created before and be playCtrl parameters to avoid problems.

It doesn't respect the "model must always be valid" principle.

[veloce]

Maybe instead of creating a new instance of StrongSocket for each game we should keep a global one and pass it to each game controller.

[ornicar]

But sockets are created for a URL that contains the game ID?

[veloce]

We could add the id param to StrongSocket.reset since we already reset version.
So we'd create 2 instances of StrongSocket one for game, one for lobby, on app init.

What do you think?

Also playCtrl should be removed completely as there's nothing left here... all should be done in round

[ornicar]

I don't think you can reuse a socket connection for distinct games. A round socket is bound to one game, defined by the round socket URL.

[ornicar]

nevermind, there's a confusion between instances of StrongSocket and actual browser WS connection.

[ornicar]

Yes reset could have an URL aargument additionally to version, to allow reuse of the StrongSocket instance while changing the underlying connection

[veloce]

Yep that's what I meant. I think this is a fair approach to the problem mentioned above. And maybe it'll solve other issues...