When writing modern React applications, you’ll frequently see developers using the const keyword in their code. At first glance, it might look like just another way to declare variables, but in practice, const plays an important role in maintaining clean, predictable, and bug-free React projects. In this article, we’ll break down what const really means, why it matters in React, and how you can use it effectively to write better code.

What Does const Really Mean in JavaScript?

Before we talk about React, it’s important to revisit what const means in JavaScript itself. Many developers mistakenly believe that const makes values completely unchangeable. The reality is a bit more subtle and worth understanding fully before applying it in React.

The Basics of const

• Constant bindings, not values: const prevents reassignment of a variable’s identifier, but it does not make the actual value immutable.
• Block-scoped: Variables declared with const are confined to the block in which they are declared, unlike var which is function-scoped.
• Initialization required: You cannot declare a const variable without assigning a value.

Behavior with Different Data Types

• Primitives (string, number, boolean, null, undefined, bigint, symbol): Once assigned, these cannot be changed.

const language = “JavaScript”;

// language = “TypeScript”; ❌ Error

• Reference Types (objects, arrays, functions): The reference itself cannot be reassigned, but internal properties or items can be modified.

const user = { name: “Ana” };

user.name = “Maria”; // ✅ allowed

// user = { name: “Lia” }; ❌ not allowed

This distinction is especially important in React, where state and props often involve objects and arrays. Knowing that const doesn’t freeze the content helps avoid confusion when updating state immutably.

How const Differs from let and var

Here’s a comparison table to clarify:

Feature	var	let	const
Scope	Function	Block	Block
Hoisted	Yes (initialized as undefined)	No	No
Reassignment Allowed	Yes	Yes	No
Redeclaration Allowed	Yes	No	No
Initialization Required	No	No	Yes

Understanding these mechanics ensures React developers avoid subtle bugs that arise when using the wrong declaration keyword.

Why This Matters for React Developers

React relies heavily on immutability for state management. If you misunderstand const and mutate objects or arrays incorrectly, React may not recognize changes and fail to re-render. For example, mutating a state object declared with const directly will not trigger React’s reconciliation properly.

Key takeaway: const does not make values truly immutable—it locks the binding, not the content. In React, this distinction is crucial for working correctly with state and props.

Why const Is the Default Choice in Modern React Code

Now that we’ve covered the mechanics of const, let’s look at why modern React developers default to using it in most scenarios.

Emphasis on Predictability

React thrives on predictable state and component behavior. Declaring variables with const signals that the identifier will not change, which reduces confusion and unexpected reassignments in complex apps.

Readability and Clarity

When reading code, const immediately communicates intent. Another developer reviewing your code knows at a glance that the variable should remain fixed. This small signal has a large impact on teamwork, especially in large codebases where many contributors are working together.

ESLint and Style Guides

Popular linting tools and JavaScript style guides (such as Airbnb’s) recommend using const by default. ESLint even has a rule—prefer-const—that automatically flags variables that can be const but are declared with let. This enforces consistency and reduces bugs caused by unintended reassignment.

Comparison in React Context

Here’s how each keyword typically applies in React projects:

• var: Almost never used. It introduces hoisting and function-scoping, which can cause unexpected bugs.
• let: Occasionally used in loops or when the variable value must be reassigned (like iterating through arrays or toggling conditions inside a function).
• const: The standard for declaring React components, hooks, utility functions, and most values that don’t require reassignment.

Example of Best Practice

// Recommended

const Header = () => <h1>Welcome</h1>;

// With hooks

const [theme, setTheme] = useState(“light”);

Using const for both the component and the state declaration makes the intent crystal clear.

Key takeaway: const is favored in React because it communicates intent, enforces predictability, and aligns with modern style guides that help maintain consistency in large projects.

Using const with React Components and Hooks

In React, const is deeply tied to how we write both components and hooks. Understanding this relationship ensures code that is both idiomatic and maintainable.

Functional Components

Most modern React apps are built with functional components instead of class components. By declaring these components with const, you ensure that the function reference itself cannot be reassigned:

const Navbar = () => {

return <nav>Home | About | Contact</nav>;

};

This not only makes the component definition consistent but also prevents accidental reassignments later in the file.

Hooks and State Management

Hooks like useState, useReducer, and useEffect are always declared with const:

const [count, setCount] = useState(0);

Even though count changes as the user interacts, the variable binding stays constant. React manages updates internally while const ensures the developer cannot reassign count directly, forcing updates through React’s state mechanism.

Utility Functions and Helpers

Often, developers define helper functions or constants alongside their components:

const formatCurrency = (value) => `$${value.toFixed(2)}`;

This makes the code easier to test, reuse, and understand.

Example: Combining Concepts

const Counter = () => {

const [count, setCount] = useState(0);

const increment = () => setCount(count + 1);

return (

<div>

<p>{count}</p>

<button onClick={increment}>Add</button>

</div>

);

};

Here, const is used consistently for the component, state variables, and helper functions. This pattern is standard across professional React projects.

Key takeaway: const is essential in React’s functional paradigm. It guarantees stability for components, hooks, and helpers while aligning with React’s declarative design.

Common Mistakes Developers Make with const in React

While const is powerful, misusing it can lead to confusion and bugs. Recognizing these pitfalls early makes code more reliable.

Misunderstanding Immutability

One of the biggest misconceptions is believing const makes objects or arrays immutable. In reality, you can still mutate them:

const arr = [1, 2];

arr.push(3); // ✅ Works

To achieve immutability, you must use spread syntax, Object.freeze(), or libraries like Immer.

Overusing const

Not every variable should be const. For example, loop counters work best with let:

for (let i = 0; i < 5; i++) {

console.log(i);

}

Using const here would be invalid since reassignment is required.

Incorrect State Updates

React relies on immutability for detecting changes. Mutating a state object—even if declared with const—does not notify React:

// ❌ Wrong

user.name = “Updated”;

// ✅ Correct

setUser({ …user, name: “Updated” });

Declaring Variables Too Early

