DEV Community: Sajjat Hossain

Getting started with XState

Sajjat Hossain — Tue, 06 May 2025 01:48:17 +0000

What is XState?
Why should you use XState?
Create a state machine
Consume the machine
Conclusion

What is XState?

XState is a state machine, often described as a state orchestrator. Sound unfamiliar? Let’s break it down.

A state machine is similar to other state management solutions, but it’s unique in how it handles state. Unlike traditional approaches where you can assign any value at any time, a state machine exists in only one state at a given moment. To transition to a new state, specific conditions—such as events or rules defined in advance—must be met.

Why should you use XState?

While working on a project did you ever feel like, "The conditions are too complex to handle with simple if-else"? If so, then XState is your best choice here. As mentioned perviously, it let's you be in a specific state at a given moment, if you meet the criteria, there is little to no chance to mess it up once configured properly. From one step to another step, there's going to be specific rules. and also from one state you can only transition to another specified state. example:
Let's say you have 3 states. A, B and C. Now the transitions are as follows:

A -> C.
B -> C.
C -> B -> A.
C -> A.

Let's break down these transition

For 1, You can only visit from A to C.
For 2, You can visit from B to C.
For 3 and 4, You can visit from C to B then from B to A. or from C to A.

Let's see it visually

stateDiagram-v2
    [*] --> A
    A --> C: TO_C
    B --> C: TO_C
    C --> B: TO_B
    B --> A: TO_A
    C --> A: TO_A

Now, if I ask you to write a logic to implement these transitions and safe guard the other states based on the current state using XState, you will immediately start feeling the heat. Although it is achievable by only using if-else, it's going to be really easy to make mistakes and hard to maintain once you start to add more and more states. But with XState it's going to be not very easy but not hard at all considering the complex logics.

Now, to answer the question, if you have complex logics then you should go for solutions like XState, etc. And if not, then you are good with simple if else.

Create a state machine

Now let's create a simple state machine using XState to solve the problem.

This is how it will look like.

import { createMachine } from 'xstate';

const stateMachine = createMachine({
  id: 'example',
  initial: 'A',
  states: {
    A: {
      on: { TO_C: 'C' }
    },
    B: {
      on: { TO_C: 'C', TO_A: 'A' }
    },
    C: {
      on: { TO_B: 'B', TO_A: 'A' }
    }
  }
});

Now, let's try to understand what's happening here.

Firstly you have to import the createMachine function from the xstate package.
A machine must have an id and an initial state. Initial state defines from where the machine starts it's journey.
Then you have to add the states. In this case, there can will be 3 states, A, B and C.
Now define the transitions. You have to define your transitions within the on object. As per the problem, the transitions are defined here.

Consume the machine

Here's how you can consume it.

import { interpret } from 'xstate';

const service = interpret(stateMachine)
  .onTransition((state) => {
    console.log(`Current state: ${state.value}`);
  }).start();

console.log('Sending events...');

// Test transitions,
service.send('TO_B'); // A → B (fails, stays in A,) 
service.send('TO_C'); // A → C 
service.send('TO_B'); // C → B 
service.send('TO_A'); // B → A
service.send('TO_B'); // A → B (fails again)
service.send('TO_C'); // A → C 
service.send('TO_A'); // C → A

The solution here shows you how you can consume it in vanilla javascript. You use the interpret function that returns the service. and then start it. After that from your code you can use the send method from the service to transition to any state. Here are all the transitions from our problem also a failed transition, from A -> B. There's no transition defined in the machine to visit B from A directly. So, whenever you try to visit the state directly, it's going to fail. Only the transitions that are valid are going to be successfully executed.

Conclusion

I hope I was able to give you a quick sneak peak of XState and help you understand it's potential. Also help you understand if you should use it or not and when should you use it. This example shows only the bare minimum power of XState. There's more that you can do with it.

RTK Query: Let's go beyond minimal setup

Sajjat Hossain — Sun, 23 Oct 2022 14:51:46 +0000

Previously we saw how we can get started with RTK Query with a minimal setup. If haven't read that already, I would suggest you to take a look at it. It would make it easy for you to understand this one. In this setup we will go beyond our minimal setup and would learn some simple tricks. Click here to read the previous blog

