DEV Community: Aleksandra Dudkina

map vs forEach in JavaScript: The Difference Nobody Talks About (Until It Breaks You in an Interview)

Aleksandra Dudkina — Sat, 04 Apr 2026 19:38:39 +0000

There's a difference between map and forEach that most developers know but don't fully think about until it bites them in a real situation.

I want to talk about that difference and specifically about one behaviour of map that I completely forgot about when I was solving a flat polyfill in an interview. Spoiler: it cost me time and produced a wrong answer. Let's break it all down.

The Basics: What's the Key Difference?

Both map and forEach iterate over arrays. But they are fundamentally different in what they give back.

The key difference:

map() returns a new array

forEach() returns nothing (undefined)

`map()` - transforms data

Use map() when you want to create a new array based on the original one.

const numbers = [1, 2, 3];

const doubled = numbers.map((num) => num * 2);

console.log(doubled); // [2, 4, 6]

map() takes each element, transforms it, and returns a new array of the same length.

`forEach()` - just runs code

Use forEach() when you just want to do something with each item.

const numbers = [1, 2, 3];

numbers.forEach((num) => {
  console.log(num * 2);
});

It doesn’t return anything!

const doubled = numbers.forEach((num) => num * 2);

console.log(doubled); // undefined

forEach runs a function on each element and returns undefined. Always. Even if you explicitly use return in your code:

const numbers = [1, 2, 3];

const doubled = numbers.forEach((num) => {
  return num * 2;
});

console.log(doubled); // undefined

Another example:

function doubled(arr) {
  return arr.forEach((num) => {
    return num * 2;
  });
}

console.log(doubled([1, 2, 3])); 
// undefined

Even though we used return twice, the result is still undefined.

You would use it when you just want to do something with each element - push to another array, log something etc.

Why `map()` is Used in React Lists

If you’ve worked with React, you’ve definitely seen this pattern:

const listItems = users.map((user) => (
  <li key={user.id}>{user.name}</li>
));

React needs an array of elements to render a list.

And map() returns exactly that - a new array.

Why forEach() wouldn't work in this situation:

const listItems = users.forEach((user) => (
  <li key={user.id}>{user.name}</li>
));
// nothing is returned
// nothing is rendered

This won’t work because:

forEach() returns undefined
React receives nothing to render

Why `map()` Is Perfect for Chaining

One of the biggest advantages of map() is that it returns a new array, which means you can chain methods.

Chaining multiple operations:

const numbers = [1, 2, 3, 4];

const result = numbers
  .map((n) => n * 2) // doubled numbers are returned here
  .filter((n) => n > 4) // filtered numbers are returned here
  .map((n) => `Value: ${n}`); // a new map is returned here

console.log(result);
// ["Value: 6", "Value: 8"]

Step by step:

map → [2, 4, 6, 8]
filter → [6, 8]
map → ["Value: 6", "Value: 8"]

Each step returns a new array → enabling chaining

Why forEach() breaks chaining

const result = numbers
  .forEach((n) => n * 2) // undefined is returned
  .filter((n) => n > 4); // Error. You can't use array methods with undefined

This fails because:

forEach() returns undefined
You can’t call .filter() on undefined

Final recap on basics:

const nums = [1, 2, 3];

// forEach: returns undefined
const dobuledWithForEach = nums.forEach(n => n * 2);
console.log(result1); // undefined

// map: returns a new array
const dobuledWithMap = nums.map(n => n * 2);
console.log(result2); // [2, 4, 6]

Feature	map()	forEach()

Returns value

✅ New array

❌ undefined

Use case

Transform data

Side effects

Chainable

✅Yes

❌ No

When to use map():

You need the result, a new transformed array
You're rendering lists in React
You want to chain with .filter(), .reduce(), etc.

When to use forEach():

You just want to do something - log, push, trigger a side effect
You don't need a return value
You're building a result array yourself by pushing each element into it

Rule of thumb:

If you’re returning something → use map()

If you’re just doing something → use forEach()

This is the part most developers know about. But there's a less obvious difference that matters a lot in certain situations.

The Part Nobody Talks About: Empty Slots

JavaScript arrays can have empty slots. These are not the same as undefined. They are genuinely missing indices, literally creating holes in the array.

You can create them like this:

const arr = [1, , , 4]; // see, empty slots!
console.log(arr.length); // 4
console.log(arr[1]);     // undefined (but the slot is empty, not set to undefined)

Or like this:

const arr = new Array(3); // [empty × 3]
console.log(arr.length);  // 3

Now here's where map and forEach behave very differently:

map skips empty slots but keeps them in the output.

forEach also skips empty slots but simply doesn't call the callback for them.

const arr = [1, , , 4];

arr.forEach((item, index) => {
  console.log(index, item);
});
// 0 1
// 3 4
// (see, indices 1 and 2 are skipped entirely!)

const mapped = arr.map(item => item * 2);
console.log(mapped); // [2, empty, empty, 8]
// empty slots are kept in the output!

See what map does? It skips the callback for empty slots but still keeps the hole in the output array. The resulting array has the same length and the same holes. You can't get rid of them with map.

It's the kind of thing that doesn't feel intuitive until you run into it.

Why This Matters: My Interview Story

