How I built a web-based Sudoku app

Recently I finished writing a series of posts about how I built a chess board with React. The chess board handles very little user interactions because it was meant to be a playground for me to experiment with some CSS3 and HTML5 features. Later on, as I incorporated a couple of more modern features in React (the Context API and the React MUI component library), I started to think about working on a new project where I get to play with more advanced React stuffs.

And I ended up building a web-based Sudoku.

You can start to challenge yourself against my Sudoku puzzles at https://sean-sudoku.netlify.app/. The code is currently hosted on GitHub at https://github.com/seanluong/sudoku.

There are a few interesting challenges that I had to solve in order to complete the app both in the frontend and in the backend.

Building the frontend

Using React MUI

I built all the UI using React MUI components. With the chess board I relied mostly on Stack-based layout so this time I used a Grid-based layout for the Sudoku board. I also worked with a few other components that I didn’t used for the chess board, namely FAB, Button Group, and Text Field. Overall I didn’t have much to complain about the quality of the component library as most of what I needed was very well documented.

One lesson that I learned from this project is that I’m not very sure of what the benefits Grid offer over Stack? Under the hood Grid component in the React MUI library is implemented using CSS flex box model, which is also the basis of Stack. If one really wants to take advantage of CSS grid layout, they will have to tap in to the power of MUI system.

MUI System is a collection of CSS utilities for rapidly laying out custom designs with MUI component libraries.

Managing the state

I used 2 things to manage the app’s state: Redux and Context API.

At the start I just used Redux for everything. The reason was because it had been a while since the last time I worked with Redux so I wanted to refresh my knowledge. Quite a few things have changed and it’s nice to see that the library has been going through some improvements over time.

The first great thing that I noticed in modern Redux is the ability to create slices of the state and to split the root reducer into sub-reducers. This new approach makes it much easier to manage the ever growing state transition logic and it was not available the last time I worked with Redux. Unfortunately the official Redux documentation looks like it’s still in the migration process because most of the examples / tutorials on the Redux website still have the code in the older approach. Fortunately there’s a dedicated documentation page for people who want to use the modern approach.

Another great thing that has to be mentioned are the hooks provided by the react-redux library, in particular useDispatch and useSelector . I think it’s fair to say that any innovation made to the React ecosystem is not complete until it comes bundled with its own hooks!

As much as I enjoyed working with modern Redux, I couldn’t help but wondering if this would still be the way to go in the React ecosystem when it comes to state management? Recently there seems to emerge a new trend where people get away from Redux and its baggages by taking advantage of React’s Context API and a few hooks that are already included in the React library. There’s a great blog post about this topic here.

For this project I only used the Context API to manage the state of whether users should be shown the errors that currently exist in their solution of the Sudoku puzzle. In future project I will probably experiment with using Context API in place of Redux for state management.

Building the backend

At the beginning I didn’t envision having a backend part for this project. As I worked on how to generate a Sudoku puzzle, I decided that I wouldn’t be writing the puzzle generation code myself. While I was fairly confident that given a sufficient amount of time I should be able to come up with some algorithm to generate puzzles and even read up on previous research on how to generate puzzles at different difficulty levels, I didn’t feel like going down that path would maximize my learning experience from the project as far as building a web app was concerned. I thought that it would be more fun if I could find an API endpoint where I could make a request to get a puzzle and get back one in the response.

In the end, what I did was to scrap Sudoku puzzles generated by a different app. All of that was done in a serverless backend script that is currently hosted as a Netlify function. It was quite a ride and definitely a very gainful experience. I’ll talk about it in my next post.