Learn how to build a grid with CSS Grid and manage complex state with useReducer while building a Tic Tac Toe Game.

Kyle Shevlin

Manage Complex Tic Tac Toe Game State in React

Learn how to implement data structures, sorting algorithms, and the trade-offs between what algorithms to choose.

Data Structures and Algorithms in JavaScript

Managing state is one of the primary reasons our applications become so complex. See how to simplify state with state machines.

Introduction to State Machines Using XState

Functional Programming can be overwhelming to learn with all the new jargon and concepts. Learn this style without all the headaches.

Just Enough Functional Programming in JavaScript

Kyle Shevlin Landing Page

 Courses from Kyle Shevlin

JavaScript® (often shortened to JS) is a lightweight, interpreted, object-oriented language with first-class functions, most known as the scripting language for Web pages, but used in many non-browser environments as well such as node.js or Apache CouchDB. It is a prototype-based, multi-paradigm scripting language that is dynamic, and supports object-oriented, imperative, and functional programming styles.

javascript

We should add some final touches to our tic-tac-toe game. We want to make sure that after a user has won, that it's impossible for them to put the game into a broken state. We can do that by adding a guard to our `reducer`.

It would also be nice if the board automatically reset in the result of a draw. We can add a `checkForDraw` function that algorithmically determines if the game is drawn or not and automatically reset the `grid` data.

Prevent Impossible States and Check for Draw Conditions with Guard Statements in React

Tic-tac-toe, like many grid-based games, relies upon a 2-dimensional array data structure to hold the state of our `grid`.

A `grid` is a matrix. The outer array contains all the `rows`, and each row is an array of `columns`. Often each column value is referred to as a `cell`. In tic-tac-toe, we create a 3x3 grid of `null` values that will be replaced with `X`s and `O`s as the user interacts with the game.

Create a 2-Dimensional Grid for our Tic-Tac-Toe Game

React is one of the web’s most popular frameworks for building JavaScript applications. 

If you know what you’re doing, React can drastically simplify how you build, use, and maintain code.

Whether you’re a React newbie or you’re ready for advanced techniques, you can level-up with egghead. Explore our in-depth courses, lessons, and community resources to build more powerful applications and crack open your career.

react

Our tic-tac-toe board works and can be played, but it can't be reset once the game is won or the board is full. Adding this is simple. We'll add another case to our `reducer` and use a function to regenerate the `initialState` of our game.

Reset React State with a Button and Function in our Tic-Tac-Toe Game

In order to update our UI when a user interacts with the buttons, we need to store and update the tic-tac-toe `grid` data somehow. We're going to use the `React.useReducer` hook to accomplish this.

With this hook, we are able to store some data (including our grid) and define `actions` that update that data. We'll work on adding a `CLICK` case to our `reducer` that will update the `grid` with either an `X` or an `O` according to whose `turn` it is.

Handle User Input by Adding State to the Tic-Tac-Toe Grid with React useReducer

A game a user can't interact with is hardly a game at all. We'll go through the process of turning our `Cell` components into accessible buttons and moving the click handling function up to our `Game` component where our state will eventually be handled.

Convert a 3x3 Tic-Tac-Toe Grid Interactive by Adding Buttons in React

Cascading Style Sheets bring order and beauty to our applications.

Our tic-tac-toe UI has to display our `grid` data. Using CSS Grid to do so is :chefs_kiss:. We'll create `Grid` and `Cell` components to handle our data. The `Grid` component will map our `rows` and `columns` and use the CSS Grid layout engine to correctly place them. We'll make our grid generically handle any amount of rows and columns we would throw at it. We'll use a simple trick with the `grid-gap` property to easily create the crossing lines of a tic-tac-toe game.

Map Over a 2-Dimensional Array to Create a Game Grid in React with CSS Grid

At this point, our game is fully usable. Users can add `X`s and `O`s and can see for themselves who has won or not. However, this is a computer game now and it should be programmed to determine who the winner is algorithmically.

Breaking down the problem of tic-tac-toe, one will realize that there are only 8 winning conditions in the game. We can create a handful of functions that will `checkForWin` when a square is clicked. Once we have determined the winner, we can update the UI to announce that to the users.

Check for Winning Conditions in React useReducer for Tic-Tac-Toe

