DEV Community: Aleksandra Dudkina

React Children vs Slots: When to Use Each Pattern?

Aleksandra Dudkina — Sat, 19 Sep 2026 16:43:00 +0000

For a long time, when I needed to make a React component flexible, my first thought always was:

Just pass everything through children.

And in many cases, that's exactly what you should do.

But once a component has several places where custom content can go, children can become a little too generic.

That's where the slot pattern becomes useful.

The confusing part is that React doesn't actually have a built-in Slot concept like some other frameworks do.

So what do people mean when they talk about slots in React?

Let's compare.

`children`: one place for any content

The most basic composition pattern in React is children.

type CardProps = {
  children: React.ReactNode;
};

function Card({ children }: CardProps) {
  return <div className="card">{children}</div>;
}

Then we can put anything inside:

<Card>
  <h2>Profile</h2>
  <p>Some information about the user</p>
</Card>

React passes everything between <Card> and </Card> through the children prop.

I usually think of children as:

Here is one area of the component. Put whatever you want inside it.

This works really well for things like:

cards
modals
layout wrappers
providers
containers

But what if the component has several separate customizable areas?

What if I need more than one `children`?

Imagine a modal:

<Modal>
  ...
</Modal>

It might have:

a title
main content
a footer
actions

Technically, we could put everything into children:

<Modal>
  <h2>Delete account?</h2>

  <p>This action cannot be undone.</p>

  <div>
    <Button>Cancel</Button>
    <Button>Delete</Button>
  </div>
</Modal>

This is fine if Modal doesn't need to know anything about that structure.

But sometimes it does.

Maybe the modal needs to render the title in one container, the content in another and the actions inside a sticky footer.

Then a single children prop is not very convenient.

Slots are basically named places for content

One common React version of the slot pattern is simply passing React nodes through different props.

type ModalProps = {
  title: React.ReactNode;
  children: React.ReactNode;
  footer?: React.ReactNode;
};

function Modal({ title, children, footer }: ModalProps) {
  return (
    <div className="modal">
      <header>{title}</header>

      <main>{children}</main>

      {footer && <footer>{footer}</footer>}
    </div>
  );
}

Now usage looks like this:

<Modal
  title="Delete account?"
  footer={
    <>
      <Button>Cancel</Button>
      <Button>Delete</Button>
    </>
  }
>
  <p>This action cannot be undone.</p>
</Modal>

Here:

children is the main content
title is one slot
footer is another slot

So, at least conceptually:

children is an unnamed/default slot, while slots give different pieces of content explicit destinations.

There is no special React syntax involved.

They're just props containing React nodes.

Why not use props for everything?

We could go even further:

<Modal
  title="Delete account?"
  description="This action cannot be undone."
  cancelText="Cancel"
  confirmText="Delete"
/>

And sometimes that's better.

The difference is that ordinary data props describe what the component should render, while slots usually let the consumer provide the actual UI.

For example:

footer={<CustomActions />}

gives much more freedom than:

confirmText="Delete"

Neither approach is always better.

It depends on how much control the component should expose.

Slots can make the API clearer

Let's imagine a component with several visual areas.

With generic children, I might need to invent additional wrappers:

<Card>
  <CardHeader>
    <h2>Settings</h2>
  </CardHeader>

  <CardContent>
    ...
  </CardContent>

  <CardFooter>
    <Button>Save</Button>
  </CardFooter>
</Card>

This is the compound component pattern, which is another common way to implement slot-like APIs.

Alternatively, I could make the slots explicit:

<Card
  header={<h2>Settings</h2>}
  footer={<Button>Save</Button>}
>
  ...
</Card>

Both APIs represent roughly the same idea:

This component has several predefined places where custom content can be inserted.

Which one I choose usually depends on the complexity of the component.

For something small, named props are often simpler.

For a larger component with many related parts, compound components can feel more natural.

A slot doesn't have to contain JSX

Another thing that confused me at first was thinking that every customizable area should be a ReactNode.

Sometimes a render function is more useful.

For example:

<List
  items={users}
  renderItem={(user) => (
    <UserCard user={user} />
  )}
/>

renderItem is not technically the same API as:

item={<UserCard />}

because the component passes data back to us.

But conceptually, it's solving a similar composition problem:

The library controls where something is rendered, while I control what gets rendered there.

You'll see this pattern a lot in component libraries.

So when do I use `children`?

I usually prefer children when the component has one obvious content area.

For example:

<Popover>
  <SettingsForm />
</Popover>

or:

<PageLayout>
  <Dashboard />
</PageLayout>

It's simple, familiar and doesn't add unnecessary API.

When do slots make more sense?

Slots become more useful when a component has several independent customizable areas.

For example:

<Page
  header={<Header />}
  sidebar={<Navigation />}
  footer={<Footer />}
>
  <Content />
</Page>

In this case, trying to put everything into a single children prop would probably make the API less explicit.

Slots also make sense when the component needs to control where each piece is rendered.