Another mistake is declaring a const variable before knowing if it will be used, which clutters code and reduces readability.

Key takeaway: Misusing const often stems from misunderstanding its limits. Developers should remember that it prevents reassignment but not mutation, and apply it thoughtfully.

Best Practices: Writing Clean and Maintainable React Code with const

To maximize the benefits of const, developers should adopt practices that improve readability, maintainability, and alignment with React’s design.

Use const by Default

Start with const for all variables, only switching to let if reassignment is necessary. This reduces mental overhead and enforces stable code patterns.

Combine with Immutability Principles

Since const alone doesn’t guarantee immutability, pair it with immutable updates when managing state. For example, always use spread operators or immutability helpers when modifying arrays and objects.

const updatedTodos = […todos, newTodo];

Maintain Consistency in Components

Declare all components and hooks with const. This improves readability and ensures predictability across the codebase.

Document Intent with const

Using const communicates to your team that the variable should remain unchanged. This implicit documentation reduces errors when multiple developers work on the same project.

Best Practices Checklist

• Default to const
• Use let only when reassignment is required
• Never use var in React code
• Apply immutability patterns for objects and arrays
• Keep const declarations close to where they’re used

Key takeaway: Adopting consistent const usage across a React project leads to cleaner, more maintainable codebases that scale well with teams and complexity.

Conclusion

The const keyword may seem small, but it has a big impact on how you write and maintain React applications. By understanding its true behavior, using it consistently, and avoiding common mistakes, you’ll write code that’s easier to debug, collaborate on, and scale. In short, const isn’t just a keyword—it’s a mindset that supports the declarative, predictable nature of React.

FAQs

Does const make objects immutable in React?

No. const prevents reassignment but doesn’t stop mutation of objects or arrays.

Can I use let instead of const in React?

Yes, but only when reassignment is required. By default, const is recommended.

Why shouldn’t I use var in React code?

Because var introduces function scope and hoisting, leading to unpredictable behavior.

Is const faster than let or var?

Performance differences are negligible. The choice is more about readability and predictability.

Should I declare React components with const?

Yes. Defining components as const ensures they can’t be accidentally reassigned, improving code clarity.

If you’re working on a React project and encounter the dreaded “Can’t Resolve ‘fs’” error, you’re not alone. This is a common issue faced by developers when libraries or code written for Node.js find their way into a browser-based React app. Since React runs on the client side, it doesn’t support certain Node.js modules like fs, leading to build failures or runtime errors.

This guide will help you understand why the error occurs, explore common scenarios, look at quick fixes, and offer preventive best practices. By the end, you’ll know exactly how to troubleshoot and avoid this frustrating error.

Understanding the “Can’t Resolve ‘fs’” Error in ReactJS

What the Error Really Means

The error message “Can’t Resolve ‘fs’” means that your React app is attempting to import or require the fs module. The fs module is a Node.js core module used to interact with the file system—reading, writing, creating, and deleting files. Since browsers cannot access the local file system directly for security reasons, they have no idea how to handle fs.

When bundlers like Webpack or Vite prepare your React code for the browser, they come across a reference to fs and fail to resolve it because the module doesn’t exist in that environment. This results in a compile-time error that halts your build.

Why This Happens Specifically in React

React itself doesn’t use fs—the error usually comes from either:

• Your codebase, if you accidentally import Node.js APIs into client components.
• Third-party libraries, which may be designed for Node.js but mistakenly installed into a React app.

React, being a frontend framework, expects all code to be compatible with the browser runtime. So any server-side module like fs becomes a mismatch.

Example Error Trace

You might see something like this in your terminal:

Module not found: Error: Can’t resolve ‘fs’ in ‘/project-path/node_modules/library-name’

This tells you that the library library-name is trying to use fs, which causes the bundler to fail.

Why This Error is Important to Fix Quickly

If not addressed, this error will prevent your React app from running altogether. Unlike small warnings, this is a hard error that breaks your build.

Key takeaway: The “Can’t Resolve ‘fs’” error happens because React is a browser-based framework, while fs is a Node.js module that only works on the server side.

Why Node’s fs Module Doesn’t Work in the Browser

Node.js vs. Browser Environments

To understand this error fully, you need to recognize the difference between Node.js and browsers:

Feature	Node.js	Browser
File System Access	Full access via fs	No direct access for security
Runtime	Server-side	Client-side
Modules	Built-in core modules like fs, path, http	DOM APIs, fetch, localStorage
Use Case	Backend development	Frontend development

Browsers intentionally restrict direct file system access. Imagine if a website could read and modify files on your hard drive without permission—it would be a massive security risk. That’s why APIs like fs don’t exist in browsers.

Bundler Limitations

Webpack, Vite, and other bundlers are smart, but they can’t magically translate Node.js-only modules into browser-compatible ones. Some bundlers allow fallbacks, where a missing module can be replaced or ignored. But by default, if a React app tries to import fs, the bundler has no idea what to do.

Security and Performance Considerations

Even if you could somehow enable fs in the browser, it would break essential web security principles. Browsers must isolate websites from a user’s machine to prevent malware and exploits. Additionally, file system operations are resource-intensive and not designed for client-side environments.

Common Misunderstanding

Developers coming from a Node.js background sometimes expect that if code works in Node, it should also work in React. Unfortunately, that’s not true—React is strictly frontend, and importing server-only modules like fs will always fail.

Key takeaway: The fs module works only in Node.js because browsers are sandboxed and cannot access local files directly, making it impossible for React to resolve fs.

Common Scenarios That Trigger the Error

Installing Node-Centric Libraries

One of the most common causes of the error is installing an npm package that assumes access to Node.js. For example:

• Markdown parsers that load files using fs
• PDF or image generators that write files locally
• Tools built for CLI applications

When these libraries are used in React, they attempt to call fs, which doesn’t exist.

Copy-Pasting Backend Code

Another frequent mistake is mixing backend and frontend code. A developer might copy utility functions from an Express backend project into a React component, forgetting that those functions use fs. This inevitably causes build errors.

