Interlude: Tic Tac Toe

At this point if you have been reading sequentially through these chapters you know enough to put together a simple tic-tac-toe game.
The Game Board
The board is represented by an array of 9 cells. Cell 0 is the top left square, and cell 8 is the bottom right.
Each cell will contain nil, an :X or an :O.
Displaying the Board
The DisplayBoard component displays a board. DisplayBoard accepts a board param, and will fire back a clicked_at event when the user clicks one of the squares.
A small helper function draw_squares draws an individual square which is displayed as a BUTTON. A click handler is attached which will fire the clicked_at event with the appropriate cell id.
Notice that DisplayBoard has no internal state of its own. That is handled by the DisplayGame component.
class DisplayBoard < HyperComponent
  param :board
  fires :clicked_at
​
  def draw_square(id)
    BUTTON(class: :square, id: id) { board[id] }
    .on(:click) { clicked_at!(id) }
  end
​
  render(DIV) do
    (0..6).step(3) do |row|
      DIV(class: :board_row) do
        (row..row + 2).each { |id| draw_square(id) }
      end
    end
  end
end
The Game State
The DisplayGame component has two state variables:
@history which is an array of boards, each board being the array of cells.
@step which is the current step in the history (we begin at zero)
@step and @history allows the player to move backwards or forwards and replay parts of the game.
These are initialized in the before_mount callback. Because Ruby will adjust the array size as needed and return nil if an array value is not initialized, we can simply initialize the board to an empty array.
There are three reader methods that read the state:
player returns the current player's token.  The first player is always :X so even steps
are :X, and odd steps are :O.
current returns the board at the current step.
history uses state_reader to encapsulate the history state.
Encapsulated access to state in reader methods like this is not necessary but is good practice
class DisplayGame < HyperComponent
  before_mount do
    @history = [[]]
    @step = 0
  end
​
  def player
    @step.even? ? :X : :O
  end
​
  def current
    @history[@step]
  end
​
  state_reader :history
end
Calculating the Winner Based on the Game State
We also have a current_winner? method that will return the winning player or nil based on the value of the current board:
class DisplayGame < HyperComponent
  WINNING_COMBOS = [
    [0, 1, 2],
    [3, 4, 5],
    [6, 7, 8],
    [0, 3, 6],
    [1, 4, 7],
    [2, 5, 8],
    [0, 4, 8],
    [2, 4, 6]
  ]
​
  def current_winner?
    WINNING_COMBOS.each do |a, b, c|
      return current[a] if current[a] && current[a] == current[b] && current[a] == current[c]
    end
    false
  end
end
Mutating the Game State
There are two mutator methods that change state:
handle_click! is called with the id of the square when a user clicks on a square.
jump_to! moves the user back and forth through the history.
The handle_click! mutator first checks to make sure that no one has already won at the current step, and that no one has played in the cell that the user clicked on. If either of these conditions is true handle_click! returns, no mutation is signaled and nothing changes.
If we had wanted to return AND signal a state mutation we would use the Ruby next keyword instead of return.s
To update the board handle_click! duplicates the squares; adds the player's token to the cell; makes a new history with the new squares on the end, and finally updates the value of @step.
We like to use the convention where practical of ending mutator methods with a bang (!) so that readers of the code are aware that these will change state.
class DisplayGame < HyperComponent
  mutator :handle_click! do |id|
    board = history[@step]
    return if current_winner? || board[id]
​
    board = board.dup
    board[id] = player
    @history = history[0..@step] + [board]
    @step += 1
  end
​
  mutator(:jump_to!) { |step| @step = step }
end
The Game Display
Now we have a couple of helper methods to build parts of the game display.
moves creates the list items that allow the user to move back and forth through the history.
status provides the play state
class DisplayGame < HyperComponent
  def moves
    return unless history.length > 1
​
    history.length.times do |move|
      LI(key: move) { move.zero? ? "Go to game start" : "Go to move ##{move}" }
        .on(:click) { jump_to!(move) }
    end
  end
​
  def status
    if (winner = current_winner?)
      "Winner: #{winner}"
    else
      "Next player: #{player}"
    end
  end
end
And finally our render method which displays the Board and the game info:
class DisplayGame < HyperComponent
  render(DIV, class: :game) do
    DIV(class: :game_board) do
      DisplayBoard(board: current)
      .on(:clicked_at, &method(:handle_click!))
    end
    DIV(class: :game_info) do
      DIV { status }
      OL { moves }
    end
  end
end
&method turns an instance method into a Proc rather than having to say { |id| handle_click(id) }
Summary
This small game uses everything covered in the previous sections: HTML Tags, Component Classes, Params, Events and Callbacks, and State. The project was derived from this React tutorial: https://reactjs.org/tutorial/tutorial.html. You may want to compare our Ruby code with the React original.
The following sections cover reference materials, and some advanced information. You may want to skip to the HyperState section which will use this example to show how state can be encapsulated, extracted and shared resulting in easier to understand and maintain code.
Events and Callbacks
Recovering from Errors
Last modified 2yr ago