`children` vs slots

`children`	Slots
One default content area	Multiple named content areas
Built into React	A composition pattern
Passed through `props.children`	Usually implemented with props or compound components
Great for wrappers and containers	Great for structured reusable components
Parent mostly provides content	Component controls where each piece goes

And the important part:

They're not really competing concepts.

children can actually be one of the slots.

For example:

function Modal({
  title,
  children,
  footer,
}: ModalProps) {
  return (
    <>
      <header>{title}</header>
      <main>{children}</main>
      <footer>{footer}</footer>
    </>
  );
}

Here children is simply the default slot.

Final takeaway

React gives us children, but "slots" are mostly a pattern we build on top of React's normal composition model.

If my component has one customizable area, I usually reach for children.

If it has several distinct areas, I start thinking about named slots:

header
sidebar
footer
actions

or compound components:

<Card.Header />
<Card.Content />
<Card.Footer />

The goal isn't to use the more sophisticated pattern.

It's to make the component API obvious.

If I have to open the component implementation just to understand where my children will end up, that's usually a sign that the API could be clearer.

How I Choose a Library Before Adding It to a Project

Aleksandra Dudkina — Tue, 15 Sep 2026 13:47:02 +0000

Downloads, maintenance, framework support, API, styling and the one thing I really don't want to do - reverse-engineer a library just to use it

When I started working with frontend libraries, my selection process was pretty simple:

Google the problem
Find a library that seems to solve it
npm install
Start coding

And sometimes this works perfectly.

But the more libraries I used in real projects, the more I realised that installing one is the easy part.

The real question is:

Will I still be happy with this library several months later?

A library might look perfect from the README and still become painful once you discover that it hasn't been updated for two years, doesn't properly support your React version, exposes an API that doesn't fit your use case, or is almost impossible to customise.

So now, before adding a new library to a project, I usually check a few things first.

1. How many downloads does it have?

One of the first places I go is npm.

Weekly downloads are not a guarantee that a library is good, but they give me a rough idea of how widely it is used.

My very approximate scale looks like this:

Weekly downloads	How I interpret it
1M+	Very widely used
100k–1M	Well established
10k–100k	Totally reasonable, especially for a niche library
<10k	I want to investigate more before adding it

These numbers are not strict rules.

A very specific library might only have 5,000 weekly downloads and still be the best solution for its particular problem.

A new library might also be technically much better than an older one with millions of downloads.

And downloads don't necessarily mean that millions of developers intentionally selected this package. Some packages are installed as dependencies of other packages.

So I don't use downloads as:

low downloads = bad library

I use them more as:

low downloads = I should probably check the rest of the signals more carefully.

The more important or deeply integrated the dependency will be, the more cautious I am.

For example, I care much more about this when choosing a table library, router or state-management solution than when installing a tiny helper package.

2. When was the latest version released?

The next thing I check is the date of the latest release.

A library can have millions of downloads but still be practically abandoned.

As a very rough benchmark, I think about it like this:

updated during the last 3 months → great
3–6 months ago → completely normal
6–12 months ago → I start checking the repository
more than a year ago → I want to understand why

Again, this doesn't automatically mean:

no releases for a year = dead library

Some libraries are simply mature.

If a small utility has been stable for years and the JavaScript API it depends on hasn't changed, there might genuinely be nothing to release.

But for something tightly connected to React, bundlers, browser APIs or other actively changing tools, a long period without releases makes me more suspicious.

At this point I usually open GitHub and check:

Are there recent commits?
Are pull requests being merged?
Are maintainers answering issues?
Are new React / TypeScript versions mentioned?
Is there a huge queue of old unresolved bugs?

The last release date alone doesn't tell the full story.

A library released six months ago with active maintainers can be healthier than a library that published a tiny patch yesterday but has 500 ignored issues.

3. Does it actually support my framework?

This sounds obvious, but I have learned not to assume it.

In my case, I'm mostly working with React.

So if I'm evaluating a library, I want to know:

Does it explicitly support React?
Which React versions?
Does it have a React-specific package?
Are there React examples in the documentation?
Does the documentation use current React patterns?

For example, seeing:

npm install some-library

is not enough for me.

I want to see something like:

import { SomeComponent } from "some-library/react";

export function MyComponent() {
  return <SomeComponent />;
}

Even better if there is a dedicated React section explaining the integration.

I also check peerDependencies when compatibility matters.

If I'm using React 19 and the package declares:

{
  "peerDependencies": {
    "react": "^17 || ^18"
  }
}

I wouldn't immediately reject it, but I would investigate before putting it into production.

Maybe React 19 works perfectly and they simply haven't updated the peer dependency yet.

Or maybe there is a real compatibility problem.

I prefer knowing this before I've built half a feature around the library.

4. What does the API actually look like?

A library can solve exactly the problem I have and still expose an API I don't want to work with.

Before installing it, I try to understand how I would implement my actual use case.