I was asked to write a polyfill for Array.prototype.flat. If you haven't used it, flat takes a nested array and flattens it to a given depth:

[1, [2, [3]]].flat(1);   // [1, 2, [3]]
[1, [2, [3]]].flat(2);   // [1, 2, 3]
[1, [2, [3]]].flat(Infinity); // [1, 2, 3]

My first attempt was using map and recursion:

function flat(arr, depth = 1) {
  return [].concat(...arr.map((item) => {
    if (depth > 0 && Array.isArray(item)) {
      return flat(item, depth - 1);
    }
    else {
      return [item];
    }
  }));
}

Here's what happens here step by step:

flat is called with an array and a depth (default is 1)
.map() goes through each item in the array:
If depth is more than 0 and the item is an array, it calls flat on it with depth - 1
Otherwise, it puts the item in [item] to ensure map returns an array
[].concat(...) combines all those arrays into one flat array

The test I failed:

flat([1,2, , ,undefined,[3,4,[5,6,[7,8,[9,10]]]]], Infinity)

Expected result: [1, 2, undefined, 3, 4, 5, 6, 7, 8, 9, 10]

Actual result: [1, 2, undefined, undefined, undefined, 3, 4, 5, 6, 7, 8, 9, 10]

See, there are 2 empty slots in this test. They are expected to be ignored but instead they are kept in the result and turned into undefined.

Remember what we said before:

const arr = [1, , , 4]; // see, empty slots!
console.log(arr.length); // 4
console.log(arr[1]);     // undefined (but the slot is empty, not set to undefined)

map skips empty slots but keeps them in the output.

It keeps empty slots in the output and spread ... turns them into undefined, while it should just ignore empty slots.

Remember what we said about how forEach treats empty slots:

forEach skips empty slots but simply doesn't call the callback for them

Which basically means that forEach skips empty slots entirely.

Perfectly suitable for our case!

Let's rewrite our solution with forEach:

function flat(arr, depth = 1) {
  let result = [];
  arr.forEach((item) => {
    if (depth > 0 && Array.isArray(item)) {
      result.push(...flat(item, depth - 1))
    }
    else {
      result.push(item)
    }
  })
  return result
}

Basically, almost the same solution. The difference is: as forEach doesn't return a new array, we can't use [].concat anymore (as we will be trying to concat undefined in such case), we will just push to the result array instead.

As forEach ignores empty slots entirely, it won't turn empty slots into undefined elements.

The result we get: [1, 2, undefined, 3, 4, 5, 6, 7, 8, 9, 10]

No extra undefined elements anymore.

Recap

map returns a new array, forEach returns undefined
Both skip empty slots during iteration
map keeps empty slots in the output
forEach doesn't return anything, so it just skips empty slots and moves on

Note: This is one of those things that almost never matters in day-to-day work but can come up when doing some lower-level array manipulations. Worth keeping in the back of your head.

Rest Parameters and arguments object: A Quick JavaScript Guide

Aleksandra Dudkina — Thu, 26 Mar 2026 14:13:12 +0000

When I was learning JavaScript, rest parameters and the arguments object felt confusingly similar.

Here's a quick breakdown.

Why do we even need it

Imagine you're writing a function to calculate the total price of items in a shopping cart.

function calculateTotal(firstItemPrice, secondItemPrice, thirdItemPrice) {
  let total = 0;
  total = total + firstItemPrice + secondItemPrice + thirdItemPrice
  return total;
}

calculateTotal(10, 20, 30); // 60

This works perfectly, except for the fact that it works perfectly only for 3 items. What if we need to calculate the price of 5 items? Or of 10 items? We really wouldn't want to pass 10 similar arguments to a function.. We don't even know how many items a user will put in a cart in the first place. And this is when the arguments object and rest parameters come in handy.

You need arguments object and rest parameters when you don't know how many parameters will be passed to a function in advance.

Arguments Object Usage

JavaScript gives us a built-in way to handle an unknown number of arguments - the arguments object. Think of it this way: it packs all the arguments you pass to a function inside just one variable.

// you don't need to declare arguments here
function calculateTotal() {
  let total = 0;

// all the parameters you pass are inside arguments
// let's iterate over all items to count their total price
  for (let i = 0; i < arguments.length; i++) {
    total += arguments[i];
  }

  return total;
}

calculateTotal(10, 20, 30);        // 60
calculateTotal(5, 15, 25, 35);     // 80

Now we can count the total price of any number of items!

If you look carefully at the function we've just created you might want to use .reduce() here. Let's see how it'll work:

function calculateTotal() {
  return arguments.reduce((total, price) => total + price, 0);
}

calculateTotal(10, 20, 30);
// TypeError: arguments.reduce is not a function

And this is exactly why arguments is so confusing.. We've just successfully iterated over it, we can even address any parameter with its index (for example, extract first item with arguments[0]) then why do we get this error?

If you try to use any other array method or iterator, you’ll run into the same error:

function calculateTotal() {
  arguments.forEach(price => {
    console.log(price);
  });
}

calculateTotal(10, 20, 30);
// TypeError: arguments.forEach is not a function

function calculateTotal() {
  return arguments.map(price => price * 2);
}

