Updating the chessmate app
Chessmate is a very simple app that includes both backend and frontend implementations, where the backend is represented by two models, one representing the chess game either newly created by the user or one that already exists; and the second model represents the various pieces that a regular chess game composed of.
The two models are related through a has-many relationship, where each game has many pieces. Every new game gets created by the default game that sits on top of the game table along with its 32 pieces representing the black and white sets<sixteen pieces for each set>. The piece model has (among others ) position attribute, which in the case of our default game; has its value set to the starting position of that particular piece. This way the default game which will always have the id of one in the games table will act as a reference to every new game created by users. Every new game will have its own id and other attributes of course. But that new game’s pieces will be cloned of off the default game’s pieces and then saved to the database in one shot, that way we minimize the traffic between the back and front ends.
Only the necessary actions are implemented in the games_controller and pieces_controller along with their respective routes in the routs.rb file, this way we kind of minimized the security risks that other unnecessary routes may expose.
The API for the game is very simple (no fast json was used to avoid any added complexities). Just a game object that has some attributes among which the pieces’ key which has the game’s pieces in an array as its value.
The resources in the route.rb is nested to reflect the models’ relationship, this also comes in handy when we want to update the position of any piece during the normal gameplay, we’ll have both the game id and the game id and the piece’s id its position need to be updated in our URI all done in one fetch request.
In the frontend, both of our models are represented by their javascript class counterparts named conveniently game.js and piece.js. Each with its own related functionality implemented as a class or instance method. In addition, we have a Menu class which for now has only one utility class method called show which accepts one argument as a javascript rest argument is composed of strings pointing to the various game menus that need to be shown depending on where we at in our application.
The game starts with two typical options; either starting a new game or retrieving an unfinished game that was saved for later. Either way that will trigger the chessboard to be rendered and then the pieces on top of it in their respective positions depending on whether it is a new game or saved game.
The main chessboard is laid out using CSS grid layout which is a great match and use case for board games applications. The board grid also includes four extra rows, two on top of the board that will hold the white pieces captured by the black opponent, and the other two rows are positioned at the bottom of the board to hold the black captives captured by the white opponent.
Not only the CSS grid implementation make the board layout super easy. But it also has two other advantages in this particular application.
First, it made moving the pieces around super easy, achieved by simply changing the grid-area property of the element containing the piece in question to the new position which is represented by the two alphanumeric characters. Or three characters in the case of the captive piece which causes its position string to be prepended with an ‘x’ as shown in the image above.
The second major advantage is the ability to lay more than one element on top of each other simply by having them share the same grid area value, following the principle that the element assigned the grid area value last will be on top of those that got their values set earlier. That was a game-changer, not only we don’t have to worry about the z-index of any given chess piece with respect to its containing square and let the CSS grid layout mechanism deal with it, but it made controlling and sliding the pieces around in javascript much easier, concise, and more importantly; it made the code more readable.
And by having the position attribute of each piece in our backend model exactly matches that piece’s grid-area value (the same two or three alphanumeric characters) in the frontend, we simply created that invisible bond or link between the two objects.