I assume that you're using Redux Toolkit to manage your global states, and not just RTK Query to manage your APIs. Here's how you have to configure your store to use Redux Toolkit Query in conjunction with your global states.

Configure Store :

import { configureStore } from '@reduxjs/toolkit';
import { demo } from 'store/api/demoSlice';
import { setupListeners } from '@reduxjs/toolkit/dist/query';

export const store = configureStore({
  reducer: {
    yourStateSlice,
    demo
  },
  middleware: (getDefaultMiddleware) =>
    getDefaultMiddleware().concat([
      demo.middleware,
    ])
});

setupListeners(store.dispatch);

Here, as you can see, it looks different than the usual setup. We're adding the demo api slice as the rest but there are two extra thing (middleware and setupListeners). Let's learn why we need these two.

The api slices are like other state slices. They hold their own state. But why do they need their own state? For the caching purpose that we talked about. Now, If they are similar, then why we need these extra configurations? Because, they might be similar but as you may know, when you fetch data from the api, you need to handle it asynchronously. You have to wait for the response. For which you can use them as regular slices. You need to add them to the middleware list so that they interrupt your regular state management and also handle the responses asynchronously. Also you need add the setupListeners to listen for the actions being dispatched.

Multiple api slice :

Another part of this setup is to show you, how you can configure your store to have multiple api slices. It's pretty simple. You just have to create another slice and add to the reducer and middleware list as shown blow,

import { configureStore } from '@reduxjs/toolkit';
import { demo } from 'store/api/demoSlice';
import { demo2 } from 'store/api/demo2Slice';
import { setupListeners } from '@reduxjs/toolkit/dist/query';

export const store = configureStore({
  reducer: {
    yourStateSlice,
    demo,
    demo2
  },
  middleware: (getDefaultMiddleware) =>
    getDefaultMiddleware().concat([
     demo.middleware,
     demo2.middleware
   ])
});

setupListeners(store.dispatch);

See! really easy right? So, far we've configured the store but there's one thing still remaining. That is to wrapping up the root app with the provider. But wait, did we do that previously? we don't need to do that again. You're right and also wrong at the same time. You're right that we've already wrapped the root with the provider. But you're also wrong cause we wrapped the root with the ApiProvider. You can only use api slices with that provider not the state slices.

Yeah. Right. Then we just wrap the root with provider that we used to use for the state slices right?

No, we can not just use that. First we have to remove the api provider and wrap the root only with the regular state provider because we're already passing the api slices as/with the rest of the state slices. So we don't need that anymore. The updated code should look like this,

import React from 'react';
import ReactDOM from 'react-dom/client';
import { Provider } from 'react-redux';
import { store } from 'store/';
import Index from 'pages/'

function App() {
  return (
    <Provider store={store}>
      <Index />
    </Provider>
  );
 }

Just pass the store and you're all done.

Now, as you have multiple api slices, please be sure to differentiate the api tags from each api slice. Because they might end up creating some unexpected behaviour.

Here comes a trick :

How can you request for multiple api calls that may require the response from the another api?

Ans: You have to skip the next request conditionally. This might sound trick but it's actually easy. Here's how to do it.

const {data, ...} = demo.useAnImportantQuery();
const {data: data2, ...} = demo.useAnothereImportantQuery({data.id},{skip: !data})

This way the second call will be skipped untill you get successful response from

the first api or the data has no value.

RTK Query: Make fetching and caching data effortless.

Sajjat Hossain — Tue, 04 Oct 2022 18:50:23 +0000

RTK query which is the short form of Redux Toolkit Query is a data fetching and caching library that comes bundled with Redux Toolkit. If you're a person using Redux Toolkit to manage your application global store then this is going to be the best go-to for you.

There are a few alternatives to Redux Toolkit, React-Query and React-Saga are amongst them. These libraries need a bit more configuration to work. Like, React Query wants you to use your choice of data fetching library (e.g Axios or fetch API). But RTK Query handles all of it for you. You just need to create an endpoint module and add the required configurations. After you add the base configurations you're ready to roll. Also, it makes handling loading states, and errors a lot easier. Now let's see how we can implement RTK Query with minimal configuration.

First, we'll see how you can just use the RTK Query without using Redux Toolkit in your project.

1. Create a store :

Create a folder named store at the root of your project.

