The way we manage the Socket.io connection in the frontend can be improved.
Rationale
Currently, files import socket from src/socket.ts. I personally do not like this approach, as the socket connection is not always available as it is only established once a player joins a game, and thus a global export accessible to all components seems inappropriate.
Additionally NicknamePage currently establishes the actual connection to Socket.io. This seems quite smelly for a number of reasons. While we do want the connection to be established when the user joins through NicknamePage, we don't want to redirect them to NicknamePage in other circumstances, such as if they refresh their page after already connecting. This is the current behaviour as described in (#121) which is intentional until #101 is completed. However, we should look to refactor this now to initialise the connection in a place better than NicknamePage in preparation for #101's completion.
Proposed Changes
[x] Socket context
This will allow us to delete src/socket.ts and instead initialise the socket inside GameRouter.
GameRouter can pass its socket object to a SocketProvider, which pages that require the socket object to listen to or emit events can access through a useSocket() hook.
See #137
[x] Establish connection inside GameRouter
Relocate the connection logic from NicknamePage to GameRouter. This change will enable the user to bypass NicknamePage if they have previously connected and refresh the page once #101 is completed.
One thing to note with these changes is locating additional code within GameRouter. I believe after this issue is completed alongside #131 that GameRouter will be due for a refactor of its own. At this stage I am unsure of what form that will take, but will document the rational and proposal for changes in a seperate issue once I get a clearer picture.
The way we manage the Socket.io connection in the frontend can be improved.
Rationale
Currently, files import
socketfromsrc/socket.ts. I personally do not like this approach, as the socket connection is not always available as it is only established once a player joins a game, and thus a global export accessible to all components seems inappropriate.Additionally
NicknamePagecurrently establishes the actual connection toSocket.io. This seems quite smelly for a number of reasons. While we do want the connection to be established when the user joins throughNicknamePage, we don't want to redirect them toNicknamePagein other circumstances, such as if they refresh their page after already connecting. This is the current behaviour as described in (#121) which is intentional until #101 is completed. However, we should look to refactor this now to initialise the connection in a place better thanNicknamePagein preparation for #101's completion.Proposed Changes
src/socket.tsand instead initialise thesocketinsideGameRouter.GameRoutercan pass itssocketobject to aSocketProvider, which pages that require thesocketobject to listen to or emit events can access through auseSocket()hook.GameRouterNicknamePagetoGameRouter. This change will enable the user to bypassNicknamePageif they have previously connected and refresh the page once #101 is completed.One thing to note with these changes is locating additional code within
GameRouter. I believe after this issue is completed alongside #131 thatGameRouterwill be due for a refactor of its own. At this stage I am unsure of what form that will take, but will document the rational and proposal for changes in a seperate issue once I get a clearer picture.