calculateTotal(10, 20, 30);
// TypeError: arguments.map is not a function

That’s because arguments is array-like, but NOT an actual array.

It supports:

numeric indexes (arguments[0])
length

But it doesn’t support:

array methods (map, reduce, forEach)

If you want to use arguments like an array, you first need to convert it into a real array with Array.from():

function calculateTotal() {
  const prices = Array.from(arguments);

  return prices.reduce((total, price) => total + price, 0);
}

calculateTotal(10, 20, 30); // 60

At this point we:

received arguments
converted them into an array
and only then used array methods

We're also using additional memory by creating a new array.

It all feels like extra, unnecessary work for something so common.

If you already think that using arguments is not very convenient, let me give you more reason to doubt it:

arguments does NOT exist in arrow functions

const calculateTotal = () => {
  console.log(arguments);
};

calculateTotal(10, 20, 30);
// ReferenceError: arguments is not defined

Arrow functions simply don’t have their own arguments object.

So if you try to handle a dynamic number of parameters in an arrow function, you can’t use arguments at all.

What we have for now:

Pros:

Can handle an unknown number of arguments
You can access any argument by its index (arguments[0])
You can check how many arguments were passed using arguments.length

Cons:

Not a real array: you need to convert it to an array first to use array methods like .map(), .reduce() or forEach
Converting to an array uses extra memory
Can't be used in arrow functions

And this is exactly why rest parameters exist.

Rest Parameters Usage

Rest parameters solve literally all the issues that arguments has.

Rest parameters let you collect all remaining function arguments into a real array right from the start.

const calculateTotal = (...prices) => {
  prices.forEach(price => {
    console.log(price);
  });
};

calculateTotal(10, 20, 30);
// 10
// 20
// 30

Notice how:

We don't use arguments anymore
prices is already a real array
Works with any number of arguments, similarly to the arguments object
We can use rest parameters in an arrow function

There is even more advanced usage available - you can mix regular arguments with rest parameters:

// declare first argument separately
const calculateTotal = (firstItem, ...otherItems) => { 
 console.log(`First item purchased: ${firstItem}`);

    if (otherItems.length > 0) { 
        console.log("Other items purchased:"); 
        otherItems.forEach((item, index) => {
        console.log(`${index + 1}. ${item}`) 
      }) 
    } 
    else { 
        console.log("No other items purchased.")
    }
}

// Example usage with numbers as prices:
calculateTotal(50, 20, 15, 10);

// First item purchased: 50 
// Other items purchased:
// 20
// 15
// 10

firstItem:

Captures the first argument separately

...otherItems :

Collects all remaining arguments into a real array
Allows iteration with .forEach(), .map(), .reduce(), etc.

Unlike the arguments object, which captures everything all together, rest parameters must always be the last argument in your function definition. function(a, ...b, c) will throw a SyntaxError:

// SyntaxError: Rest parameter must be last formal parameter 

function calculate(first, ...others, last) { 
    console.log(others); 
}

// How the JS engine sees it:
// "Okay, the first argument is 10. Then 'others' captures everything that's left. 
//  Then what am I supposed to put into 'last'? I'm confused!"

If you want to separately use the last parameter, you can do it this way:

function calculate(first, ...others) { 
// using index to address the last parameter
    console.log(others[others.length-1]); 
}

Don't confuse rest parameters with spread

Even though rest parameters (...args) and the spread operator (...myArray) use the same ... syntax, they do very different things.

Rest Parameters

Used in a function parameter list to collect all the arguments into a single array

function sum(first, ...others) {
  return others.reduce((total, num) => total + num, first);
}

sum(10, 20, 30, 40); // 100

Here:

first = 10
...others = [20, 30, 40] - collects remaining arguments into an array.

Spread Operator

Used when calling functions, creating arrays, or objects to expand elements.

const numbers = [20, 30, 40];
console.log(...numbers); // 20 30 40

const allNumbers = [10, ...numbers, 50];
console.log(allNumbers); // [10, 20, 30, 40, 50]

Here ...numbers “spreads” the array elements into individual values. It does not collect anything - it expands.

Quick Rule of Thumb:

Rest parameters → collects multiple values into an array + used only in functions
Spread → expand an array into individual elements

Rest Parameters vs `arguments` key differences

Feature	`arguments`	Rest Parameters
Type	Array-like	Real array
Works in arrow functions	No	Yes
Modern usage	Legacy	Preferred
Supports array methods	No	Yes

The arguments object is a legacy feature from older versions of JavaScript. It can still be used. Rest parameters (...args) are a newer feature in JavaScript (ES6+), designed to replace most use cases of arguments. Use rest parameters by default.

JWT Authentication in React: Guide to Access Tokens & Refresh Tokens

Aleksandra Dudkina — Sun, 22 Mar 2026 08:10:33 +0000

What Are Access Tokens and Refresh Tokens? (And Why You Need Both)

Before diving into implementation, let’s first understand the HTTP endpoints your frontend communicates with and what each of them does.

A step by step flow in short:

On login request we send the login and password to the server. The backend checks whether they match an existing user. If no, we will get an error response (typically 401 Unauthorized). If yes, we will get a 200 response with a response body similar to this:

"access_token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJleHAiOjE3MTYyMzkwMjIsInVzZXJfaWQiOjEsInJvbGUiOjJ9.RDsEg737AOckmF_rXiZehecfKZQZV_Zr_csnRZnJZVM"

We will see later what to do with this response. What we need to remember for now is that we get an access token on authentication request (login request in simple words).

Besides access token, the server will also send us a refresh token. You may wonder where it is, as we don't see anything besides access token in the response. Refresh token is sent in HTTP-only cookies and cannot be directly accessed in your app. Refresh token is stored in browser.

What we need to remember for now:

Access token is what we work with in our app. It usually contains some important information about the user (like id, role, etc.), which is validated by the backend (the backend is always the source of truth). This token is sent with every request. The server uses it to verify that the user is authenticated and has the required permissions. Also, access token has its expiration time, for example, 15 minutes. Usually, access token is short-lived. So to stay authorized, we will need to request a new access token when it expires. And this is why refresh token is needed.
Refresh token is used to get a new access token. This token is automatically sent to the server (this happens on the browser side).

In short: when the access token expires, we send a refresh request, and the browser automatically includes the refresh token cookie, and we receive a new access token.

Think of authentication as:

access token = temporary pass

refresh token = ability to get a new pass without logging in again

Flow recap:

User logs in → receives access token in body + refresh token in cookie
For API requests, application includes access token
When access token expires, application detects this (or receives 401) and calls refresh endpoint
Browser automatically includes refresh token cookie with refresh request
Server sends new access token (the user does not need to log in again)
Application retries original request with new token
When user logs out, refresh token is invalidated on server and removed from browser

How to Decode a JWT Token

As you remember, after we send a login request and get a success response, we get something similar to this in response body:

"access_token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJleHAiOjE3MTYyMzkwMjIsInVzZXJfaWQiOjEsInJvbGUiOjJ9.RDsEg737AOckmF_rXiZehecfKZQZV_Zr_csnRZnJZVM"

If you look carefully, you see that the long string we received from server is divided into 3 parts by dots (.)

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9. - this is header

ehJ1c2VyX2lkIjoxMjL0NSwicm9sZSI6ImNsaWVudCIsImlzcyI6Ik15QXBwIiwiaWF0IjoxNzYwMDAwMDAwLCJleHAiOjE3NjAwMDAzMDB9. - this is payload

dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk - this is signature

We can read the payload (the middle part) to extract some useful information. This part is encoded (meaning anyone can decode and read it) and typically contains data such as user ID, role, or other details.

Besides the user data, it also contains token-related data, the most important part for us is token expiration time.

There are libraries for decoding token payload.

What I personally used when working on a project:

online token decoders just for quick checks and tests
a library to decode in my app. Personally, i used "jwt-decode" library

What i did is i wrote a decoder function with the library:

import { jwtDecode } from "jwt-decode";
import type { JwtPayload } from "jwt-decode";

// if you work in TypeScript
// this might be useful for correct storing and checking 
// the values you extract from payload for later usage
export interface accessTokenPayload extends JwtPayload {
  user_id: number;
  role: number;
  // other user data 
}

export function jwtDecodePayload(token: string) {
  return jwtDecode<accessTokenPayload>(token);
}

And decoded the payload after I received it from the server:

    // login request
      const response = await fetch(`${api}/login`, {
      method: "POST",
      headers: {
        "Content-Type": "application/json",
      },
    // this line is crucial to receive refresh token, 
    // we will take a deeper look at it later 
      credentials: "include",
      body: JSON.stringify({
        login: login,
        pass: password,
      }),
    });


    const data = await response.json();
    //the function we created above
    const tokenPayload = jwtDecodePayload(data.access_token); 
    console.log(tokenPayload) 

// {
//   exp: 1716239022,  - expiration time, timestamp in seconds
//   user_id: 1,
//   role: 2
// };

Now we can use tokenPayload in our app.

Note: we can read this data on the frontend, but we should not fully trust it, the server always validates it.

Before using it, we need to store it somewhere.

Token Storage Considerations

If you search on the internet, you will see that when it comes to where to store access token, many mention storing it in localStorage or sessionStorage. When implementing authorisation logic on the project I've been working on, our team decided that none of these will be used. Storing tokens in localStorage is convenient but has security risks. That's why many teams prefer keeping access tokens in memory.

Our decision was to store access token in memory (RAM). What it means in simple words: just store it as a JavaScript variable. The variable will be deleted from the memory every time we do a page refresh (this is where we will use refresh token to request a new access token). This is why we often call the refresh endpoint when the app loads - to restore the session after a page refresh, so the user doesn’t have to log in again.

Architecture note: Store only token-related data in tokenStorage. Store user data (login, role, etc.) separately in global state (Redux, Context, etc.) - keep token logic isolated.

But we have many values: expiration time, user ID, user role, so it’s not just a single value as we need to store multiple pieces of data.

My solution was to create an object that will be used around the app. This is a simplified setup that demonstrates the idea:

class TokenStorage {
  private accessToken;
  private tokenExp; //timestamp in seconds

  setToken(token, tokenPayload) {
    this.accessToken = token;
    this.tokenExp = tokenPayload.exp;
  }

  getToken() {
    return this.accessToken;
  }