Not the easiest example from the documentation.

My use case.

Let's say I'm choosing a table library.

I might need:

sorting
filtering
column resizing
row selection
virtualisation
controlled state
custom cells

I want to understand whether these are first-class features or whether I will have to fight the library.

I usually look through:

exported components
hooks
methods
callbacks
configuration options
controlled / uncontrolled state
TypeScript types

For example, there is a big difference between an API like:

<Table
  data={data}
  columns={columns}
  onRowSelect={setSelectedRows}
/>

and one where implementing the same behaviour requires several adapters, custom plugins and undocumented internal methods.

That doesn't necessarily make the second library bad.

Sometimes more complex APIs give you much more control.

But I want to understand that trade-off before choosing it.

Another thing I check is whether the API matches how I expect the feature to evolve.

Maybe today I only need a simple date picker.

But I already know that soon I will probably need:

ranges
disabled dates
localisation
controlled state
custom input
custom calendar cells

If the library supports only my current simplest scenario, I might have to replace it very soon.

5. Can I customise the styles?

This depends a lot on the project.

Sometimes the default UI is completely fine.

Sometimes I need the component to look exactly like our design system.

In the second case, styling becomes one of the most important criteria.

Before choosing the library I check whether I can use:

className
inline style
CSS variables
data-* attributes
custom components
render props
theme configuration

I also want to understand how difficult overriding the default styles will be.

If changing a simple border requires:

.some-library-wrapper
  .some-library-container
  .some-library-component
  .some-library-inner-element {
  border: none !important;
}

that's already a warning sign 🙂

This is one of the reasons I often like headless or primitive-based libraries.

They might require more work initially, but they usually give much more control over the final UI.

Of course, this isn't always necessary.

If I'm building an internal admin panel and the library's default design is acceptable, full styling control might not matter at all.

The important thing is to check it before choosing the library if customisation is part of the requirements.

6. How good is the documentation?

This is probably one of the most important things for me.

Because eventually something will not work.

And at that moment I don't want my only option to be:

Open library's repository and start investigating the source code.

I don't expect documentation to explain every possible edge case.

Sometimes reading library source code is actually useful.

But I don't want it to be required for basic usage.

Good documentation for me usually has:

a clear getting started guide
API reference
examples
TypeScript examples
explanations of configuration options
framework-specific documentation
migration guides between major versions
examples for less obvious use cases

One thing I particularly like is when documentation explains why something works a certain way instead of only showing code.

For example:

<Component option={true} />

is useful.

But:

option enables controlled behaviour and should be used together with onChange

is much more useful.

I also search the docs for the exact feature I need.

If the library says it supports custom rendering, but searching for “custom rendering” gives me one two-line example with no explanation, I know I might spend more time exploring the repository later.

My rule is roughly:

Reading the source code for a complex edge case is fine.

Reading the source code just to understand the public API is not.

What I don't treat as a deal-breaker

There are a few things I try not to judge in isolation.

Low npm downloads

Fine for a niche or relatively new package.

No release for several months

Fine if the library is stable and the repository is still maintained.

Small GitHub community

Fine if the maintainers are active and the project is focused.

Complex API

Fine if the problem itself is complex and the API gives me the flexibility I need.

This is why I don't really have one metric like:

If the package has less than X downloads, don't use it.

Choosing a dependency is more about putting all the signals together.

Final checklist

Before adding a library, I usually investigate:

How many weekly npm downloads does it have?
When was the last version released?
Is the repository still actively maintained?
Does it support my framework and its current version?
Is there framework-specific documentation?
Does the API cover the use cases I actually need?
Can I customise the styles if necessary?
Are the docs detailed enough?
If something goes wrong, will I be able to understand how the library works without reverse-engineering the whole repository?

Final takeaway

Choosing a library isn't only about:

npm install

and getting the first example working.

The dependency becomes part of your project.

Other developers will need to work with it. You may need to update it. Requirements will change. Bugs will happen.

So I try to choose libraries not only based on whether they solve the problem today, but also on whether I expect them to remain comfortable to work with later.

Because replacing a library after one quick experiment is easy.

Replacing it after it has spread through half of your application is a very different task.

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

React Children vs Slots: When to Use Each Pattern?

children: one place for any content

What if I need more than one children?

Slots are basically named places for content

Why not use props for everything?

Slots can make the API clearer

A slot doesn't have to contain JSX

So when do I use children?

When do slots make more sense?

children vs slots

Final takeaway

How I Choose a Library Before Adding It to a Project

1. How many downloads does it have?

2. When was the latest version released?

3. Does it actually support my framework?

4. What does the API actually look like?

5. Can I customise the styles?

6. How good is the documentation?

What I don't treat as a deal-breaker

Low npm downloads

No release for several months

Small GitHub community

Complex API

Final checklist

Final takeaway

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

`children`: one place for any content

What if I need more than one `children`?

So when do I use `children`?

`children` vs slots

`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?