Pet project: chessboard UI – Day 3

Today was a really poor day for the user of our chessboard (no new feature!). BUT I’m quite satisfied with the progress made on the app structure and the development experience. Almost everything I mentioned yesterday has been implemented.

Redux and ducks

I started the day by setting up Redux. I decided to do this early because…

  • it is much more convenient to hold the state of the application in one single store.
  • it will be more convenient to handle user actions.
  • it will allow time-travel between moves (something that chess.js doesn’t support).
  • it allows me to conveniently test the app logic (by dispatching actions and comparing the expected state to the actual state.

To do so I installed the following libraries: redux, react-redux, immutable, redux-immutable, reselect, redux-devtools-extension. Then I refactored the currently very simple codebase to match the ‘ducks’ organisation, which I previously used on the ChineseMe project and found very convenient when scaling up.

Screen Shot 2018-08-24 at 16.23.54
Up and running with Redux and Redux Devtools

Improved Game State

Instead of saving the full FEN string in the store, I decided to cut it into it’s six distinct parts. This will make it easier later to update the game situation based on user actions:

Screen Shot 2018-08-24 at 15.36.41

I use Reselect to recreate the full FEN string based on those six elements:

Screen Shot 2018-08-24 at 16.29.42

Testing the app logic

With this first ‘duck’ in place I can now develop the logic following a TDD approach. With Redux, the idea is quite simple: the only thing that can happen is user actions resulting in redux actions, which are handled by reducers, which update the state in the storeThe UI then displays components by querying the store’s state via selectors.

Image result for redux action reducer store selector image
Diagram taken from this article


This means that we can test that every part of the flow works as expected by creating tests that:

  1. Generate an action using an action creator
  2. Calculate the next state by passing the action to the reducer
  3. Get the next state via the appropriate selector
  4. Compare the next state to the expected state

With that in mind I wrote a failing test for a future ‘MOVE’ action:

Screen Shot 2018-08-24 at 15.38.20
A useful pattern to test the logic of a redux app

As expected the test is currently failing since the position is not yet updated. I’ll handle the logic of the ‘MOVE’ action tomorrow:

Screen Shot 2018-08-24 at 15.38.36.png
As expected, it’s a fail! So far so good.

Useful util functions

When handling user actions it will be more convenient to work at the square level. If we represent the board by an array of 64 strings, it’s easy to understand what ‘moving a piece’ means: moving elements within the array.

However as far of the app state is concern, it’s much more convenient to keep track of the position as a string. And it would be more convenient if a server was added to this project (a simple string is easier to save in a database than a JS array.

With that in mind I developed two useful util functions:

  • positionToArrayOfPieces
  • arrayOfPiecesToPosition

I followed a TDD approach to facilitate the development of those functions:

Screen Shot 2018-08-24 at 10.47.28



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s