  isTokenActive() {
    if (!this.accessToken) {
      return false;
    }
    if (!this.tokenExp) {
      return false;
    }
    return Date.now() < this.tokenExp * 1000;
  }

// we will need this to handle logging out
  clearToken() {
    this.accessToken = null;
    this.tokenExp = null;
  }

}

// the variable will be created when we load the app in the browser
export const tokenStorage = new TokenStorage();

What we have:

we store the full access token string and we can get it with tokenStorage.getToken() anywhere in the app
we store token expiration time and can quickly check if access token hasn't expired by just calling tokenStorage.isTokenActive()

So when we receive access token from the server and decode it, we store it in the tokenStorage variable.

// response from login request
const response = await fetch(`${api}/login`, {
  method: "POST",
  headers: {
    "Content-Type": "application/json",
  },
  //this line below enables storing refresh token! we will explore it later
  credentials: "include",
  body: JSON.stringify({
    login: login,
    pass: password,
  }),
});


const data = await response.json();
// decoded payload
const tokenPayload = jwtDecodePayload(data.access_token); 

// we set the whole access token string and token payload object
tokenStorage.setToken(data.access_token, tokenPayload);

Now we can access token anywhere in the app, for example, check if access token is still valid by just calling tokenStorage.isTokenActive()

Access Token Usage

Let’s briefly recap why we need the access token:

It is passed in all HTTP requests

//we get current access token stored in app
const token = tokenStorage.getToken()

const myRequest = await fetch(`${api}/request`, {
  method: "GET",
  headers: {
    "Content-Type": "application/json",
     "Authorization": `Bearer ${token}` //we pass token to server
  },
  credentials: "include",
});

It is passed as a query parameter in WebSocket requests (explained in WebSocket part below).

What happens if token is expired (or if the user is not authorized at all): server will respond with 401 Unauthorized. This is the moment we need a new access token and this is when we need refresh token!

How the Refresh Token Flow Works (and How to Implement It)

First, let's investigate where refresh token is stored and how we use it to get a new access token. Remember, the body response from server didn't include any refresh token.

Let's take a step back.

This is the login request we did and the response body:

   // login request
      const response = await fetch(`${api}/login`, {
      method: "POST",
      headers: {
        "Content-Type": "application/json",
      },
      credentials: "include", //take a look here
      body: JSON.stringify({
        login: login,
        pass: password,
      }),
    });

// body response: 
"access_token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJleHAiOjE3MTYyMzkwMjIsInVzZXJfaWQiOjEsInJvbGUiOjJ9.RDsEg737AOckmF_rXiZehecfKZQZV_Zr_csnRZnJZVM"

If you go to DevTools → Application → Cookies, you will see the cookie with the refresh token.

This is the refresh token!

Refresh token is sent in HTTP-only cookie and is stored in browser. This works because of credentials: "include" line, the browser will not store cookies sent by the server in the response if credentials: "include" is not set (It took me a while to find this bug when I was implementing authorisation flow myself).

Note: Since refresh tokens are stored in cookies and sent automatically by the browser, the backend usually needs CSRF protection to prevent malicious websites from making requests on behalf of the user without their consent.

credentials: "include" handles both receiving HTTP-only cookies (refresh token in our case) and sending them back to the server automatically. If there are HTTP-only cookies stored in browser, credentials: "include" line in your request will automatically send them to server.

Getting a new valid access token is not difficult. We just need to send a request to a dedicated endpoint and include HTTP-only cookies (refresh token from browser).

Here is a simplified logic:

    // refresh token request
    const response = await fetch(`${api}/refresh`, {
      method: "GET",
      headers: { "Content-Type": "application/json" },
      credentials: "include", //send refresh token stored in browser
    });

    if (response.ok) {
      const data = await response.json();
      // receiving and storing a new access token
      const payload = jwtDecodePayload(data.access_token);
      tokenStorage.setToken(data.access_token, payload);
    }

Logging out


    // logout request 
    const response = await fetch(`${api}/logout`, {
      method: "GET",
      headers: { "Content-Type": "application/json" },
      credentials: "include", //send refresh token stored in browser
    });

    if (response.ok) {
      // we need to clear the local token variable!
      tokenStorage.clearToken();
      return;
    }

At this moment the server invalidates the refresh token (deletes it from database) on its side. If you try to use the same refresh token after it was cleared on the server (after the logout), you will get 401 Unauthorized error.

Remember i mentioned, that storing access token in a variable means that on each page refresh access token will be deleted from the memory. Will we have to call refresh token on each page refresh?

Note that refresh token is not infinite-long either. It has its expiration time too. How do we check if refresh token is still valid? What will happen if it is already expired but we keep sending it to server?

There are even more questions to be raised:

What if user is not authorized at all? What if unauthorized user tries to navigate to some protected page with just inserting URL in browser search line? How to prevent an authorized user to navigate to login page? If user changed password on another device, how should be log them out automatically?

Protected routes and handling user authorisation states

I will share my personal experience of handling authorisation on routing level, but remember that this part can be implemented in various different other ways, depending on the project setup.

We use React Routing in the project i've been working on, but if you use Tanstack Routing for example, the core idea remains the same.