Now, create a folder called reducers inside of it. To separate our API slices from global state slices let's create a folder called API and we'll create all the API slices inside of it. Now the slice config,

Slice with a single endpoint. Let's name it to demo.

import { createApi, fetchBaseQuery } from '@reduxjs/toolkit/query/react';

interface IReturn {
  key[string]: any;
}

interface IParams {
  key[string]: any;
}

export const demo = createApi({
  reducerPath: 'demo',
  baseQuery: fetchBaseQuery({
    baseUrl: 'https://baseurl.com'
  }),
  tagTypes: ['tag'],
  endpoints: (builder) => ({
    getSingleData: builder.query<IReturn, IParams>({
      query: ({ slug, id }) => `/${slug}/items/${id}`
    })
  })
});

You need to add reducerPath just like you need to do for reducer slices. Now, there are two types of builder methods. query and mutation. Queries are used when you're not trying to mutate or change any data. For Get requests in short. And mutations are used to change,update,delete type actions. Also the tagTypes here are like groups and you'll need it when you make mutations. We'll see it downwards.

Here you can see there are two interfaces. These are only required for TypeScript projects. You need to specify the types of the parameters and the returns inside the angle brackets.
Now, you might need more the these like you might need to pass your auth token. You just have to configure it inside the baseQuery property. Here's how to do it.

import { createApi, fetchBaseQuery } from '@reduxjs/toolkit/query/react';

interface IReturn {
  key[string]: any;
}

interface IParams {
  key[string]: any;
}

const baseQuery = fetchBaseQuery({
  baseUrl: 'https://baseurl.com',
  prepareHeaders: (headers) => {
  const token = 'token';
    if (token) {
      headers.set('Content-Type', 'application/json');
      headers.set('Authorization', `Bearer ${token}`);
      headers.set('Cookies', token);
    }
    return headers;
  }
});

export const demo = createApi({
  reducerPath: 'demo',
  baseQuery: baseQuery,
  tagTypes: ['tag'],
  endpoints: (builder) => ({
    getSingleData: builder.query<IReturn, IParams>({
      query: ({ slug, id }) => `/${slug}/items/${id}`
    }),
    getAllData: builder.query<IReturn[], IParams>({
      query: ({ slug }) => `/${slug}/items`,
      providesTags: [{ type: 'tag', id: 'LIST' }]
    })
  })
});

We're setting the headers if we find the token. The getAllData seems to be different right? It has an extra configuration providesTags. What is it doing here? Well, it is used to cache the fetched data. So, when you send a request using the same endpoint and the cache hasn't been invalidated, it will return the cache instead. Which saves you from some API calls and makes the UI rendering look instant.
So far we've only seen how we can request queries. Let's configure some methods to make mutations. Create, Update, Delete generally.

export const demo = createApi({
  reducerPath: 'demo',
  baseQuery: baseQuery,
  tagTypes: ['tag'],
  endpoints: (builder) => ({
    getSingleData: builder.query<IReturn, IParams>({
      query: ({ slug, id }) => `/${slug}/items/${id}`
    }),
    getAllData: builder.query<IReturn[], IParams>({
      query: ({ slug }) => `/${slug}/items`,
      providesTags: [{ type: 'tag', id: 'LIST' }]
    }),
    updateItem: builder.mutation<IReturn, IParam>({
      query: ({ slug, id, body }) => {
        return {
          url: `/${slug}/items/${id}`,
          method: 'PATCH',
          body
        };
      },
      invalidatesTags: [{ type: 'tag', id: 'LIST' }]
    }),
    deleteItem: builder.mutation<IReturn, IParams>({
      query: ({ slug, id }) => {
        return {
          url: `${slug}/items/${id}`,
          method: 'DELETE'
        };
      },
      invalidatesTags: [{ type: 'tag', id: 'LIST' }]
    })
  })
});

For mutations, we're writing a bit more code. In the return statement of the query, you need to specify the URL, Method, and Body (optional). Just like in fetch or Axios you pass the endpoint and method and body here. Now, here's an interesting thing. When you make mutations, you're changing the data. So it means that the cache you have currently is old and stores old/wrong values. You need to update it. But first, you have to invalidate it so it can be updated right! To do that, just add an extra property invalidatesTags and add the tags that it belongs to. Also, you don't have to do it in the shown way. You can just add the tags directly inside the array like so,