Conditional logic can be very cumbersome and difficult to read. A single `if/else` block might be simple enough, but nesting several of them can lead to very complicated logic and difficult to read code.

Often, we can easily eliminate half of the branching through the use of guard statements and early returns. This lesson will take a function with a few nested `if/else` blocks and refactor it to remove all of the `else`s. The result will be simpler and, in my opinion, easier to read.

Remove Unnecessary `Else` Blocks with Guards and Early Returns

Attempting to render an object in a React component results in an error. Objects are not valid React elements, however, strings are. If we transform an object using `JSON.stringify()` into a string, we can render it just as we would any other string.

We can encapsulate this concern in a React component. We can then use this component in a React app wherever we might like to display an object on the screen. This is very useful for debugging purposes when `console.log` or a `debugger` are not your best options.

Render an Object with JSON.stringify in React

Statecharts are a formalism for modeling stateful, reactive systems. This is useful for declaratively describing the behavior of your application, from the individual components to the overall application logic.

xstate

Actions are "fire-and-forget" side effects that are triggered by transitions. We set functions on a transition object's `actions` property to have them called when a transition is taken.

```javascript
//...
EVENT_NAME: {
  target: 'name-of-state-to-transition-to',
  actions: [(context, event) => { sideEffectToFire(context, event) }]
}
//...
```

Add Actions to Transitions to Fire Side Effects

Actions aren't limited to being called on transitions. They can also be called when we enter or exit a state node. This is done through the `entry` and `exit` properties.

The API for `entry` and `exit` actions is the same as that for `actions` on transitions. It can receive a single function or an array of functions, each which will be called with the next `context` and the `event` object that caused the transition.

This is a powerful way to fire side effects based on states rather than transitions.

```javascript
//...
states: {
  broken: {
    entry: [
      (context, event) => {
        sideEffectToFireWhenWeEnterTheBrokenState(context, event)
      }
    ],
    exit: [
      (context, event) => {
        sideEffectToFireWhenWeExitTheBrokenState(context, event)
      }
    ]
  }
}
```

Trigger Actions When Entering and Exiting a XState State

As our state machines grow more complex, we might find ourselves in a situation where a state should only exist if the machine is already in another state. To do this, we can use hierarchical states.

Instead of attempting to define all the states of a machine at a top level, we can nest states that should only be available as children of a parent state. These substates are written _exactly_ like the states of the top level of a machine: with an `initial` property, and the `states` of the nested state graph.

Using hierarchical states is a great way to avoid needing to check for booleans in an application. If a state can only exist when another state exists, consider if the one isn't in fact a child of the other.

Simplify State Explosion in XState through Hierarchical States

Generally speaking, state machines do not and should not have a sense of _time_. They are intended to be pure functions that receive a state and event and return the next state. Pure functions by design have no sense of _history_.

Yet, it is occasionally useful to return to a previous state. How is this accomplished? With history state nodes. Each state object returned by XState contains a special property that points to the previous state. When a history state node is defined and is the target of a transition, the machine returns to this previously stored state.

We can create a history node by defining the `type` as `history`, and setting the `history` property to either `shallow` (the default) or `deep`.

Recall Previous States with XState History States Nodes

Unbeknownst to many, promises are state machines. They exist in either an `idle`, `pending`, `resolved` or `rejected` state. Because they can be modeled as state machines, we can invoke them when we enter a state in a `Machine`.

We invoke services such as a promise by using the `invoke` property on a state node. When the state is entered, the `src` of the `invoke` object is called. In the case of promises, the `Promise` is called. When the `Promise` resolves, the `onDone` transition is taken. When the `Promise` rejects, the `onError` transition is taken. In either case, the data returned from the promise, whether resolved or errored, is passed back on the event object as `event.data`.

Invoking a Promise for Asynchronous State Transitions in XState

We can invoke a callback as a service when we enter a state in XState. This gives us the ability to trigger various functionality by responding to events sent to the service, and allows us to send events _back_ to the parent machine.

We do this by writing a "callback handler" and setting it as the `src` of our invoked service. A callback handler is a function that receives the current `context` and the `event` object that triggered the invocation. This function returns another function that receives two functions as arguments. A `callback` function to send events to the parent machine, and an `onEvent` function for the handler to respond to events sent to the handler.