Before handling routing and protected routes, let's investigate, how our app understands if refresh token is still valid and if the user is authorized or not.

A short answer is: the server handles it all.

The server is the source of truth. The frontend only reacts to responses (like 401 Unauthorized).

Let's take a look at few scenarios:

We make a HTTP request and send access token in Headers.

//we get current access token stored in app
const token = tokenStorage.getToken()

//some request
const myRequest = await fetch(`${api}/request`, {
  method: "GET",
  headers: {
    "Content-Type": "application/json",
     "Authorization": `Bearer ${token}` //we pass token to server
  },
  credentials: "include"
});

Server checks if the access token we provided is expired. If access token is expired, server will send us the 401 Unauthorized error.

We make a refresh token request:

// refresh token request
const response = await fetch(`${api}/refresh`, {
  method: "GET",
  headers: { "Content-Type": "application/json" },
  credentials: "include", //send refresh token stored in browser
});

if (response.ok) {
  const data = await response.json();
  // receiving and storing a new access token
  const payload = jwtDecodePayload(data.access_token);
  tokenStorage.setToken(data.access_token, payload);
}

The server checks whether the refresh token is valid.

- If refresh token is expired, server will send us the 401 Unauthorized error.

- If refresh token is invalid, server will send us the 401 Unauthorized error (for example, the user logged out with this refresh token before, and this refresh token isn't valid anymore on server side).

This is where routing comes into place: if user is not authorized, we should navigate them to some /auth path.

First, let's clear local token storage if the user is not authorized anymore.

This is what we were already doing in logout request:


    // logout request 
    const response = await fetch(`${api}/logout`, {
      method: "GET",
      headers: { "Content-Type": "application/json" },
      credentials: "include", //send refresh token stored in browser
    });

    if (response.ok) {
      // we need to clear the local token variable! !
      tokenStorage.clearToken();
      return;
    }

Let's add additional checks to refresh token request. Remember, refresh token request can respond with 401 Unauthorized error and we need to log the user out!

// refresh token request
const response = await fetch(`${api}/refresh`, {
  method: "GET",
  headers: { "Content-Type": "application/json" },
  credentials: "include", //send refresh token stored in browser
});

// Server checks if the refresh token we provided is valid.
// - If refresh token is expired, server will send us the 401 Unauthorized error.
// - If refresh token is invalid,  server will send us the 401 Unauthorized error
if (response.status === 401) {
// clear local access token as the user needs to be logged out
    tokenStorage.clearToken();
}



if (response.ok) {
  const data = await response.json();
  // receiving and storing a valid access token
  const payload = jwtDecodePayload(data.access_token);
  tokenStorage.setToken(data.access_token, payload);
}

Refresh request result:

200 OK → new access token → user stays logged in
401 Unauthorized → refresh token invalid → user is logged out

Auth checks outside of route level would look something like this in a simplified way:

const MainPage = () => {

// when app is initialised, the tokenStorage is empty, we need to get a new access token 
refreshRequest()

// if there is no access token stored or it is already expired, log out user

  useEffect(() => {
  // check if the current access token is still valid
    if (!tokenStorage.isTokenActive()) {
      navigate("/auth") //depends on which routing lib you use
    }
  }, [navigate]);

The same on /auth path:

const LoginPage = () => {

// when app is initialised, the tokenStorage is empty, we need to get a new access token 
refreshRequest()

// if there is already an active access token, the user is already authorized 
useEffect(() => { 
// check is current access token in still valid 
 if (tokenStorage.isTokenActive()) { 
    navigate("/main") //depends on which routing lib you use 
 } 
}, [navigate]);

What happens here is:

The component is rendered

→ Refresh request is called to check if user is authorized

→ token check

→ navigation

This means that if the user is authorized, they might briefly see the LoginPage before being redirected to the MainPage. And vice versa. This happens because we first need to wait the component to fully render before useEffect runs. This means the user may briefly see the wrong page before being redirected - a noticeable flicker.

Using route loaders solves this.

Using Route Loaders for Auth Checks (No Page Flicker)

Route is matched

→ loader runs (refresh + token check)

→ navigation happens

→ only then the page renders

No unnecessary renders. No flickering.

Flow recap:

Login → access token + refresh token

Request → send access token → OK

Access token expired → refresh request (cookie auto-sent) → new access token → retry request

Refresh token expired → logout → redirect to /auth

To implement it, we go to the place in the project where we do all the routing setup. In my case, it was in main.tsx component:

    router = createBrowserRouter([
      {
        path: "/main", // this is the main page
        element: <MainPage />,
        loader: rootLoader,
      },
      {
        path: "/auth", //this is auth page
        element: <LoginPage />,
        loader: authLoader,
      },
    ]);

This is React Router (data mode), but this logic can be implemented with almost any other library. All the route-level requests and anything we want to do before page rendering happens inside the loader function.

Tanstack router docs for loaders

React Router docs with loader example - this is example for data mode, framework mode can differ a bit.

We pass to the loaders functions all the checks we need:

async function rootLoader() {
// if there is no active access token, wait for a new one
  if (!tokenStorage.getToken()) {
    await refreshTokenRequest();
  }

// if we didn't receive any new valid access token, it means the user is NOT authorized, navigate to auth
  if (!tokenStorage.isTokenActive()) {
    return redirect("/auth");
   } 
  }
  return null;
}

async function authLoader() {
// if there is no active access token, wait for a new one
  if (!tokenStorage.getToken()) {
    await refreshTokenRequest();
  }

// if we received a new valid access token, it means the user is already authorized, navigate to the main page
  if (tokenStorage.isTokenActive()) {
    return redirect("/");
  }
  return null;
}

Flow recap:

We refresh the main page → refresh token request is sent →

res 401 → no valid access token, clear the remaining access token we had in memory → navigate user to /auth → render auth page
res ok → we received and stored a new valid access token → render main page

Login → access token + refresh token

Request → access token → OK

Access expired →

→ refresh request (cookie auto sent)

→ new access

→ retry request

Refresh expired →

→ logout

→ redirect to /auth

Handling JWT Auth with WebSockets

Usually, access token is added as a query parameter to the WebSocket endpoint.

Example:

const accessToken = 'your_access_token_here';
// we attach access token directly to  websocket endpoint 
// to the query param "access_token"
const websocketEndpoint = `wss://example.com/socket?access_token=${accessToken}`;

const socket = new WebSocket(websocketEndpoint);

socket.onopen = function(event) {
    console.log('WebSocket is open now.');
};

// Example of handling a WebSocket error response indicating unauthorized access

socket.onclose = function(event) {
    if (event.code === 1008) { // 1008 is a policy violation code, often used for unauthorized access
        console.error('WebSocket closed due to unauthorized access');
    } 
};

If you send invalid or expired access token, the connection will get closed and you will receive 1000 or 4001 error code (some servers use custom codes like 4001 to indicate an expired access token; always check your backend docs).

socket.onclose = function(event) { 
    if (event.code === 1008 || event.code === 4001) { 
// 1008 is a policy violation code, often used for unauthorized access 
// 4001 is a custom application code typically used for invalid or expired tokens
        console.error('WebSocket closed due to unauthorized access'); 
    } 
};

At this moment, there are two possible reasons:

access token got expired
the user got unauthorized (for example, the user logged out in another browser window).

In both cases backend sees that the access token we send isn't valid anymore.

Usually, when socket connection is closed, you try to reconnect a few times. We will try to reconnect here too. But if we try to reconnect with the same invalid access token, we will be getting the same error response. We need to get a new access token first, before trying to reconnect.

So it would be something like:

socket.onclose = async function (event) {
  if (event.code === 1008 || event.code === 4001) {
    // 1008 is a policy violation code, often used for unauthorized access
    // 4001 is a custom application code typically used for invalid or expired tokens
    console.error("WebSocket closed due to unauthorized access");

    // requesting a new access token with refresh request, store a new token in memory
    await refreshTokenRequest();
    // just for safety check again if we got a valid access token
    if (tokenStorage.isTokenActive()) {
      // reconnect
      connectWebSocket();
    }
  }
};

Common close codes to handle:

1008 — policy violation (unauthorized access)
4001 — custom code often used for expired tokens (always check your backend docs)

If you try to reconnect with the same invalid token, you will keep getting the same error. Always request a new access token first, then reconnect.

Tip: Add a maximum reconnect attempt limit to avoid infinite retry loops.

Recap

We covered the full JWT authentication flow in React:

Access token is stored in memory and sent with every request
Refresh token lives in an HTTP-only cookie and is handled automatically by the browser
Tokens should be stored in memory, not localStorage, to avoid security risks
Use a local object to manage token state across your app
When access token expires, call the refresh endpoint to get a new one without logging the user out
Use route loaders instead of useEffect for auth checks to avoid page flicker
For WebSockets, always refresh the token before reconnecting after a 1008 or 4001 close code

The server is always the source of truth, the frontend only reacts to what the server tells it.

finally() in JavaScript: Why It Can't (Usually) Change a Promise's Result

Aleksandra Dudkina — Sun, 04 Jan 2026 21:49:38 +0000

A common misconception is that finally() behaves like then().

In reality, it doesn’t receive values, ignores return values, and only affects a promise in very specific cases. Let’s see why.

`finally()`: Why It Can’t Change a Promise Result

`finally()` doesn’t receive arguments

Let's start with a quick quiz to test your understanding:

myPromise.then(() => "Hi, Sasha!")
.finally(res => console.log(res + "Whats up?")) 

//what will appear in console?

If you think the answer is “Hi, Sasha!Whats up?” then keep reading 🙂

How finally() works under the hood

The finally method doesn't have its own low-level implementation in the Promise specification.

Under the hood, it simply delegates to then, using the same callback for both success and failure:

promise.finally(onDone);
// is roughly equivalent to
promise.then(onDone, onDone);

Because of this onDone doesn’t receive any arguments (no resolved value, no rejection reason)

And what happens to the parameter value which wasn’t passed? Correct: it stays undefined.

Correct answer to the quiz is “undefinedWhats up?“ as res value is undefined.

What happens to the Promise value after `finally()`?

Another quiz:

myPromise.then(() => "Hi, Sasha!")
.finally(res => "my new result")
.then(res => console.log(res)) //what will be logged here?

The answer is "Hi, Sasha!"

The value returned from finally() is simply ignored.

This is a key rule: finally() doesn’t change Promise’s state.

It exists for side effects only - cleanup logic, metrics, etc.

Why the returned value from `finally()` is ignored

finally() doesn’t receive the resolved value
it can’t pass a new value down the chain
the Promise continues with the value from the last then() or catch()

So this:

.finally(() => "new value")

is effectively the same as:

.finally(() => {})

Takeaways so far

Since finally() doesn't get any arguments, any value given to it stays undefined.
The return value from a finally() callback is ignored and doesn't change the Promise's state or the next then() chain
The Promise keeps the value from the last then() or catch() before finally() was called.

Can `finally()` change the Promise state?

Promise.resolve("OK")
  .finally(() => {
    throw new Error("Something went wrong");
  })
  .then((res) => console.log(res))
  .catch((err) => console.log(err));

//what is the Promise state at this point?
//what will be logged? "OK" or "Something went wrong"?

At first glance, you might expect "OK".

After all, we already know that finally() doesn’t change a Promise’s value, right?

But in this case, the output will be “Something went wrong” and the Promise ends up rejected.

Why does this happen?

The important clarification is this:

finally() does not change a Promise’s state by default.

However, if an error is thrown inside finally(), or if it returns a rejected Promise, that error overrides the previous state.

Here is another quick quiz:

Promise.resolve("OK")
  .finally(() => {
    return Promise.reject("Something went wrong")
  })
  .then((res) => console.log(res))
  .catch((err) => console.log(err));

//what is the Promise state at this point?
//what will be logged? "OK" or "Something went wrong"?

We are not throwing any error here. However, we are still getting the "Something went wrong" here.

Another way to change a Promise’s state is to return a rejected Promise from finally().

The takeaway we had previously is that the return value from a finally() callback is ignored, so why returning rejected Promise work?

Let’s investigate what happens under the hood.

Remember how finally() works?

promise.finally(onDone);
// is roughly equivalent to
promise.then(onDone, onDone);

Knowing that, let’s investigate our case:

Promise.resolve("OK")
  .finally(() => {
    return Promise.reject("Something went wrong")
  })
  .then((res) => console.log(res))
  .catch((err) => console.log(err));

//is roughly the same as:


Promise.resolve("OK")
//this is our finally method
.then(

// first onDone callback
  value => Promise.resolve(
    (() => { return Promise.reject("Something went wrong"); })()
  ).then(() => value), // if resolves, continue with the previous value

// second onDone callback
  reason => Promise.resolve(
    (() => { return Promise.reject("Something went wrong"); })()
//throwing error
  ).then(() => { throw reason; }) // if gets rejected, continue with rejection reason as value
)
.then(res => console.log(res)) //this is ignored 
.catch(err => console.log(err)); //this is called

Remember that throwing error changes Promise’s state?

This is what is done behind the scenes when we return a rejected Promise.

Note that if you return a new resolved promise from finally(), nothing changes. The chain waits for it to resolve, and then() continues with the original value.

Final takeaways

Since finally() doesn't receive any arguments, any value provided to it remains undefined.
The return value from a finally() callback is ignored and does not alter the Promise's state or affect the subsequent then() chain.
The Promise retains the value from the last then() or catch() before finally() was invoked, unless:
- The method returns a rejected Promise.
- An error is thrown within the method.

DEV Community: Aleksandra Dudkina

map vs forEach in JavaScript: The Difference Nobody Talks About (Until It Breaks You in an Interview)

The Basics: What's the Key Difference?

map() - transforms data

forEach() - just runs code

Why map() is Used in React Lists

Why map() Is Perfect for Chaining

Final recap on basics:

The Part Nobody Talks About: Empty Slots

Why This Matters: My Interview Story

Recap

Rest Parameters and arguments object: A Quick JavaScript Guide

Why do we even need it

Arguments Object Usage

Rest Parameters Usage

Don't confuse rest parameters with spread

Rest Parameters

Spread Operator

Rest Parameters vs arguments key differences

JWT Authentication in React: Guide to Access Tokens & Refresh Tokens

What Are Access Tokens and Refresh Tokens? (And Why You Need Both)

How to Decode a JWT Token

Token Storage Considerations

Access Token Usage

How the Refresh Token Flow Works (and How to Implement It)

Protected routes and handling user authorisation states

Using Route Loaders for Auth Checks (No Page Flicker)

Handling JWT Auth with WebSockets

Recap

finally() in JavaScript: Why It Can't (Usually) Change a Promise's Result

finally(): Why It Can’t Change a Promise Result

finally() doesn’t receive arguments

How finally() works under the hood

What happens to the Promise value after finally()?

Why the returned value from finally() is ignored

Takeaways so far

Can finally() change the Promise state?

Why does this happen?

Final takeaways

`map()` - transforms data

`forEach()` - just runs code

Why `map()` is Used in React Lists

Why `map()` Is Perfect for Chaining

Rest Parameters vs `arguments` key differences

`finally()`: Why It Can’t Change a Promise Result

`finally()` doesn’t receive arguments

What happens to the Promise value after `finally()`?

Why the returned value from `finally()` is ignored

Can `finally()` change the Promise state?