Add basic game types, logic and jest for testing

[bradtaniguchi]

We should start defining the game as how we think we will need it defined. So stuff like how we define the grid, basic game state (like we are alive/dead) how many mines/flags/etc. Because we are using typescript, refactoring this should be very easy.

We should also start defining some game logic, like the following functions (all these can be renamed, refactored, or not even done, its just a starting point):

• getGrid - returns the gridContent of the grid at the given coordinates
• getDirectNeighbors - returns a "block" of grid elements (gridBlock) relative to the give coordinates, creating a 3 by 3 grid. Should be an object/ type called "grid" or a tuple, whatever makes the most sense as a "block" of elements
• isBomb - returns if the girdContent or gridBlock is a bomb
• getBombsNear - returns the number of bombs in the given gridBlock, to show the numbers of 0-8

Obviously these are just spitball guesses at this point :wink: and I didn't include any state-management related logic as these we will need regardless.

[cmccormack]

I absolutely agree. I think starting with user stories may help us to then determine what functions we need, but having some empty functions with descriptive name to start should help get some code created.

[bradtaniguchi]

Idk what or how user stories works 🙃 so I'd need some help on that end haha

[bradtaniguchi]

So I was brain storming and ran into a question I have about how we will manage the state of the game. Namely the state management approach we will take with React.

I currently took the same approach with the state as I would with Redux/ngrx in that I saved changes made to the state to the store, and nothing more. As such I currently have a "game object" that looks like:

export interface Game {
  /**
   * The starting board
   */
  board: GridElementType[];

  /**
   * The list of moves made by the user
   */
  moves: Move[];
}

So essentially we would keep track of the starting board, and all the user's moves, but we wont keep track of what the current board looks like. Idk if this is a smart decision, as I think we would have to calculate the current board after every move by aggregating every move made by the user over the course of the game. This does have the cool effect where you can "undo" moves and "go back in time" by just removing moves from the array.😄

Obviously we could also keep track of the "currentBoard" state that is updated based upon the move as-well, but this will increase some complexity as the "real" board is created from the list of moves made, so this would more or less duplicate some logic and make "undoing" more complex.

We might be able to optimize the "aggregate" approach well enough the overall performance wont be an issue, or combine both approaches somehow. Or think of a totally different approach. Let me know what you guys think 😄