invalidatesTags: ['tag']

After including this property, whenever you make changes your cached data will be invalidated. Now you might think as your cache was invalidated you need somehow make another request to fetch new data and cache that again. Don't worry. RTK query handles that for you too. Whenever a cache is invalidated it will automatically fetch new data with the method that provides that tag.
Now, will it run every one of them to fetch data? And when will it be executed? It will be executed when going to a page where a query method is implemented and you are fetching data. And all the loading and error handling will happen as the initial fetch.

This far we've only created an API slice. Now, let's see how we can allow our project to use it. To do so we need to wrap our root element with a provider and pass the API slice as a prop. Now here's a thing. RTK suggests you use a single slice for the APIs but you're not bound to do so. If you have a use case where you need to have separate API slices, you can do so. But it requires a bit more configuration. For now, let's just focus on our minimal configuration.

2. Wrap with the provider :

import React from 'react';
import ReactDOM from 'react-dom/client';
import { ApiProvider } from '@reduxjs/toolkit/query/react';
import { demo } from 'store/api/demoSlice';
import Index from 'pages/'

function App() {
  return (
    <ApiProvider api={demo}>
      <Index />
    </ApiProvider>
  );
 }

To provide your slices you just have to import the exported slice from the store and pass it into the ApiProvider as the value of the API prop. For the sake of minimal setup, assuming that you have only one API slice for your whole project. You're done here. Now let's see how we can consume our API methods. Here comes the interesting part.

3. Consuming the API methods.

import { demo } from 'store/api/demoSlice';

function Todos = () => {
const { data, isLoading, error } = demo.useGetAllDataQuery()
const [deleteItem, status] = demo.useDeleteItemMutation()

const handleDelete = async (id) => {
  const res = await deleteItem(id);
};

if(isLoading){
  return <div>Loading. Please wait!</div>
}

if(isError){
  return <div>Sorry! Unable to load data.</div>
}

return (
  <div>
    {data.map(item => {
       return <div key={item.id} onClick={handleDelete}>{item.title}</div>
     })}
  </div>)
}

export default Todos;

Wait! What? Where do these useGetAllDataQuery and useDeleteItemMutation methods come from? The methods we created are different!

Looks different but at the same time similar right? Well, you're right. Cause we did not create these methods but they sound familiar cause these are the ones we created with a bit of tweaking. RTK Query prefixed our methods with the keyword use and postfixed with the type of the method, either Query or Mutation. And to use those methods we need to use them this way.

Now, as you can see I've imported the demo module from demoSlice and used the endpoints. Here, for queries, It returns an object with some props like data, isLoading, isError, error, etc. These props are self-explanatory. To use the data you need to wait until the data is loaded. Till then show a loading message and error message for any kind of error.

For the mutation, you get a tuple in return. The first property is the handler and the second one is the status. You can also show loading states based on the status of the mutation. now you just have to call the handler passing the right param(s). And after the successful execution, the data will get invalidated and fetch new data automatically.

You can also refetch manually. Query methods return a property called refetch. It's a function and you can just call it on a click event may be to refetch. All other methods can be used in the same way.

Now you're ready to jumpstart yourself and go beyond this minimal config.

Few things you should know :

You can make lazy queries. What I mean is that with the way we're consuming the endpoints now, the queries happen on page load automatically. But you might wanna do it only on a certain use case. To do that you can make lazy queries. The code will look like this,

const [ fetchAllData, {data, isLoading, isError} ] = demo.useLazyGetAllDataQuery()

Now just call the fetchData method as/when you please.

You need async await only when a method returns a tuple.
You can cache each element of an array with the same tag type but different IDs like so,

providesTags: (result, error, arg) => result 
? [...result.map(({ id }) => ({ type: 'tag', id })), 'tag'] 
: ['tag']

Invalidating will be similar.

invalidatesTags: (result, error, arg) => [{ type: 'tag', id: arg.id }]

Position props.children in an unique way

Sajjat Hossain — Mon, 23 May 2022 13:23:24 +0000

Recently I faced an interesting issue. I was asked if there's any way to position each children element passed into a children component via wrapping these elements/components using a component. The syntax of the question is as follows,

Let's assume we have a modal component. So, it will be like,

Fig: 1

<Modal>
  <Header />
  <Body />
  <Footer />
