feat: implement room features via Socket.IO

[bxbdev]

Why need this change? / Root cause:

• Added events from socket
  • USER_JOINED
  • USER_READY
  • USER_NOT_READY
  • USER_LEFT
  • GAME_STARTED
  • GAME_ENDED
  • ROOM_CLOSED
  • HOST_CHANGED

Changes made:

Test Scope / Change impact:

Issue

• Feat: 其他使用者進入房間 - 1 #243 Feat: 看到其他使用者離開房間 - 1 #244 Feat: 其他使用準備/取消準備 - 1 #245 Feat: 房主關閉房間 #275 Feat: 其它使用者被踢除 #276 Feat: 更換房主 #277 Feat: 通知所有使用者遊戲開始 #279 Feat: 通知所有使用者遊戲關閉 #280

Note

(by Yuwen)

• 現在可於遊戲房間內，透過聊天室輸入 Enum SOCKET_EVENT 中定義的事件名稱來加入假資料並測試實作的狀況，
  例如，在聊天室輸入 USER_JOINED 字串，會讓房間新增一位使用者 (但如果再輸入一次會出錯就是了)，也可以輸入 KICK_ME 來模擬自己被踢之後的狀況 (此為唯一一個不在 Enum 的事件) 。
• 後續有計畫以 Jest 進行自動化測試。

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
game-lobby-web	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Aug 14, 2023 10:38am

[bxbdev]

@Yuwen-ctw 我是覺得 roomId 還是保持原本就好，不用需要特別改成 message.to ，這樣反而會看不懂這個 message.to 的用意。
然後原本 socket?. 的寫法，是因為我的 VS Code 會抱怨，是否能確認一下在 socket 運作之前，確保 socket 是找的到的？

[Yuwen-ctw]

Hello bxb,

先說明一個前提是，依現行主線的程式碼，透過聊天室發送訊息時，其型別已事先定義於 components/rooms/RoomChatroom/index.ts 裡面了，同時也是目前 miro 定義聊天訊息的格式，如下圖所示:

因此在前端透過聊天室發送訊息時，後端接到的資料 (socket.on 的第二個參數，pages/api/mock/socketio.ts Line 40)，其實就是 MessageType，因此再回傳給前端時，可以透過 message.to 取得 MessageType 中 to 的屬性。

所以，不確定你對於 message.to 的想法是針對 MessageType 中的 to 屬性的命名，還是針對 mock socket server 的使用方法呢?

假如是前者，那型別完全是可以進行調整的：
先前定義聊天訊息的型別（MessageType）時，針對接收訊息對象的 key 到底該如何命名我也思考了許久，之所以沒有選擇使用 roomId，是因為考慮未來聊天訊息可能不只發生在房間內，可能也包含大廳聊天室或者好友之間的私聊，在這個情況下，接收訊息的對象就不適合使用 roomId 這類明指遊戲房間的名稱，所以才使用 to 作為 MessageType中，描述接收訊息對象的 key。當時其實還有其他選擇，像是 chatRoomId 或 chatRoomName 等等，如果有更好的看法，完全可以進行調整！

那假如是後者，不確定你的意思是否是將現行的

case SOCKET_EVENT.USER_JOINED:
            socket.emit(SOCKET_EVENT.USER_JOINED, {
              user: {
                id: "mock_user_id",
                nickname: "mock_user",
              },
              roomId: message.to,
            });
            break;

改回第一個 commit 的這樣呢？

case SOCKET_EVENT.USER_JOINED:
            socket.emit(SOCKET_EVENT.USER_JOINED, {
              user: {
                id: "mock_user_id",
                nickname: "mock_user",
              },
              roomId: '0',
            });
            break;

這樣子寫的話，邏輯上的結果是，「不論發送的對象在哪個遊戲房間，mock socket server 接到訊息後都會嘗試往 roomId 為 0 的房間發送訊息」，假如未來我們將 mock socket server 的功能做得更齊全時，依然勢必要將 roomId 的 value 調整成變數，否則在開發模式下，如果不是去 0 號房進行測試，可能會沒有效果，這就是個人將原本 "0" 字串改成變數 (message.to) 的原因。

至於第二點 socket?.on 的議題，我有考慮到啦～我把這段程式碼往前放了，請參考下圖

依現行的調整應該不會讓你的 VSCode 抱怨的，假如有抱怨的話，可以再找個時間讓我診斷一下～