The way events are sent to the callback handler is by utilizing the `options` argument of the `send` action creator. We identify where we send events to using the `to` property, and setting the value to the `id` of our service.

Invoke Callbacks to Send and Receive Events from a Parent XState Machine

Trying to structure the state logic of an application as a single machine can begin to become unwieldy when we have too many states. It is often better to divide our app into smaller machines and invoke those machines as necessary.

When we enter a state in a machine, we can invoke a child machine. This machine can send and receive events from the parent. When the child machine reaches a final state, the `onDone` transition is taken by the parent's current state node.

To invoke a child machine, we use the `invoke` property and set the `src` property to a machine. We can forward events in the parent machine to the child machine by setting the property `autoForwards` to `true`. We can also send events to the child machine through setting the second argument of the `send()` function to `{ to: 'child-machine-id' }`.

The child machine can send events to the parent machine by using the `sendParent` function. In this way, parent and child machines can communicate.

Invoke Child XState Machines from a Parent Machine

Enumerating the possible states of a function is a sound way to write a function, but it is imperative and could benefit from abstraction. We can do this with a state machine.

A state machine formalizes how we enumerate states and transitions. For the sake of clarity and to emphasize the core concepts, I will be overly verbose with my code in this lesson.

In this lesson, we'll replace the state enum with individual state objects. We'll also replace our events `toggle()` and `break()` with events `TOGGLE` and `BREAK`. I'll also demonstrate the usefulness of the Machine's `initialState` getter and the `transition` method. Lastly, I'll show what happens when we pass erroneous states or events into our machine.

Replace Enumerated States with a State Machine

XState provides the `send` function to create an action that will send the event passed in to the machine. If we provide the second argument to the `send` function, the `options` object, we can send the event `to` a particular machine. This is useful when you have invoked a machine as a service on a state node, a concept that will be explored in a later lesson.

Send Events to the Machine with the XState Send Action Creator

It is considered best practice to use the string shorthand for actions, guards, and more when configuring an XState `Machine`. We do this by providing a second argument to the `Machine` factory function: the `options` object.

On this object, we can define our actions, guards, activities, services and more. We then refer to the name of these functions with a string of the same name.

```javascript
//...
broken: {
  entry: ['logBroken']
}
//...
// In the options object
{
  actions: {
    logBroken: (context, event) => { console.log('yo I am broke') }
  }
}
```

Replace Inline Functions with String Shorthands

It is often useful to identify conditional branching in your machine as a state itself. A state that is designed to determine the next state does not need a specific event sent to trigger the transition. Instead, we can use the "null event" to trigger an immediate, transient transition.

The null event is identified with an event name of an empty string `''`, and is immediately sent to the state upon entry. We can setup multiple targets with conditionals, or fire off actions to set up a future state with this transient transitions.

Use XState Null Events and Transient Transitions to Immediately Transition States

Transitions come in two varieties: "external" and "internal". By default, a transition is considered external. This means that a transition will _exit_ the current state node, and _enter_ the next state node (even if that state node is the state the machine is currently in). This exit/enter loop will trigger any actions that are set on the `exit` and `entry` properties.

A transition can be set to internal, either through setting a `.` (dot) in front of the state node name (as we do in this lesson), or through setting the property `internal` to `true` on the transition object.

When a transition is internal, it will not exit and enter the state node, which means that the actions in the `exit/transition/entry` loop will not be called.

Use Internal Transitions in XState to Avoid State Exit and Re-Entry

Mock Service Worker is an API mocking library that allows you to write client-agnostic mocks and reuse them across any frameworks, tools, and environments.



Mocking WebSocket APIs with Mock Service Worker


While using anonymous functions might seem convenient, they can create difficulties when trying to identify performance bottlenecks during profiling. This lesson will demonstrate how named functions make it easier to pinpoint and address performance issues, ultimately leading to more efficient and debuggable code. Learning this practice will greatly improve your ability to locate and fix performance issues in complex projects.

Always Name Functions in JavaScript


When attempting to load the same module twice in JavaScript you'll hit a cache and code won't re-run. In scenarios where you actually do want to have state in your modules, you'll have to use a cache-busting technique by passing a query parameter to a dynamic import. This lesson walks through how to add a query parameter, how to add the appropriate types for loading dynamic modules in TypeScript, and when these techniques are valuable.