Misconfigured Bundlers

Sometimes the issue isn’t your code, but how your project is configured. If Webpack or Vite is not set up correctly, they may attempt to bundle server-side code into your client build, leading to fs errors.

SSR Framework Issues

In frameworks like Next.js or Remix, which combine server and client code, it’s easy to accidentally expose server-side logic (with fs) to the client. This often happens when developers import server utilities directly into components.

Summary List of Triggers

• Node.js-only libraries included in React
• Backend code mistakenly copied into frontend
• Webpack/Vite misconfiguration
• Server-side code bleeding into client bundle

Key takeaway: The error is usually caused by importing Node.js-specific code or libraries into React, often due to dependency choices, code mixing, or misconfiguration.

Quick Fixes and Workarounds You Can Try Immediately

Step-by-Step Fixes

Here are practical solutions you can apply right away:

• Remove fs from React code
• Check your components and ensure fs isn’t being imported.
• Move file-related logic to the backend.
• Audit dependencies
• Run npm ls fs or check the error stack trace.
• Replace Node-only libraries with browser-compatible ones.
• Configure bundler fallbacks

In Webpack, add this:

resolve: {

fallback: {

fs: false

}

}

This tells Webpack to ignore fs so your build won’t fail.

• Use backend APIs for file operations
• Example: Instead of reading a file with fs, create an Express route that reads the file and serves it via an API.
• Fetch that data from React using fetch().
• Use browser-native APIs
• For file uploads: use the File API or FileReader.
• For local persistence: use localStorage or IndexedDB.

Example Replacement

If you’re trying to read a file uploaded by the user:

const fileInput = document.querySelector(‘input[type=”file”]’);

fileInput.addEventListener(‘change’, (event) => {

const file = event.target.files[0];

const reader = new FileReader();

reader.onload = (e) => {

console.log(e.target.result);

};

reader.readAsText(file);

});

This replaces what many developers attempt to do with fs.readFileSync().

Key takeaway: The fastest way to fix the error is to either remove fs from frontend code, configure bundlers to ignore it, or shift file-related logic to backend APIs and browser-friendly alternatives.

Best Practices to Prevent “Can’t Resolve ‘fs’” in the Future

Separate Client and Server Logic

Clearly define what belongs on the client (UI, rendering, interactivity) and what belongs on the server (file system, databases, authentication). Never let server modules leak into your React code.

Audit Dependencies Carefully

Before installing a library, check:

• Does it mention browser support in its documentation?
• Are there alternatives designed for frontend apps?

Use Environment Conditionals

Sometimes, you may need to conditionally import code:

if (typeof window === ‘undefined’) {

const fs = require(‘fs’);

}

This ensures that fs is only used in Node environments.

Stick to Modern Libraries

Modern React-focused libraries avoid Node.js dependencies. For example, use browser-compatible parsers instead of ones designed for CLI tools.

Team Documentation

If you’re working in a team, maintain a document that lists:

• Safe-to-use frontend libraries
• Backend-only utilities
• Config rules for bundlers

Prevention Checklist

• Never import fs in React components
• Verify all libraries for browser support
• Separate frontend and backend utilities
• Use conditional imports for Node modules
• Regularly audit npm dependencies

Key takeaway: Prevention is better than cure—by separating client/server code, auditing libraries, and enforcing good coding practices, you can avoid ever seeing the fs error again.

Conclusion

The “Can’t Resolve ‘fs’” error in ReactJS is a sign that server-side Node.js logic has slipped into the browser-based world of React. While frustrating, the fixes are straightforward once you understand the root cause. By removing or replacing fs, adjusting bundler settings, or restructuring your code, you can resolve the error quickly.

Always remember that fs belongs to Node.js, not the browser. Keep server-side logic on the backend, and use browser APIs or backend APIs in React to ensure smooth builds.

FAQs

Can I use fs in React directly?

No. Since React runs in the browser, it cannot use Node’s fs module.

Why does a library I installed trigger this error?

Some libraries are built for Node.js and rely on fs. They won’t work in a browser environment without modification.

How do I know which dependency is causing the issue?

Check the error stack trace—it usually points to the exact file or package.

Is there a polyfill for fs in React?

You can configure Webpack or Vite to ignore fs, but true file access isn’t possible in browsers.

What’s the best alternative to fs for React?

Use browser APIs like FileReader, Blob, or call backend APIs that handle fs operations.

Additional Resources

Introduction

If you’re new to ReactJS, you’ve probably come across terms like promises, asynchronous functions, and API calls. These concepts might sound intimidating at first, but they’re essential to building modern, interactive web applications. In React, data doesn’t always come instantly—sometimes you need to wait for an external resource, like fetching user data from a server. This is where promises come in.

In this guide, we’ll break down what promises are, how they work in React, and how you can use them effectively. By the end, you’ll not only understand promises conceptually but also feel confident implementing them in your own React projects.

What Are Promises and Why Do They Matter in ReactJS?

At their simplest, promises are objects that represent a value that may be available now, in the future, or never. They are the JavaScript language’s built-in solution for managing asynchronous operations in a more structured way compared to callbacks.

When working in React, asynchronous operations happen all the time—fetching data from APIs, submitting forms, validating inputs, or even loading resources like images. Without promises, managing all of these asynchronous tasks would quickly devolve into deeply nested and difficult-to-maintain code, often called “callback hell.”

Why React Developers Rely on Promises

React is designed around building interactive, state-driven user interfaces. Since the UI must stay responsive, React cannot afford to “pause” execution while waiting for tasks like fetching data. Instead, promises allow React to delegate asynchronous operations without freezing the app.

Common scenarios where promises are critical in React include:

• Fetching API data: Pulling user information, blog posts, or e-commerce products.
• Authentication checks: Verifying a user’s identity before rendering protected routes.
• Delayed computations: Running background tasks while keeping the UI active.
• Integration with external libraries: Many React-compatible tools, like Axios or Firebase, use promises under the hood.