以上說明，感謝！

[bxbdev]

Hello bxb,

先說明一個前提是，依現行主線的程式碼，透過聊天室發送訊息時，其型別已事先定義於 components/rooms/RoomChatroom/index.ts 裡面了，如下圖所示: 因此在前端透過聊天室發送訊息時，後端接到的資料 (socket.on 的第二個參數，pages/api/mock/socketio.ts Line 40)，其實就是 MessageType，因此再回傳給前端時，可以透過 message.to 取得 MessageType 中 to 的屬性。

所以，不確定你對於 message.to 的想法是針對 MessageType 中的 to 屬性，還是針對 mock socket server 的使用方法呢?

假如是前者，那型別完全是可以進行調整的： 先前定義聊天訊息的型別（MessageType）時，針對接收訊息對象的 key 到底該如何命名我也思考了許久，之所以沒有選擇使用 roomId，是因為考慮未來聊天訊息可能不只發生在房間內，可能也包含大廳聊天室或者好友之間的私聊，在這個情況下，接收訊息的對象就不適合使用 roomId 這類明指遊戲房間的名稱，所以才使用 to 作為 MessageType中，描述接收訊息對象的 key。當時其實還有其他選擇，像是 chatRoomId 或 chatRoomName 等等，如果有更好的看法，完全可以進行調整！

那假如是後者，不確定你的意思是否是將現行的

case SOCKET_EVENT.USER_JOINED:
            socket.emit(SOCKET_EVENT.USER_JOINED, {
              user: {
                id: "mock_user_id",
                nickname: "mock_user",
              },
              roomId: message.to,
            });
            break;

改回第一個 commit 的這樣呢？

case SOCKET_EVENT.USER_JOINED:
            socket.emit(SOCKET_EVENT.USER_JOINED, {
              user: {
                id: "mock_user_id",
                nickname: "mock_user",
              },
              roomId: '0',
            });
            break;

這樣子寫的話，邏輯上的結果是，「不論發送的對象在哪個遊戲房間，mock socket server 接到訊息後都會嘗試往 roomId 為 0 的房間發送訊息」，假如未來我們將 mock socket server 的功能做得更齊全時，依然勢必要將 roomId 的 value 調整成變數，否則在開發模式下，如果不是去 0 號房進行測試，可能會沒有效果，這就是個人將原本 "0" 字串改成變數 (message.to) 的原因。

至於第二點 socket?.on 的議題，我有考慮到啦～我把這段程式碼往前放了，請參考下圖 依現行的調整應該不會讓你的 VSCode 抱怨的，假如有抱怨的話，可以再找個時間讓我診斷一下～

以上說明，感謝！

Hi Yuwen,
哦！那個是 mock api 的，沒事！我以為是前端送給後端的資料型態，這樣我沒有什麼問題了。
我本來以為是送資料給 backend，想說backend不需要特別註明 message.to，只需要一個 roomId 就好。
上面的調整內容，我沒有任何問題了。

謝謝你的回答。

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
0.0% Duplication

[GaaSBot]

✅ Knip Scan Result for 493eec2

Unused files (10)

Unused files (10)
.bundlewatch.config.js
components/shared/Chat/ChatContent.tsx
components/shared/Chat/ChatMessage.tsx
components/shared/Chat/index.tsx
components/shared/Icon/group/news.tsx
configs/i18nConfigs.ts
lighthouserc.js
reset.d.ts
scripts/knipScanReporter.js
scripts/lhciScanReporter.js

Unused dependencies (2)

Unused dependencies (2)
@svgr/webpack package.json
sharp package.json

Unused devDependencies (5)

Unused devDependencies (5)
@actions/github package.json
@octokit/core package.json
@storybook/blocks package.json
@storybook/testing-library package.json
@total-typescript/ts-reset package.json

Configuration issues (1)

Configuration issues (1)
Unused item in ignoreDependencies: @next/bundle-analyzer

[GaaSBot]

🤖 Lighthouse Scan Result for 493eec2

/rooms

Metric	Value
Performance	72
Seo	80
Accessibility	79
HTML Report for LHCI Scan	Report Link

/rooms/abc

Metric	Value
Performance	76
Seo	80
Accessibility	69
HTML Report for LHCI Scan	Report Link

/login

Metric	Value
Performance	50
Seo	80
Accessibility	97
HTML Report for LHCI Scan	Report Link