Import the Same JavaScript Module Multiple Times with Cache Busting



The include keyword in GitHub Actions empowers you to add custom variables to your matrix strategy, providing flexibility beyond standard configurations. In this video, we'll explore how include allows you to define specific combinations of variables, enhancing control over your workflow runs. You'll see how this feature enables you to tailor jobs for unique environments or scenarios not covered by the default matrix options. By leveraging include, you can efficiently manage complex build processes with greater precision. This technique helps you streamline your CI/CD pipeline, making it more adaptable to your project's evolving needs.

Use GitHub Actions Matrix Include for Complex Job Configurations

While running `zod` schema validation agains domain-rich objects, the error message saying that _a string is not a number_ might not be really useful.

Especially, when you need to provide a meaningful feeback to the user, e.g. after they have submitted a form with lots of data.

`zod` allows to customize messages on a very granular level. We can also extract repeatable customization to `zod` error maps.

Finally, in order to process an error message further (e.g. display it to the user), we need to handle the `zod` validation errors effectively. Especially, when a big object validation has failed and we could receive a handful of errors.

That's what we learn in this lesson. 🔥

Customize zod Error Messages and Handle zod Errors Effectively

customize zod validation messages, customize zod schema property messages, reuse error maps across different schemas, navigate through zod error objects

You might want to run `zod` schema checks in different styles.

Sometimes you prefer to conditionally throw the error - that's what `parse` does. But another time you'd prefer to receive a `boolean` property that determines whether the validation was successful or not - and perform further actions accordingly.

Additionally, the error-throwing API of `parse` works extremely well with [TypeScript assertion functions](https://www.typescriptlang.org/docs/handbook/release-notes/typescript-3-7.html#assertion-functions). Their combination is just... perfect! 👌

That's what we learn in this lesson.

Use parse and safeParse Runtime Type-checks with zod

use zod parse function to conditionally throw ZodError, use zod safeParse to get a boolean value and run typescript type guard over success property

In this lesson we learn that TypeScript cannot guarantee correct shapes of responses. That's due to TS performing checks in compile-time, while the response will be availbale in runtime - when TS doesn't exist anymore.

In some situations, such as HTTP requests, runtime type checks such as `zod` are essential for providing quick feedback around data-related errors.

Understand where are the possible mistakes to make while using TypeScript with HTTP calls. Use `fetch` and `axios` along with `zod` schema checks.

Also, note that similar mistakes or mistakes could happen while using web storage (e.g. `localStorage`)

Validate HTTP API Response with zod, fetch and axios

use zod as an HTTP response validation tool along with fetch and axios in order to make sure that the response has expected data structure

In this lesson we learn that the `zod` schemas become the single source of truth.

We shall not update TypeScript types manually, since they are generated automatically from the schema.

Same with validation functions.

Whenever the schema changes, all the rest will update accordingly. It's an important mind shift.

Treat zod Schemas as Single Source of Truth

Zod Schemas are the single source of truth for both typescript types, and interfaces - and runtime validation functions. Schemas should be updated first.

`zod` is powerful, but writing the schemas manually for existing JSON objects, especially big ones, can be time-consuming.

But that's what `quicktype` is for! You can get 80% work done instantly! 🥳

Depending on your need - whether you want to automate the process, or do it just one time, you can:
- use an online app
- use an IDE extension
- run a CLI script
- generate a script to be executed within CI/CD environment/tooling

And this is what we learn in this lesson! 🔥🔥🔥

Get started with zod quickly!

Generate zod Schemas Automatically using Quicktype App, Extensions and Scripts

Use quicktype app, extension or scripts to automatically generate zod schemas from existing json files. Save time and get started with zod quickly!

`zod` is a powerful library allowing to run runtime type-checks.

It's complementary to TypeScript, which does type checks in compile time.

In this lesson we create few schemas that represent primitive type values, along with `zod` utilities which make these more precise. We also create object schemas and nest one inside another.

All schemas are being validated against example values. We analyze how to interpret error messages in case of failures.

Perform Runtime Type-checks on Primitives and Objects with zod

Create zod schemas to validate primitive type and object type values in runtime. Analyze the errors to see how a value doesn't correspond to schema expectations