This repository contains the code and resources used in the experimental research for my thesis: "Comparative Analysis of State Management Libraries in React Applications". The purpose of this study was to evaluate the effectiveness of different state management libraries in a controlled environment.
State management is a crucial aspect of developing React applications. However, research on comparing different state management libraries is limited. This study aims to bridge that gap by comparing various state management libraries based on key metrics: performance, package size, memory consumption, and ecosystem support.
For this purpose, a React e-commerce store was developed using the Saleor API as a back-end. This base application was cloned six times, with each instance utilizing a different state management library, maintaining consistent functionality and experience across all instances.
The findings provide valuable insights and practical recommendations that can help developers choose the most appropriate state management library for their specific project requirements.
The repository is organized as follows:
- /boilerplate: The original React e-commerce application template.
- /redux: The version of the app using Redux for state management.
- /mobx: The version of the app using MobX for state management.
- /useContext: The version of the app using React's Context API.
- /zustand: The version of the app using Zustand for state management.
- /jotai: The version of the app using Jotai for state management.
- /recoil: The version of the app using Recoil for state management.
- /__results__: Contains screenshots from the experiments.
- /thesis.pdf: The full thesis document.
To run the application, you need a running Saleor API. The easiest way to set it up is by using the saleor-platform, a Dockerized package containing the core API, Saleor Dashboard, and other necessary services like the PostgreSQL database. Follow these steps:
-
Clone the
saleor-platformrepository:git clone https://github.com/saleor/saleor-platform cd saleor-platform -
Build the Docker image:
docker-compose build
-
Apply Django migrations:
docker compose run --rm api python3 manage.py migrate
-
Populate the database and create an admin user:
docker compose run --rm api python3 manage.py populatedb --createsuperuser
-
Start the Saleor API:
docker compose up
By default, the GraphQL API will be available at http://localhost:8000/graphql/, and the Saleor Dashboard will be accessible at http://localhost:9000/.
To configure the store for the experiments:
-
Disable Email Confirmation for New Users: For user registration to work without email confirmation, disable this requirement via the Saleor Dashboard:
- Navigate to Configuration → Site settings.
- Uncheck the "Require email confirmation" box.
-
Payment Configuration (Optional): To enable fully functional checkouts, configure a payment application. You can use the
saleor/dummy-payment-appfor this purpose (Dummy Payment App):- Run the app locally and expose it via a tunneling service like
ngrok. - Install the app in the Saleor Dashboard by providing the manifest URL in the format
{tunnel_url}/api/manifest.
- Run the app locally and expose it via a tunneling service like
Once the Saleor API is running, follow these steps to set up and run the React applications:
-
Clone this repository:
git clone https://github.com/Droniu/state-manager-comparison.git cd thesis-state-management-comparison -
Install dependencies for each version (make sure you use Node 20):
cd redux npm installRepeat for the other versions (
mobx,useContext,zustand,jotai,recoil). -
Run the application:
npm run dev
Access the app at
http://localhost:3000. -
If you want to run the application in production mode, or check bundle size:
npm run build npm run preview
The size of each state management library significantly impacts the overall bundle size of the application:
| Library | Library Size (kB) | Project Size (kB) |
|---|---|---|
| Redux | 6200 | 552 |
| MobX | 4718 | 593 |
| Context API | 0 | 533 |
| Zustand | 325 | 538 |
| Jotai | 428 | 537 |
| Recoil | 2210 | 609 |
In terms of performance, measured by Lighthouse scores, there we no differences in TBT (Total Blocking Time) and LCP (Largest Contentful Paint):
| Library | TBT (ms) | LCP (s) |
|---|---|---|
| Redux | 10 | 1.7 |
| MobX | 10 | 1.7 |
| Context API | 10 | 1.7 |
| Zustand | 10 | 1.7 |
| Jotai | 10 | 1.7 |
| Recoil | 10 | 1.7 |
Memory consumption was evaluated on both Safari and Chrome:
| Library | Memory Usage Safari (MB) | Memory Usage Chrome (MB) |
|---|---|---|
| Redux | 21.37 | 7.59 |
| MobX | 23.97 | 7.72 |
| Context API | 23.54 | 8.07 |
| Zustand | 20.18 | 7.71 |
| Jotai | 22.32 | 8.21 |
| Recoil | 22.73 | 7.43 |
Other results, such as state update time, re-renders and library popularity, are detailed in the full thesis document.
Based on the results, here are the recommendations for selecting a state management library:
- Redux: Ideal for developers who prefer a mature, well-tested solution, especially for large-scale applications.
- MobX: Best suited for those who favor object-oriented programming and class-based syntax.
- Context API: Recommended for small to moderate-sized applications focusing on minimal bundle size.
- Zustand: A good choice for simplicity and a balance between popularity and maturity while also minimizing bundle size.
- Jotai: Excellent for performance-oriented applications with a need for small bundle sizes and for developers exploring new solutions.
- Recoil: Not recommended due to lack of maintenance. Consider Jotai for a similar experience with better performance.
This project is licensed under the MIT License - see the LICENSE file for details.
- Michał Droń - Droniu
- Special thanks to my thesis advisor dr inż. Tomasz Szandała thanks to whom this project went seamlessly.
- Thanks to WUST for providing the opportunity to conduct this research.
- Thanks to the Saleor team for developing the amazing API used in this project.
- Thanks to all the contributors of the state management libraries evaluated in this study.