</Modal>

Now, the expected output should look similar to this codes' output,
(inside modal component)

Fig: 2

<div>
 <header>
  <Header />
 </header>
 <main>
  <Body />
 </main>
 <footer>
  <Footer />
 </footer>
</div>

Now, here's how I solved the issue,
I did not know how to solve it as I had no experience such like this. But I thought that if I could select them via the index, I could do so. So I spun up a Next.js application and tested my theory later on. And voila! I was right. You can achieve the same output (similar to the Fig: 2) as shown here,

Fig: 3

const Modal = ({children}) => {

 return (
   <div>
    <header>
     { children[0] }
    </header>
    <main>
     { children[1] }
    </main>
    <footer>
     { children[2] }
    </footer>
  </div>
 )
}

similarly:

const Modal = ({children}) => {
/**
* @desc assigning each array element to a variable;
*/
 const [header, body, footer] = children;

 return (
   <div>
    <header>
     { header }
    </header>
    <main>
     { body }
    </main>
    <footer>
     { footer }
    </footer>
  </div>
 )
}

Maybe, it's not the best way to pass an element or achieve such output. But it's an unique way and you never know, there might be an use-case for this. Here's an working demo: Click here!

Should you use useState or useRef?

Sajjat Hossain — Thu, 20 Jan 2022 10:12:22 +0000

useState and useRef both are used to store component state in React. But there is a fundamental difference between them. They work differently.

useState copies the data and returns that data as state. On the other hand useRef stores the reference to that data. For better understanding let's see a simple example of what happens when we assign data to a variable in JavaScript. I found out that these two work exactly the same way (from my experience).

Example 1:

const value1 = [1, 2, 3, 4];
const value2 = value1;

console.log(value1) // [1, 2, 3, 4]
console.log(value2) // [1, 2, 3, 4]
console.log(value1 === value2); // true

Example 2:

const value1 = [1, 2, 3, 4];
const value2 = [1, 2, 3, 4];

console.log(value1) // [1, 2, 3, 4]
console.log(value2) // [1, 2, 3, 4]
console.log(value1 === value2); // false

Take a look at these examples. Two variables output same values but when comparing with each other, the output is different. Why does this happen?

It happens, because in the first case by declaring value1 = value2 we're assigning it a reference to value1. As the value2 is referencing to value1, it's like comparing value1 === value1 which is true cause the memory location is the same. Also in any given point of time, if you change the value of value2 then value1 will be changed too.

But in the second case, we're not referencing any variable to another. Their values are stored in their own memory location.

And while comparing, compilers aren't comparing values, instead comparing memory location. As the location is different, we're getting false as the output.

And this same situation occurs for the useState and the useRef hook.
So, if you need to store data then use useState hook and if you need to store reference to anything in the component, use useRef hook.

Easiest way to store dot files using git!

Sajjat Hossain — Thu, 03 Jun 2021 08:17:04 +0000

I was looking for a long time for a solution that will help me to store my dot files on a git remote repository. I found sylink method but that was a very lengthy process. I had to manually create all sym-links. Which is not that intuative. Then one day i came accross a youtube video by DistroTube, where he explained how we can store our files using git bare repository. I'll try to explain here how to do it and if you wanna check his video I'll leave a link at the bootm.
Here's the process:

Create a bare repository in the home folder :

$ mkdir dotfles
$ git init --bare $HOME/dotfiles

Now run these commands :

$ alias dotfiles='/usr/bin/git --git-dir=$HOME/dotfiles/ --work-tree=$HOME'
$ dotfiles config --local status.showUntrackedFiles no

Note:

The first command will add dotfiles alias to the .bashrc file. So, that we dont have to type the line all the time which is crucial for the process.
The second line will prevent any promt created because of untracked file.

Now you are good to go. You can add files just as you add using git command. Instead use the alias. Just do as shown below :

First let's add the remote repository link (If it's the first push):

$ dotfiles remote add origin <repository_link>

Let's add a file or folder ( first locate the file/folder ) :

$ dotfiles add <pathToTheFile/fileName>
$ dotfiles commit -m "Test Commit"
$ dotfiles push -u origin <branch_name>

Greate! You've seccessfully uploaded your dotfiles to git remote repository. Now when you change anything just add, commit and psuh just as shown.

Link to DistroTube's Video