
I am a massive fan of [React Query](https://tanstack.com/query/v4). It has grown on me to the point that it's now one of the first tools I set up when I start on a new project. If you're not familiar with React Query, at a high level it's a library that helps you manage your data fetching and client-side caching in React applications.

React Query makes it easy to write declarative data fetching code that gets access to all sorts of nice features like request states (`isLoading`, `isFetched`, etc), query deduping, query cancellation, cache control and persistence, and a [whole lot more](https://tanstack.com/query/v4/docs/comparison) &mdash; and it gives you the power to manipulate your client-side cache in pretty much any way you might need.

If you just need to fetch some data you can use [`useQuery`](https://tanstack.com/query/v4/docs/reference/useQuery) with one or two lines of code and be on your way, but as your application grows in complexity you may find yourself wanting to connect to a websocket to receive real-time updates from your server. Fortunately, React Query makes this quite painless.

## Querying data

When you're ready to start updating your client via websockets, if you're already using React Query, the good news is that nothing really changes with the way you fetch your data.

```js
const { data } = useQuery({
  queryKey: ['replies', postId],
  queryFn: () => fetchReplies(postId),
});
```

Here we've got a `fetchReplies` function that returns a promise that resolves to an array of replies for a given post. We're using the `queryKey` to identify this query, and we're using the `queryFn` to call our `fetchReplies` function.

## Subscribing to a websocket

In this example, we're going to use [Pusher](https://pusher.com). I like Pusher because they have an [open specification](https://pusher.com/docs/channels/library_auth_reference/server-library-reference-specification/) and there are other, self-hostable [alternatives](https://soketi.app/) that implement the Pusher spec. Meaning you can build on Pusher and if your application scales to the _incredibly expensive_ tiers of Pusher.com, you don't have to rewrite your entire socket architecture to cut some costs. You can just host your own server.

```js
React.useEffect(() => {
  const channel = pusher.subscribe('postEvents');

  channel.bind('newReply', (event) => {
    /* ... */
  });

  return () => {
    channel.unbind('newReply');
    pusher.unsubscribe('postEvents');
  };
}, []);
```

## Interacting with the cache

There are two ways that I typically approach passing a socket message along to React Query. Each are useful in different contexts, so we'll cover both and when you might want to use one over the other.

The first is to invalidate the query by `queryKey`, so that the next time that query is needed it'll fetch fresh data from the server. This approach minimizes the amount of data over the wire via the websocket and allows users to only fetch the data that they need, when they need it.

The second approach is to send the updated data through the websocket and then manually update the `queryClient` cache with that new data. This approach is better if you expect to have a frequent, small updates or if you expect a large number of concurrent consumers &mdash; and want to avoid triggering a thundering herd every time new data is available.

### Invalidate Query

When a socket event occurs, we'll use [`queryClient.invalidateQueries`](https://tanstack.com/query/v4/docs/reference/QueryClient#queryclientinvalidatequeries). The nice thing about React Query here is that if the query is actively being used, it'll refetch that data in the background and show the stale data in the UI until the new data is available. If that query is _not_ actively being used, React Query marks it as invalidated and fetches it the next time the user needs it. 

Using the same example from above, we'll fill out the `newReply` event handler.

```js
React.useEffect(() => {
  const channel = pusher.subscribe('postEvents');

  channel.bind('newReply', (postId) => {
    queryClient.invalidateQueries({
      queryKey: ['replies', postId]
    })
  });

  return () => {
    channel.unbind('newReply');
    pusher.unsubscribe('postEvents');
  };
}, []);
```

Now on the server, you can send a message to the `post-replies` channel with the `postId` as the event data:

```js
pusher.trigger('postEvents', 'newReply', postId);
```

### Manually update the cache

If you expect to have frequent, small updates &mdash; like a chat feature &mdash; or a large number of concurrent users it is probably better to ship the updated data over the websocket and update the cache by `queryKey` directly using [`queryClient.setQueryData`](https://tanstack.com/query/v4/docs/reference/QueryClient#queryclientsetquerydata).

```js
React.useEffect(() => {
  const channel = pusher.subscribe('postEvents');

  channel.bind('newReply', (reply) => {
    queryClient.setQueryData(
      ['replies', reply.postId],
      (cacheData) => [...cacheData, reply]
    );
  });

  return () => {
    channel.unbind('newReply');
    pusher.unsubscribe('postEvents');
  };
}, []);
```

In this case, we're still updating the same record by `queryKey` but instead of telling React Query to fetch the data next time it needs it, we just take the cached value as a parameter in our update function and append our new comment entry to the array.

And on the server side, rather than just sending the `postId` we'll send the entire `reply` object.

```js
pusher.trigger('postEvents', 'newReply', reply);
```



Using Websockets with React Query


I honestly can't tell if the Twitter acquisition is going off the rails or according to plan.

I'm not sure what will happen to Twitter over the coming weeks and months, but it seems inevitable that the outcome will at minimum be fragmentation of the various communities that I've followed and engaged with over the years.

If you're part of the contingent that's bailing on Twitter, I'm [@jonbellah@mastodon.social](https://mastodon.social/@jonbellah).

Bye bye, Birdie


After almost a decade working as an individual contributor — with a few short stints in engineering leadership-adjacent roles — I've decided to finally make the
jump to engineering management.

Today is my first day as an Engineering Manager at [Endeavor](https://www.endeavorco.com/story/).

Beyond learning an entirely new skillset, I'm particularly excited about this new role for a few key reasons.

First, Endeavor is just an incredibly interesting and exciting company to go to work for. They've got their hands in a broad swath of the sports and entertainment
industries, from being one of the largest [talent agencies](https://www.wmeagency.com/expertise/) and [sports and event management](https://img.com/expertise/)
companies in the world to being the parent company of the [UFC](https://ufc.com) and [PBR](https://pbr.com/) &mdash; and so, so much more.

Secondly, I'll be working with _several_ friends from my time at TED. The TED Tech team was one of the smartest and most close-knit groups that I've ever worked
with and getting a chance to go work with a bunch of them again is super exciting.

And lastly, I'll be leading a team at an internal incubator charged with innovating and building the next generation of Endeavor's business. The William
Morris Agency &mdash; the precursor to today's Endeavor &mdash; was formed almost 124 years ago&hellip; and a company doesn't survive for 124 years by remaining
stagnant. Endeavor has innovated and grown their business decade-after-decade and I'm looking forward to playing a (small) part in writing the next chapter of
that story.

I'll likely be hiring for my team very soon, so if you're interested in working with me, don't hesitate to [reach out](https://jonbellah.com/contact)!

Making the Jump to Engineering Management


In my [last post](https://jonbellah.com/articles/renewed-focus), I talked a bit about migrating this blog over from Gatsby to Next.js. One thing I had to
sort out in that migration was moving from the relatively-straightforward implementation of `gatsby-plugin-feed` to building a custom-rolled RSS feed.

It actually turned out to be a relatively painless process, so I thought I'd share how it works.

## A Bit of Background

First, it's probably helpful to cover how I've got things set up. I write everything in markdown (mdx) and have it sitting in a `content` directory,
alongside the `src` and `public` directories in my codebase.

Here's roughly the file structure we'll be working with in this tutorial:

```
blog/
├─ src/
│  ├─ pages/
│  │  ├─ api/
│  │  │  ├─ rss/
│  │  │  │  ├─ index.ts
│  │  │  │  └─ feed.json
├─ scripts/
│  └─ rss.mjs
├─ content/
│  └─ blog-post.mdx
└─ package.json

```

The way that this will end up working is that we will use a `prebuild` hook in our `package.json` to run a node script that will grab all of our posts
and format them into a `feed.json` file. From there we'll create an API route that will use that json file to serve up our RSS feed. Lastly, we'll use our
`next.config.js` file to add a rewrite, so that we can serve the RSS feed from `/rss.xml`.

## The Node Script

This node script will be run on a `prebuild` hook. When we build our site to deploy, the script will run through the `content/` directory, grab all of our posts
loop through them and format them into a `feed.json` file that we can deploy alongside our API endpoint.

The primary reason for generating this JSON file is so that we don't have to do a bunch of file system reads when someone requests the RSS feed.

Here's the script in full:

```js
// scripts/rss.mjs
import fs from 'fs';
import matter from 'gray-matter';
import path from 'path';

const generateRss = async () => {
  const POSTS_DIR = path.join(process.cwd(), 'content');
  const posts = fs
    .readdirSync(POSTS_DIR)
    .filter((filePath) => filePath !== '.DS_Store') // only needed for macOS
    .map((filePath) => {
      const source = fs.readFileSync(path.join(POSTS_DIR, filePath));
      const { content, data } = matter(source);

      return {
        content,
        data,
        filePath,
      };
    })
    .sort(
      (a, b) =>
        new Date(b.data.date).getTime() - new Date(a.data.date).getTime(),
    );

  // Create sitemap file
  fs.writeFileSync('src/pages/api/rss/feed.json', JSON.stringify(posts));
};

generateRss();
```

The way this works is that we're calling `readdirSync` on the directory that contains all of our mdx files to get an array of file names,
then filtering out the `.DS_Store` file (only necessary for macOS), and then mapping over that list of files.

When we map over the array of file names, we then call `readFileSync` to read the individual file and use the `gray-matter` package to extract the
frontmatter into an object, and return all of that data to make our `posts` variable an array of objects that contain all of our posts and their frontmatter.

Finally, we sort the posts by publish date and then call `fs.writeFileSync` to write a `feed.json` file into the `pages/api/rss` directory; where it'll sit next
to the API endpoint handler.

## The Prebuild Hook

Not much to this one. When you run `npm run build`, the `prebuild` hook will run before the build process begins. We'll use this hook to run the node script we just built.

```json
{
  "scripts": {
    "generate:rss": "node scripts/rss.mjs",
    "prebuild": "npm run generate:rss"
  }
}
```

## The API Route

This is the meat and potatoes of serving up the RSS feed. We're using a custom [API route](https://nextjs.org/docs/api-routes/) to run a lambda function that
loads up the JSON file that we generated in the previous step, formats it into an XML document, and returns it back to the requester.

```js
// src/pages/api/rss/index.ts
import { NextApiRequest, NextApiResponse } from 'next';
import nc from 'next-connect';

import { BlogPost } from 'lib/types';

import feed from './feed.json';

const metadata = {
  title: 'JonBellah.com',
  description: 'About my site!',
  link: 'https://jonbellah.com'
}

const handler = nc();

/**
 * Respond with an rss.xml
 *
 * @param {object} req NextApiRequest
 * @param {object} res NextApiResponse
 */
handler.get(async (req: NextApiRequest, res: NextApiResponse) => {
  try {
    const postItems = feed
      .map((page: BlogPost) => {
        const url = `${
          process.env.NEXT_PUBLIC_ROOT_URL
        }/articles/${page.filePath.replace('.mdx', '')}`;

        return `<item>
          <title>${page.data.title}</title>
          <link>${url}</link>
          <guid>${url}</guid>
          <pubDate>${page.data.date}</pubDate>
          ${
            page.data.excerpt &&
            `<description>${page.data.excerpt}</description>`
          }
          ${/**
           * NOTE: page.content on the next line should be wrapped with
           * the CDATA tag, but it breaks my _actual_ RSS feed if I
           * include it. Check the link to the source at the bottom
           * of this post for the actual code.
           */}
          <content:encoded>${page.content}</content:encoded>
        </item>`;
      })
      .join('');

    // Add urlSet to entire sitemap string
    const sitemap = `<?xml version="1.0" encoding="UTF-8"?>
    <rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0">
      <channel>
      <title>${metadata.title}</title>
      <description>${metadata.description}</description>
      <link>${metadata.link}</link>
      <lastBuildDate>${feed[0].data.date}</lastBuildDate>
      ${postItems}
      </channel>
      </rss>`;

    // set response content header to xml
    res.setHeader('Content-Type', 'text/xml');

    return res.status(200).send(sitemap);
  } catch (e: unknown) {
    if (!(e instanceof Error)) {
      throw e;
    }

    return res.status(500).json({ error: e.message || '' });
  }
});

export default handler;
```

It's worth noting, too, that if you're using a CMS that has a REST API &mdash; like [WordPress](https://wordpress.org/) &mdash; you can fetch the list of posts in this
lambda function and build your RSS feed on-the-fly. If your content _is_ stored in an external CMS, you can skip the `prebuild` script and just use the API route.

Another thing worth noting is that the `url` variable within the `postItems` map assumes that the path for posts will be `articles/{post-slug}`. Be sure to change that to
whatever path you prefer for your own site.

## Configure the Next Rewrite

The final step to get this up and running is to use our `next.config.js` file to add a rewrite, so that we can serve the RSS feed from `/rss.xml` instead of `/api/rss`.

Feel free to make the `source` route whatever you prefer, especially if you're trying to preserve the route to an existing RSS feed.

```js
// next.config.js
module.exports = {
  rewrites: async () => [
    {
      source: '/rss.xml',
      destination: '/api/rss',
    },
  ],
};
```

Now once you deploy your site to Vercel, you can visit `yoursite.com/rss.xml` and see your RSS feed!

## Source

You can find the source code for this tutorial [here](https://github.com/jonbellah/tutorials/tree/main/apps/nextjs-rss-feed).


Adding an RSS Feed to a Next.js Blog


Last year, I announced the launch of a project called JSFoundry. At the time, my objective was to build a place to put all of my tutorials,
courses, and other teaching-related materials with a goal of separating those materials out into their own "brand", so that (eventually)
I could tap into other educators and begin building up a community.

Today, I'm announcing that I'm shutting it down.

## What happened?

Well... _:gestures_wildly:_ a lot of things. The pandemic might be one (small) factor, but it was certainly not the only one.

On top of a couple of job changes, being a dad, and working on a long-running freelance retainer; the simple truth is that pretty much as soon as I
launched the site I lost sight of the core objective. I was exhausted by trying to figure out "if I write this blog post, where should it go?" or "do I
want to spin up a separate YouTube channel for new tutorials?" and all of the other strategic questions that, honestly, I should've thought through before
building out the site.

I had analysis paralysis. For no real reason.

It was a good learning experience, but not exactly time well-spent.

As I continued to stew on the strategic questions, I realized that ultimately my goal is and always has been to build a SaaS business, not necessarily an
info product business. I have always wanted to build my own company &mdash; and eventually work for myself &mdash; and, at the end of the day, I feel that
building software is a better fit for what I envision that work to be. I love teaching, but I've always enjoyed the work of actually writing code more than
writing blog posts or recording and editing tutorials.

At the same time, though, I have always felt &mdash; and continue to feel &mdash; strongly about the value of teaching and developer education work. I honestly
believe it has the power to change peoples lives. Helping people along their journey, particularly towards their first developer jobs, is one of the most rewarding
feelings ever. So, it's something that I absolutely plan to continue doing... just without the pressure of trying to build up some brand or business.

## Well, what now?

First off, while this site may look the same as it has for a while, I've migrated it over from Gatsby to Next. I've moved all of my blog and course-related code
into a [Turborepo](https://turborepo.org/), where I can more easily manage everything.

I took a bit of time to tear apart my course platform and trim it down to only the absolute essentials, improved those features deemed essential, and relaunched
the LMS at its original location: [courses.jonbellah.com](https://courses.jonbellah.com).

The migration and cleanup process was actually quite fun: I migrated from Mongoose to Prisma, MongoDB to MySQL (hosted on [PlanetScale](https://planetscale.com/)),
from PassportJS to [next-auth](https://next-auth.js.org) with magic link sign-in, and from a custom Stripe Elements implementation to a very hands-off Stripe Checkout
process. I also finally moved all my remaining projects over to [Vercel](https://vercel.com/).

I also took a little bit of time to redesign and relaunch [LearnStateMachines.com](https://learnstatemachines.com) as its own standalone course site again. There's been
a lot of movement on the [XState V5](https://github.com/statelyai/xstate/pull/898) PR and I still intend to release a new version of the course when that lands. I'm quite
happy with how the design turned out and am looking forward to dusting off that course again soon.

In the end, the best part was being able to delete _so_. _much_. _code_.

Now things are much more clear and everything has its place. No more distractions. No more clutter.

## What's next?

Finally making the decision to throw away all that work actually feels pretty great. There was an immediate feeling of clarity, like a dam had been broken.

As for what's next, I'm going to continue putting work into the same projects that I have been... now just with more precise focus around the goals, objectives, and motivations.

[BugCatcher](https://bugcatcher.io) is still in its early days &mdash; having taken about a year of real time to do ~3 months of work, due to the aforementioned juggling
of a freelance project &mdash; but I'm very excited about the problem space and the people we're solving the problem for. We've got a lot of interesting work on the roadmap.

As for writing and teaching, I'm hesitant to promise that I'll be any better about publishing content more regularly. The truth is that I've always been terrible at building
a habit of writing or recording tutorials. I _will_ say that it's something I'm keen to improve on, though. One idea that I'm kicking around is to share some of the under-the-hood
work I'm doing on BugCatcher, either as pre-recorded videos or as a livestream. And, of course, releasing a new version of Learn State Machines once XState V5
lands.

Lastly, I've got some pretty exciting career-related news that I'll be talking about more soon!


A Renewed Sense of Focus


Over the last few months, I’ve been working on a ground-up rewrite of my [state machines course](https://learnstatemachines.com). Despite the fact that it’s only a few months old — originally launched in August 2018 — there have been some pretty major developments in the both of the main libraries that the course relies upon heavily: XState and React.

As part of the rewrite, I’ve been doing a ton of tinkering with all the new features in both, trying to find places where I can make code quality improvements in the app that the course is centered on. In the process of that exploration, I have become incredibly fond of using statecharts with hooks.

When I sat down to write this post, I started looking back at some reference material and ended up looking at the code example in [my last post](https://jonbellah.com/articles/intro-state-machines/), which was published just a couple of weeks before hooks were announced. All of a sudden, that example started looking really dated to me… it’s amazing how patterns can change so much, so quickly.

So, in this post we’re going to rewrite that example payment form from scratch using hooks. Here’s a quick look at the form we’ll be wiring up:

<div className="w-full aspect-video">
  <iframe
    className="w-full h-full object-center object-cover"
    scrolling="no"
    title="State machine payment form - wired"
    src="//codepen.io/jonbellah/embed/oagRpX/?height=300&theme-id=515&default-tab=js,result"
    frameBorder="no"
    allowtransparency="true"
    allowFullScreen
  >
    See the Pen{' '}
    <a href="https://codepen.io/jonbellah/pen/oagRpX/">
      State machine payment form - wired
    </a>
    {' '} by Jon Bellah (<a href="https://codepen.io/jonbellah">@jonbellah</a>) on{' '}
    <a href="https://codepen.io">CodePen</a>.
  </iframe>
</div>

If you'd rather check this out in video form, I recently published a video on my YouTube channel that covers the material found in this article:

<div className="w-full aspect-video">
  <iframe
    className="w-full h-full object-center object-cover"
    src="https://www.youtube.com/embed/73Ch_EL4YVc"
    frameBorder="0"
    allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture"
    allowFullScreen
  />
</div>

Without further ado, let's dig in!

### Hooks at a glance

If you’re not familiar, hooks were released in React 16.8 and provide developers with a way to use React features — like state and lifecycle methods — within function components. Prior to 16.8, if you needed a stateful component, you were required to write a class which [had a fair number of tradeoffs](https://medium.com/@dan_abramov/making-sense-of-react-hooks-fdbde8803889#5655).

In short, hooks allow us to simplify our components by flattening out our component hierarchy, breaking our application logic into reusable chunks, and avoiding unnecessary nesting components with patterns like render props or higher-order components.

If you’re interested in digging in a bit more, I recently published [React Hooks in 10 Minutes](https://www.youtube.com/watch?v=IlgebhSP3zI) — which gives a nice primer into hooks. The React team has also provided some [excellent documentation](https://reactjs.org/docs/hooks-intro.html).

### Create the custom state machine hook

There are a couple of options here, Carlos Galarza has a nice solution with [use-machine](https://github.com/carloslfu/use-machine/), but I typically just reach for the `useMachine` hook provided in the XState documentation.

```js
import { useState, useMemo, useEffect } from ‘react’;
import { interpret } from ‘xstate’;

export function useMachine(machine) {
  // Keep track of the current machine state
  const [current, setCurrent] = useState(machine.initialState);

  // Start the service (only once!)
  const service = useMemo(
    () =>
      interpret(machine)
        .onTransition(state => {
          // Update the current machine state when a transition occurs
          if (state.changed) {
            setCurrent(state);
          }
        })
        .start(),
    []
  );

  // Stop the service when the component unmounts
  useEffect(() => {
    return () => service.stop();
  }, []);

  return [current, service.send];
}
```

Let’s break down what’s happening above: - At the top of the hook, we’re calling the [useState](https://reactjs.org/docs/hooks-reference.html#usestate) hook to set the default state to the `initialState` of our state machine. - Then we create a memoized value of our [interpreter](https://xstate.js.org/docs/guides/interpretation.html#the-xstate-interpreter). The second parameter on `useMemo` — the empty array — tells React that we don’t have any dependencies, meaning we don’t want React to recompute our memoized value on future renders. - In `useEffect`, we listen for the component to unmount and, when it does, stop the interpreter service. - And finally, we return the current state of our machine, along with an update function (`service.send`) that we can use in our components to transition that state.

### Defining the state machine

Next, we’ll define the state machine for our payment form. I’ll start by showing the basic machine, then we’ll layer in the various guards and services we’ll need.

```js
const stateMachine = Machine({
  initial: 'idle',
  states: {
    idle: {
      on: {
        SUBMIT: 'loading',
      },
    },
    loading: {
      on: {
        PAYMENT_SUCCESS: 'success',
        PAYMENT_FAILED: 'error',
      },
    },
    error: {
      on: {
        SUBMIT: 'loading',
      },
    },
    success: {
      type: 'final',
    },
  },
});
```

If we jump over to the [XState Visualizer](https://statecharts.github.io/xstate-viz/), we can drop the above definition in and see a visualization of the state machine.

![](https://jonbellah.com/images/blog/xstate-react-hooks/stateviz.png)

Looks like we nailed this one! We start in the _idle_ state, when the user submits the form, we enter the _loading_ state. From there, we’ll fire off a request and if the payment fails we transition to the _error_ state; and if it succeeds, we transition into the _success_ state. From the _error_ state, the user can submit the form again and be transitioned back into the _loading_ state.

There are a few more things we need to do, though. The first is that we need to check that a user has entered text into the fields before we transition into the _loading_ state… for that, we’ll use guards.

```js
const stateMachine = Machine({
  initial: 'idle',
  context: {
    msg: '',
  },
  states: {
    idle: {
      on: {
        SUBMIT: [
          {
            target: 'loading',
            cond: (ctx, event) =>
              event.data.name !== '' && event.data.card !== '',
          },
          { target: 'error' },
        ],
      },
    },
    // loading state remains the same
    error: {
      on: {
        SUBMIT: {
          target: 'loading',
          cond: (ctx, event) =>
            event.data.name !== '' && event.data.card !== '',
        },
      },
    },
    // success state remains the same
  },
});
```

In the _idle_ and _error_ states, we have guards that check that the `event.data.name` and `event.data.card` values are not empty. In the _idle_ state, we pass an array that tells XState that if the condition fails, that we should transition into the _error_ state.

Lastly, we need to invoke a service in the _loading_ state to call our payment function. I’ve left off all but the relevant parts in this example,

```js
const stateMachine = Machine({
  initial: 'idle',
  context: {
    msg: '',
  },
  states: {
    // idle state remains the same
    loading: {
      invoke: {
        id: 'doPayment',
        src: (ctx, event) => doPayment(event.data),
        onDone: {
          target: 'success',
          actions: assign({ msg: (ctx, event) => event.data }),
        },
        onError: {
          target: 'error',
          actions: assign({ msg: (ctx, event) => event.data }),
        },
      },
    },
    // error and success states remain the same
  },
});
```

When the user clicks the submit button and we transition into the _loading_ state, we’re now [invoking a service](https://xstate.js.org/docs/guides/communication.html) that will call our payment function. The payment function will return a promise that is then either resolved or rejected.

If, for example, the promise is rejected (`onError`), then we’ll transition into the _error_ state. _When_ we transition into the _error_ state we call an [action](https://xstate.js.org/docs/guides/actions.html#the-actions-property), which in this case uses [assign](https://xstate.js.org/docs/guides/context.html#updating-context-with-assign) to update the `msg` context we’ve defined on our machine. This is a helpful place to return error message that we can then display to our user.

For demo purposes, `doPayment()` is just a function that returns a promise and then “rolls a dice” to determine whether or not to resolve or reject the promise after waiting for 1 second (to fake the feeling of an asynchronous request). If you’re curious, here’s what that looks like:

```js
function fakePayment() {
  return new Promise((resolve, reject) => {
    setTimeout(() => {
      const dice = Math.floor(Math.random() * Math.floor(2));

      if (dice === 0) return resolve('Payment succeeded.');

      return reject('Payment failed.');
    }, 1000);
  });
}
```

### Putting it all together

Lastly, we need to build our actual component. Let’s start with the basic HTML and CSS from the CodePen embed at the beginning of this post, then we’ll start wiring things up.

Here’s the starting point for our component:

```js
const App = () => {
  return (
    <div className="form-container">
      <div className="form-header">
        <h2>State Machine Payment Form</h2>
      </div>

      <div className="form-body">
        <form>
          <div className="form-group">
            <label htmlFor="NameOnCard">Name on card</label>
            <input
              id="NameOnCard"
              className="form-control"
              type="text"
              maxLength="255"
            />
          </div>
          <div className="form-group">
            <label htmlFor="CreditCardNumber">Card number</label>
            <input
              id="CreditCardNumber"
              className="null card-image form-control"
              type="text"
            />
          </div>
          <button
            id="PayButton"
            className="btn btn-block btn-success submit-button"
            type="submit"
          >
            <span className="submit-button-lock" />
            <span className="align-middle">Pay Now</span>
          </button>
        </form>
      </div>
    </div>
  );
};
```

The first thing we should do to start wiring everything up is set our default state:

```js
const App = () => {
  const [machine, send] = useMachine(stateMachine);
  const [form, setForm] = useState({
    name: '',
    card: '',
  });
  // markup remains unchanged
};
```

Here, we first pass the state machine that we defined in the last section to the custom hook that we defined in the section before. Then we define a separate, component-specific `useState` that we will store our form variables in. Since they’re not values that need to be communicated to other machines or components, I like to keep them local to the component where they _are_ needed.

Next, we can add our error and success messages:

```js
const App = () => {
  // consts remain unchanged
  return (
    <div>
      <div className="form-container">
        <div className="form-header">
          <h2>State Machine Payment Form</h2>
        </div>

        {machine.matches('error') ? (
          <div className="alert error">
            {machine.context.msg
              ? machine.context.msg
              : 'You must fill out all the form fields.'}
          </div>
        ) : null}

        {machine.matches('success') ? (
          <div className="alert success">
            {machine.context.msg ? machine.context.msg : null}
          </div>
        ) : null}

        // rest of the markup remains unchanged
    </div>
  );
};
```

Here we’re checking if the current state of our machine [matches](https://xstate.js.org/docs/guides/states.html#state-methods-and-getters) either _error_ or _success_. If so, we display our alert with the message that was `assign`’d to our machine context message.

The final step will be to wire our form submission up to the machine itself.

```js
<form
  onSubmit={(e) => {
    e.preventDefault();
    send({ type: 'SUBMIT', data: { ...form } });
  }}
>
  <div className="form-group">
    <label htmlFor="NameOnCard">Name on card</label>
    <input
      id="NameOnCard"
      className="form-control"
      type="text"
      maxLength="255"
      value={form.name}
      onChange={(e) => updateForm({ ...form, name: e.target.value })}
    />
  </div>
  <div className="form-group">
    <label htmlFor="CreditCardNumber">Card number</label>
    <input
      id="CreditCardNumber"
      className="null card-image form-control"
      type="text"
      value={form.card}
      onChange={(e) => updateForm({ ...form, card: e.target.value })}
    />
  </div>
  <button
    id="PayButton"
    className="btn btn-block btn-success submit-button"
    type="submit"
  >
    <span className="submit-button-lock" />
    <span className="align-middle">Pay Now</span>
  </button>
</form>
```

When the user submits the form, we will call `preventDefault()` so that the browser doesn’t refresh the page. Then we send the _SUBMIT_ event to the machine, along with the data that the user has provided in the form fields. That data is what the machine will use when it checks the guard conditions, then subsequently transitions into the _loading_ state, and finally sends that data along with our `doPayment()` function.

And now, here’s the final payment form:

<div className="w-full aspect-video">
  <iframe
    className="w-full h-full object-center object-cover"
    src="https://codesandbox.io/embed/vmzllz0yp0?fontsize=14"
    sandbox="allow-modals allow-forms allow-popups allow-scripts allow-same-origin"
  />
</div>

> Hey, as I mentioned earlier in this post, I actually made a course about building JavaScript applications with state machines and statecharts. Version 2 is on its way! If you want to check out the course, you can find it at [learnstatemachines.com](https://learnstatemachines.com/).


Writing on software design, entrepreneurship, and whatever else is on my mind.

Using Websockets with React Query

Bye bye, Birdie

Making the Jump to Engineering Management

Adding an RSS Feed to a Next.js Blog

A Renewed Sense of Focus

Use XState with React Hooks