Example: The Basics of a Promise

Here’s a simple JavaScript example to visualize how promises work:

const myPromise = new Promise((resolve, reject) => {

let success = true;

if (success) {

resolve(“Task completed successfully!”);

} else {

reject(“Something went wrong!”);

}

});

myPromise

.then(response => console.log(response))

.catch(error => console.error(error));

What’s happening here:

• resolve moves the promise into a fulfilled state.
• reject moves it into a rejected state.
• .then() handles the success path.
• .catch() handles errors.

This structure is exactly what you’ll see in React components when fetching or processing data.

How Promises Compare to Callbacks

To highlight why promises matter, consider the difference:

Aspect	Callbacks	Promises
Code readability	Nested and messy (callback hell)	Cleaner and chainable
Error handling	Scattered across multiple functions	Centralized with .catch()
Flow control	Hard to follow	Easy to sequence operations

React’s ecosystem favors promises because they align with clean code principles, especially as apps scale in complexity.

Key takeaway: Promises are essential in ReactJS because they provide a clean, efficient way to manage asynchronous tasks, ensuring your app remains interactive and user-friendly:

Breaking Down Promise States: Pending, Fulfilled, and Rejected

Understanding the states of a promise is crucial because React components must respond to these states in order to deliver a seamless user experience. Promises don’t just return results instantly—they go through a lifecycle that determines how your app should react at each stage.

The Three States of a Promise

A promise can exist in only one of three states:

• Pending – The initial state when the asynchronous task has started but isn’t finished yet.
• Fulfilled (Resolved) – The task finished successfully, and the promise now has a value.
• Rejected – The task failed, and the promise has a reason for the failure (an error).

Think of these states like tracking a package:

• Pending → The package is in transit.
• Fulfilled → The package has arrived.
• Rejected → The package was lost or couldn’t be delivered.

Practical Example in React

React apps often use fetch() for API calls, which return promises. Here’s how the states play out:

useEffect(() => {

fetch(“https://jsonplaceholder.typicode.com/posts”)

.then(response => response.json())

.then(data => {

console.log(“Data received:”, data); // Fulfilled

})

.catch(error => {

console.error(“Error fetching data:”, error); // Rejected

});

}, []);

• Pending: The request has been sent but no response received yet.
• Fulfilled: The API responded, and the data is available.
• Rejected: Something went wrong—network error, bad endpoint, or server failure.

Handling States in the UI

React developers typically represent promise states with loading, success, and error UI states.

For example:

• While pending → show a loading spinner.
• When fulfilled → render the fetched data.
• When rejected → show an error message.

Here’s a simplified snippet:

if (loading) return <p>Loading…</p>;

if (error) return <p>Something went wrong!</p>;

return <DataComponent data={data} />;

Why States Improve User Experience

By explicitly handling promise states, you provide feedback instead of leaving users wondering what’s happening. This builds trust in your app and makes it feel responsive.

Key takeaway: Promise states—pending, fulfilled, and rejected—are the foundation for building responsive UIs in React, ensuring users always know what’s happening in the background:

Using Promises in React: Practical Examples with fetch()

The fetch() function is the most common way developers interact with promises in React. Since React apps often pull in external data, you’ll likely use fetch() almost daily. It returns a promise that resolves to the response of the request.

A Practical User List Example

Here’s how you might fetch and render a list of users:

import React, { useState, useEffect } from “react”;

function UserList() {

const [users, setUsers] = useState([]);

const [loading, setLoading] = useState(true);

const [error, setError] = useState(null);

useEffect(() => {

fetch(“https://jsonplaceholder.typicode.com/users”)

.then(response => response.json())

.then(data => {

setUsers(data);

setLoading(false);

})

.catch(error => {

setError(error);

setLoading(false);

});

}, []);

if (loading) return <p>Loading…</p>;

if (error) return <p>Error loading users: {error.message}</p>;

return (

<ul>

{users.map(user => (

<li key={user.id}>{user.name}</li>

))}

</ul>

);

}

export default UserList;

This example demonstrates:

• Pending state: The app shows “Loading…” while the data is being fetched.
• Fulfilled state: The user list is displayed once data arrives.
• Rejected state: An error message is displayed if the request fails.

Why This Matters in Real Apps

Without handling promise states properly, your React app might:

• Appear frozen while fetching data.
• Fail silently without letting users know why.
• Crash due to unhandled errors.

By combining promises with state management (useState and useEffect), you create a robust flow that accounts for success, failure, and waiting periods.

Key takeaway: Using promises with fetch() ensures React apps remain reliable, user-friendly, and responsive to real-world conditions like slow networks or failed requests:

Handling Errors Gracefully with Promises in React

Errors are a natural part of web development. Network outages, server downtime, invalid endpoints, or user mistakes can all lead to failed promises. If these aren’t handled gracefully, users may encounter broken UIs or silent failures.

Error Handling with .catch()

The simplest way to handle errors is to attach a .catch() to your promise chain:

fetch(“https://invalid-api-endpoint.com/data”)

.then(response => response.json())

.catch(error => {

console.error(“Oops! Something went wrong:”, error);

});

This prevents the app from crashing and allows you to log or display user-friendly feedback.

Best Practices for Error Handling in React

• Show meaningful error messages → Instead of technical jargon, display helpful instructions like “Unable to load data. Please check your internet connection.”
• Fallback UIs → Provide an alternative, such as cached content, placeholders, or a retry button.
• Retry strategies → Attempt the request again after a delay when errors might be temporary.
• Error Boundaries → React components that catch errors and prevent them from breaking the entire app tree.

Here’s a simple error boundary:

class ErrorBoundary extends React.Component {

constructor(props) {

super(props);

this.state = { hasError: false };

}

static getDerivedStateFromError(error) {

return { hasError: true };

}

render() {

if (this.state.hasError) {

return <h2>Something went wrong. Please try again later.</h2>;

}

return this.props.children;

}

}

Wrap components inside <ErrorBoundary> to prevent complete failure when errors occur.

Why This Matters for UX

Poorly handled errors frustrate users and create distrust. Well-handled errors, on the other hand, reassure users that your app is reliable even in unpredictable conditions.

Key takeaway: Graceful error handling with promises improves both technical stability and user experience, keeping apps trustworthy and resilient even when failures occur:

Promises vs. Async/Await in React: Which One Should You Use?

Both promises with .then/.catch and async/await achieve the same goal: handling asynchronous operations. But they differ in readability, maintainability, and developer preference.

Using Promises (.then/.catch)

fetch(“https://jsonplaceholder.typicode.com/posts”)

.then(response => response.json())

.then(data => console.log(data))

.catch(error => console.error(error));

Advantages:

• Straightforward for simple operations.
• Easy to chain multiple asynchronous steps.
• Familiar to many developers.

Drawbacks:

• Becomes messy with deeply nested chains.
• Harder to read when multiple .then() calls are involved.

Using Async/Await

async function fetchPosts() {

try {

const response = await fetch(“https://jsonplaceholder.typicode.com/posts”);

const data = await response.json();

console.log(data);

} catch (error) {

console.error(“Error fetching posts:”, error);

}

}

Advantages:

• Cleaner and more readable.
• Easier to write synchronous-looking code for async operations.
• Simplifies error handling with try/catch blocks.

Drawbacks:

• Requires an async wrapper (e.g., inside useEffect, you can’t directly use async).
• Slightly less explicit when chaining multiple promises.

Comparison Table

Aspect	Promises (.then/.catch)	Async/Await
Readability	Can get messy with chains	Clean and synchronous-looking
Error Handling	.catch() blocks	try/catch blocks
Best For	Simple, single operations	Complex async workflows

In React with useEffect

Since useEffect can’t directly be async, you often define an async function inside it:

useEffect(() => {

async function loadData() {

try {

const response = await fetch(“https://jsonplaceholder.typicode.com/users”);

const data = await response.json();

console.log(data);

} catch (error) {

console.error(error);

}

}

loadData();

}, []);

Key takeaway: Both approaches work in React, but async/await usually provides cleaner, more maintainable code for real-world applications:

Conclusion

Promises are the backbone of handling asynchronous operations in ReactJS. By understanding how they work, their states, and how to manage errors, you can build apps that feel fast, reliable, and user-friendly. Whether you stick with .then/.catch or embrace async/await, promises will always be at the heart of modern React development.

FAQs

Are promises unique to ReactJS?

No, promises are a JavaScript feature. React just leverages them heavily because of its reliance on asynchronous tasks.

Can I use async/await inside useEffect directly?

Not directly, but you can define an async function inside useEffect and call it.

Do promises replace callbacks?

Yes, promises were introduced to solve “callback hell” and make asynchronous code easier to manage.

What happens if I don’t handle promise errors?

Uncaught promise rejections can cause runtime errors and break app functionality.

Is it better to use a library like Axios instead of fetch?

Axios simplifies API calls with features like automatic JSON parsing and better error handling, but both fetch and Axios work well with promises.

Additional Resources

One of the most popular techniques for managing authentication in contemporary ReactJS apps is the use of JSON Web Tokens (JWTs). But one question consistently puzzles developers: where should JWTs be stored to ensure both functionality and security? Storing tokens incorrectly can expose your app to attacks such as XSS (Cross-Site Scripting) or CSRF (Cross-Site Request Forgery). In this article, we’ll take a deep dive into different storage methods, best practices, as well as typical blunders to steer clear of, so you may make wise choices for your ReactJS applications.

Why JWT Storage Matters in ReactJS Applications

Before deciding where to store JWTs, it’s essential to understand why the choice of storage matters. A JWT is not just a piece of data—it’s the equivalent of a digital passport that grants users access to protected resources. If an attacker obtains a valid JWT, they can impersonate the user until the token expires or is revoked.

How JWTs Work in Authentication

• When a user logs in, the backend verifies their credentials and issues a JWT.
• The client (React app) stores this token for use in subsequent requests.
• Every API call to protected routes must include the token for verification.
• The backend checks the token’s validity (signature, issuer, and expiration).

This flow makes JWTs powerful but also sensitive. If stolen, they become an attacker’s ticket into your system.

Why ReactJS Developers Face Unique Risks

ReactJS is frequently used to build Single Page Applications (SPAs). Unlike traditional server-rendered apps, SPAs rely heavily on client-side logic to manage user state and interactions. Because of this, storage often shifts to the client-side, where attackers can exploit security flaws more easily.

Some factors that increase risk in ReactJS apps include:

• Heavy reliance on APIs for backend communication
• Frequent use of localStorage and sessionStorage for simplicity
• High exposure to client-side vulnerabilities like XSS
• Complex authentication flows that include refresh tokens and rotation

What Happens If JWTs Are Mismanaged?

If JWTs are stored in an insecure location, attackers can:

• Steal tokens through XSS: Injected scripts can read tokens stored in localStorage or sessionStorage.
• Hijack sessions: Attackers can impersonate users until token expiration.
• Perform privilege escalation: If an admin token is stolen, the entire system could be compromised.
• Exploit APIs: Since JWTs are sent with each request, stolen tokens provide direct backend access.

Security Principles That Apply to JWT Storage

• Confidentiality: Tokens must not be exposed to JavaScript unnecessarily.
• Integrity: Tokens should not be modifiable by the client.
• Expiration: Tokens must expire quickly to limit damage if stolen.
• Least Privilege: Tokens should carry minimal claims and permissions.

Key Takeaway: Storing JWTs securely in ReactJS isn’t just a best practice—it’s a necessity. Poor storage decisions expose your application to attacks, compromise user trust, and put sensitive data at risk. Treat tokens as sensitive credentials and apply strict security principles from the start.

Local Storage vs. Session Storage: Pros and Cons

When working with ReactJS, many developers default to browser storage solutions such as localStorage and sessionStorage. Both are easy to use and widely documented, making them tempting options for JWT storage. However, security is frequently sacrificed for convenience. Let’s examine their pros, cons, and practical use cases.

Local Storage

LocalStorage allows you to persist key-value pairs across browser sessions. Developers often store JWTs here because they keep users logged in even after the browser is closed and reopened.

Pros of Local Storage:

• Persistent storage across sessions
• Easy implementation (localStorage.setItem(“token”, jwt))
• Good for “remember me” functionality

Cons of Local Storage:

• Vulnerable to XSS attacks (JavaScript can read it)
• No built-in expiration handling
• Requires manual cleanup at logout
• If stolen, attackers gain long-term access

Session Storage

SessionStorage is similar to localStorage but with one key difference—it only persists for the duration of the browser session (or tab).

Pros of Session Storage:

• Auto-clears when the tab or browser is closed
• Useful for temporary authentication
• Prevents lingering tokens after logout if the tab is closed

Cons of Session Storage:

• Still vulnerable to XSS attacks
• No built-in encryption
• Can persist across duplicated tabs in some browsers

Comparison Table

Feature	Local Storage	Session Storage
Persistence	Survives refresh/close	Ends when tab/browser closes
XSS Vulnerability	High	High
Expiration	None	Session only
Convenience	High	Moderate
Security Level	Low	Low

Why Both Should Be Avoided in Production

Although these methods are straightforward, they provide no real protection against XSS. If an attacker injects malicious JavaScript into your React application, they can easily access and exfiltrate sensitive tokens. For sensitive apps, these methods are not recommended.

Key Takeaway: While localStorage and sessionStorage may seem convenient, they are not secure for JWT storage in production. Their accessibility to JavaScript makes them prime targets for XSS attacks. Consider them only for prototyping or non-sensitive apps, but never for production-grade authentication.

Using HttpOnly Cookies for JWTs: The Safer Approach

Cookies have been around since the early days of the web, but their security features make them particularly suitable for JWT storage. By using HttpOnly cookies, you can significantly reduce risks associated with client-side token exposure.

What Are HttpOnly Cookies?

• HttpOnly flag: Prevents JavaScript from accessing the cookie.
• Secure flag: Ensures cookies are transmitted only over HTTPS.
• SameSite attribute: Controls whether cookies are sent on cross-site requests (helpful against CSRF).

Advantages of HttpOnly Cookies

• Tokens are not accessible via document.cookie or any JavaScript API
• Requests automatically include cookies, simplifying authentication
• Works well with short-lived tokens and refresh token strategies

Limitations and Challenges

• Cookies can still be vulnerable to CSRF if improperly configured
• Slightly more complex backend setup compared to localStorage
• Some developers find cookie handling less transparent than JavaScript-based storage

How to Implement Securely

• Server sends JWT in a Set-Cookie header with HttpOnly, Secure, and SameSite flags.
• ReactJS frontend makes API calls with { credentials: “include” }.
• Implement CSRF defenses such as CSRF tokens or double-submit cookies.

Axios Example

axios.get(“/api/profile”, { withCredentials: true })

.then(res => console.log(res.data));

Best Practices with Cookies

• Use short-lived access tokens stored in memory only
• Use HttpOnly cookies for refresh tokens
• Rotate refresh tokens frequently
• Always enforce HTTPS

Key Takeaway: HttpOnly cookies are the recommended approach for JWT storage in ReactJS because they prevent direct JavaScript access, drastically reducing the risk of token theft via XSS. When combined with CSRF protection, they offer a robust and secure solution for production environments.

Practical Secure Storage Strategies in ReactJS

Choosing where to store JWTs is only one piece of the puzzle. True security in ReactJS requires a multi-layered strategy that considers token lifespan, refresh mechanics, and backend validation.

Best Practices to Strengthen JWT Security

• Use short-lived access tokens (e.g., 10–15 minutes) to minimize exposure if stolen
• Store refresh tokens in HttpOnly cookies, not in localStorage or sessionStorage
• Rotate tokens: issue a new refresh token whenever a new access token is requested
• Add CSRF protection: leverage SameSite cookies, CSRF tokens, or double-submit cookie techniques
• Validate tokens on the backend: check signatures and expiration for every request
• Force logout on suspicious activity: revoke tokens or invalidate sessions quickly
• Always use HTTPS: insecure connections expose tokens during transmission

Example Authentication Flow

Step	Action	Storage
1	User logs in	Server issues short-lived access token + refresh token in HttpOnly cookie
2	Client uses an access token for API requests	Stored in memory only
3	Access token expires	Client uses a refresh cookie to get a new access token
4	Refresh token rotation	New refresh cookie replaces the old one
5	Logout	Refresh token cookie cleared, access token discarded

This hybrid approach ensures tokens are never persistently stored in insecure places.

Key Takeaway: Secure JWT storage in ReactJS requires more than just picking a storage mechanism—it demands a layered approach. By combining HttpOnly cookies, short-lived access tokens, rotation, and CSRF defenses, you can build a resilient authentication system.

Common Mistakes to Avoid When Storing JWTs

Even with best practices available, developers often make critical errors in how they store and handle JWTs. Awareness of these mistakes can help you avoid costly vulnerabilities.

Frequent Mistakes

• Storing tokens in localStorage or sessionStorage: Easy but insecure
• Exposing tokens in JavaScript: Allows XSS attacks to steal them
• Skipping CSRF protection: Cookies without CSRF safeguards are vulnerable
• Using long-lived tokens: Increases risk if stolen
• Not rotating refresh tokens: Allows attackers to reuse old tokens indefinitely
• Trusting tokens without validation: Tokens should always be verified on the server
• Including tokens in URLs: They can appear in logs, referrers, or browser history
• Failing to revoke tokens at logout: Leaves valid tokens active

Better Alternatives

• Store refresh tokens securely in HttpOnly cookies
• Keep access tokens short-lived and in memory only
• Use server-side invalidation and token blacklists
• Implement robust monitoring and logging for suspicious token usage

Key Takeaway: Many JWT-related vulnerabilities stem from careless storage or poor token management. Avoiding these mistakes and adopting disciplined storage practices helps ensure your ReactJS application remains secure against common attack vectors.

Conclusion

JWTs are a powerful way to handle authentication in ReactJS, but storing them improperly can expose your entire application to attacks. While localStorage and sessionStorage are convenient, they come with high risks. The recommended approach is to use HttpOnly cookies, combined with short-lived access tokens, refresh strategies, and strict security configurations. By following best practices and avoiding common mistakes, you can ensure JWT storage remains both functional and secure in your React apps.

FAQs

Can I store JWTs in localStorage if my app isn’t sensitive?

Technically, yes, but even small apps can be targeted. It’s safer to follow best practices regardless of app size.

Are HttpOnly cookies enough on their own?

They reduce XSS risks, but you still need CSRF protection and HTTPS.

Should I store access tokens in memory instead of storage?

Yes, for short-lived tokens, keeping them in memory only (not persistent) is a secure choice.

How often should I rotate refresh tokens?

Ideally, every time a new access token is issued. Rotation limits token reuse.

Do JWTs replace sessions completely?

Not always. JWTs can be stateless, but some apps still use sessions for added security and control.

Since its open-source debut in 2013, ReactJS has grown from a controversial experiment into a cornerstone of modern web development. Created by Facebook to address the challenges of building large-scale, interactive user interfaces, React has redefined how developers think about performance, state management, and scalability.

This article traces React’s evolution through its key milestones, highlighting not only major version releases but also the ecosystem and innovations that have made it one of the most influential technologies in the past decade.

The Birth of ReactJS: Facebook’s Answer to UI Complexity

The early 2010s were dominated by frameworks like AngularJS, Backbone, and jQuery, which powered much of the web. While effective, these tools often struggled with performance and maintainability at scale. Facebook, facing enormous UI challenges on platforms like News Feed and Instagram, needed something more efficient. This is where ReactJS was born.

The Origins

React was introduced internally at Facebook in 2011 and later at JSConf US in May 2013. Initially, it was met with skepticism due to its unusual JSX syntax—a blend of JavaScript and HTML-like markup. Developers at the time were accustomed to separating markup (HTML), style (CSS), and logic (JavaScript), so JSX seemed counterintuitive.

But this “JavaScript-first” mindset solved a critical problem: the ability to create reusable, encapsulated components. By bundling logic and presentation together, developers could write smaller, testable, and maintainable pieces of UI that could be easily combined into larger applications.

Why React Was Different

React introduced two groundbreaking concepts that set it apart:

• Declarative UI: Instead of manually updating the DOM, developers described how the UI should look given certain data. React took care of updating the DOM when that data changed.
• Component-Based Architecture: Complex interfaces could be built from smaller, reusable units. This reduced duplication and increased maintainability across projects.

Early Adoption

At first, many dismissed React as a niche experiment. But when companies like Instagram, Airbnb, and Netflix began adopting it, the benefits became undeniable. These early adopters reported improvements in speed, developer productivity, and scalability.

Key Takeaway:

React’s birth was not just about introducing another framework; it was about challenging conventional wisdom in UI development and laying the foundation for a component-driven, declarative future:

The Rise of Virtual DOM: A Game-Changer in Web Development

If React’s component-based model made development more manageable, the Virtual DOM made it faster and more scalable. Performance was one of the biggest challenges in the early 2010s, and React’s solution fundamentally shifted how developers thought about rendering.

The Problem with Traditional DOM

The DOM (Document Object Model) is the API browsers use to represent web pages. Manipulating it directly is slow, especially in large, dynamic applications. Common problems included:

• Frequent full-page re-renders are slowing applications
• Complex manual DOM manipulations leading to bugs
• Inconsistent updates across devices and browsers

How the Virtual DOM Works

React introduced an in-memory representation of the real DOM:

• A Virtual DOM tree is created when components render.
• On state or prop changes, React generates a new Virtual DOM tree.
• React compares the new tree with the old one using diffing algorithms.
• Only the parts that changed are updated in the actual DOM (minimal updates).

This process, known as reconciliation, was the secret sauce that made React apps feel smooth even at scale.

Benefits of the Virtual DOM

• Performance Optimization: Reduced unnecessary updates.
• Simpler Code: Developers wrote declarative logic without worrying about low-level DOM manipulations.
• Cross-Browser Consistency: Virtual DOM handled quirks and inconsistencies across environments.

Wider Influence

React’s Virtual DOM innovation quickly influenced other frameworks. Angular (Angular 2+) and Vue adopted similar optimizations, making the Virtual DOM an industry standard.

Example Table: DOM vs. Virtual DOM

Feature	Traditional DOM	Virtual DOM
Update Method	Direct manipulation	Diff & batch updates
Performance	Slow for large apps	Optimized, faster
Developer Experience	Manual control	Declarative, automated

Key Takeaway:

The Virtual DOM redefined performance standards in front-end development, turning React from a neat idea into a must-have tool for building scalable, high-performance applications:

Key Release Milestones: From React 0.3.0 to React 18

React’s journey is best understood by looking at its release milestones. Each version marked a step forward, balancing backward compatibility with cutting-edge innovation.

Major Milestones

• 2013 (React 0.3.0)

Initial open-source release. Focused on JSX, components, and the Virtual DOM.

• 2015 (React 0.14)

Split React into react and react-dom packages. This separation allowed React to expand beyond browsers (e.g., React Native).

• 2017 (React 16 – Fiber Architecture)

Complete rewrite of the core with Fiber, enabling asynchronous rendering. Introduced:

• Error boundaries
• Portals
• Fragments
• 2020 (React 17)

No new features—focused on gradual upgrades and smoother version adoption. Set the stage for React 18.

• 2022 (React 18)

Introduced Concurrent Rendering and expanded Suspense support. Improved responsiveness for data fetching and UI updates.

Why These Milestones Mattered

• Fiber (React 16): Allowed React to pause and resume rendering, paving the way for concurrent features.
• React 17: Prioritized stability over features, a move applauded by enterprises.
• React 18: Delivered the vision of asynchronous rendering, making apps feel snappier.

Table: React’s Milestone Versions

Year	Version	Key Innovations
2013	0.3.0	Initial release with JSX & Virtual DOM
2015	0.14	Separation of react & react-dom
2017	16.0	Fiber, portals, error boundaries
2020	17.0	Upgrade-focused, no new features
2022	18.0	Concurrent Rendering, Suspense upgrades

Key Takeaway:

React’s release history is a testament to its philosophy of balancing innovation with developer stability, ensuring longevity in a fast-moving tech landscape:

The Ecosystem Boom: React Router, Redux, and Beyond

While React’s core library focuses solely on building user interfaces, its real power emerged when a rich ecosystem developed around it. React alone doesn’t handle routing, global state management, or data fetching. But thanks to a growing community and third-party developers, these gaps were quickly filled. The result was not just a UI library but a complete development ecosystem that enabled React to power everything from small apps to enterprise-scale solutions.

Core Ecosystem Libraries

• React Router (2014): Introduced seamless navigation for single-page applications (SPAs). Instead of relying on full-page reloads, developers could create fluid, dynamic transitions that felt like native apps.
• Redux (2015): Popularized predictable state management using a unidirectional data flow. Redux became the default solution for handling global application state, especially in large-scale apps with complex data requirements.
• Next.js (2016): Extended React beyond client-side rendering by introducing server-side rendering (SSR) and static site generation (SSG). This drastically improved performance and SEO for React apps.

Supporting Tools and Libraries

Beyond these foundational tools, the ecosystem grew into hundreds of libraries and frameworks:

• UI Component Libraries: Material-UI, Ant Design, Chakra UI — these gave developers pre-built design systems to accelerate UI creation.
• Data Tools: Apollo Client (GraphQL), React Query (server state management and caching).
• Testing Frameworks: Jest and React Testing Library became standards for ensuring React components function correctly.
• Storybook: A tool for isolated component development and documentation, widely adopted by design systems.

Impact on Development

The ecosystem made React more than just a choice — it became a movement. Developers could now:

• Build production-ready apps faster with reusable tools.
• Scale applications easily with community-tested solutions.
• Integrate specialized tools (e.g., GraphQL, TailwindCSS) without abandoning React’s foundation.

Example: Common React Stack in Production

Layer	Tool/Library Example
UI Components	Material-UI, Chakra UI
Routing	React Router, Next.js
State Management	Redux, Zustand, Recoil
Data Fetching	React Query, Apollo Client
Testing	Jest, React Testing Library

Key Takeaway:

The boom of React’s ecosystem elevated it from a UI library into a complete platform for modern web applications, making it one of the most versatile and dominant tools in the developer’s toolkit:

The Future of React: Server Components, AI, and Beyond

As React enters its second decade, it continues to evolve in response to modern challenges: performance, scalability, and developer productivity. With upcoming features like React Server Components (RSC), deeper integration with frameworks, and AI-assisted development, React is poised to remain at the cutting edge of front-end technology.

Emerging Features

• React Server Components (RSC): A paradigm shift that allows developers to render parts of the UI on the server while keeping interactivity on the client. This reduces bundle sizes and improves page load times.
• Concurrent Rendering Expansion: Building on React 18’s foundation, future updates aim to improve responsiveness further by letting React pause, resume, and prioritize updates more intelligently.
• Improved Suspense Features: Suspense, initially experimental, will likely evolve into a standard for managing asynchronous operations like data fetching with smooth fallback UI.

Deeper Framework Integration

Frameworks like Next.js and Remix are becoming the de facto standards for building with React. These frameworks:

• Handle routing, SSR, and static builds out of the box.
• Offer optimized data fetching strategies tightly aligned with React’s evolving APIs.
• Push React closer to being a “full-stack” framework while maintaining its flexibility.

Broader Trends Shaping React’s Future

• Edge Computing and Serverless: With the rise of platforms like Vercel and Netlify, React applications will increasingly run closer to users, improving speed and reducing latency.
• AI in Development: Tools like GitHub Copilot and ChatGPT are helping developers write React code faster, automate testing, and even generate UI components.
• Sustainability and Performance: As user expectations for speed and efficiency grow, React will likely prioritize smaller bundle sizes and better defaults for performance.

Example List: Likely Focus Areas for React’s Next Phase

• Seamless client-server collaboration (via RSC).
• Enhanced developer experience with better debugging and profiling tools.
• Stronger default integrations with TypeScript.
• Expanding accessibility features baked into React APIs.

Key Takeaway:

The future of React is defined by adaptability. With innovations like Server Components, tighter framework integration, and AI-driven coding tools, React is positioned not just to keep pace with the web but to lead its next wave of transformation:

Conclusion

From its humble beginnings at Facebook to becoming the backbone of modern web development, ReactJS has transformed how developers build user interfaces. With innovations like the Virtual DOM, milestones like the Fiber rewrite, and an ever-expanding ecosystem, React has proven to be more than just a passing trend—it’s a framework for the future.

As React embraces server components, concurrent features, and deeper integration with modern frameworks, it will continue to shape the future of front-end development for years to come.

React’s success lies in its constant evolution—balancing innovation with stability while empowering developers to build faster, more scalable, and more interactive applications.

FAQs

When was ReactJS first released?

Facebook first open-sourced ReactJS in May 2013 at JSConf US.

What makes React different from other frameworks?

Its component-based structure, Virtual DOM, and declarative programming model make it unique compared to traditional frameworks.

What is the most important React update so far?

React 16’s Fiber architecture was the most significant update, enabling asynchronous rendering and setting the stage for future innovations.

Is ReactJS still relevant in 2025?

Yes. React continues to dominate front-end development, thanks to its strong ecosystem, framework support, and ongoing updates.

What’s next for ReactJS?

The future includes React Server Components, more concurrent features, and tighter integration with frameworks like Next.js and Remix.

Additional Resources