Modern Full-Stack Development

 Back  to the Code!
Now, getting back to the code in state.ts, we have more properties to declare on the 
state object:
selectedTiles : [ ]
This property, which uses the interface defined earlier as its type (again using type 
casting), is where the selected tiles are stored.
Chapter 11   time for fun: BattleJong, the Client

---

333
Next, we have a property to hold our scores:
scores : { player : 0, opponent : 0 }
After that, we have a key property to making everything work, one that tells us what 
“state” the game is in:
gameState : "awaitingOpponent"
The game can be in one of five states at a given moment: “awaitingOpponent” (when 
you are the first player to connect to the server and are waiting for another to connect), 
“playing” (when the game is being played, obviously!), “deadEnd” (when your board 
has dead-ended), “cleared” (when you have cleared your board), and “gameOver” 
(when both players have either cleared or dead-ended the board and a winner has been 
determined). This gameState value changes as various events occur and is primarily 
what is used to show the appropriate message in the control area.
The next property is needed when the game has ended:
gameOutcome : ""
This value will be set when the server tells the client which player won.
Speaking of players, each has a unique ID, as you saw in the last chapter, and we 
need to store that in state:
pid : ""
The next property is our socketComm object:
socketComm : createSocketComm(inParentComponent)
Note that the type is Function because that’s effectively what gets return by the call 
to createSocketComm().
Finally, we need to keep track of how long it takes the player to clear a tile or, more 
precisely, how long it’s been since their last match:
timeSinceLastMatch : 0
Those properties represent all the state (plus the odd socketComm instance, which 
isn’t state, per se) needed to make BattleJong work.
Chapter 11   time for fun: BattleJong, the Client

---

334