Rami Chabchoub's Blog

JavaScript Primer

Rami Chabchoub — Sun, 08 Jun 2025 00:00:00 GMT

01 String Interpolation

In earlier versions of JavaScript, if we wanted to dynamically create strings, we needed to use the addition operator (+):

```javascript showLineNumbers const userName = 'Mai'; const dynamicString = 'hello ' + userName + '!'; ```

This works alright, but it feels pretty clunky at times, and can lead to bugs (eg. forgetting the space in Hello ).

Modern JavaScript allows us to embed variables and other expressions right inside strings:

```javascript showLineNumbers const dynamicString = `hello ${userName}!`; ```

In order to use string interpolation, we need to use backticks (`).

Strings created with backticks are known as "template strings". For the most part, they function just like any other string, but they have this one super-power: they can embed dynamic segments.

We create a dynamic segment within our string by writing ${}. Anything placed between the squiggly brackets will be evaluated as a JavaScript expression.

This means that we can do fancy things like this:

```javascript showLineNumbers const age = 7; console.log(`Next year, you'll be ${age + 1} years old.`); ```

This creates the string "Next year, you'll be 8 years old.".

02 Arrow Functions

Historically, functions in JavaScript have been written using the function keyword:

```javascript showLineNumbers function exclaim(string) { return string + '!'; } ```

In 2015, the language received an alternative syntax for creating functions: arrow functions. They look like this:

```javascript showLineNumbers const exclaim = string => string + '!'; ```

Arrow functions are inspired by lambda functions from other functional programming languages. Their main benefit is that they're much shorter and cleaner. Reducing "function clutter" may seem like an insignificant benefit, but it can really help improve readability when working with anonymous functions. For example:

```javascript showLineNumbers const arr = ['hey', 'ho', 'let\'s go'];

// This: arr .map(function(string) { return string + '!' }) .join(' ');

// …Becomes this: arr .map(string => string + '!') .join(' ');

</CodeBlock>

## Rules of arrow functions

Arrow functions might seem straightforward at first glance, but there are a few "gotchas" to be aware of. It's super common for folks to get tripped up by some of these rules.

## Short-form vs. long-form

There are two types of arrow functions: short-form and long-form.

Here's the short-form:

<CodeBlock title="short-form-arrow">
```javascript showLineNumbers
const add1 = n => n + 1;

And here's the long-form:

```javascript showLineNumbers const add1 = n => { return n + 1; }; ```

We opt into the long form by adding curly braces ({ }) around the function body.

The fundamental difference between the two forms is this:

The short-form function's body must be a single expression. That expression will be automatically returned.
The long-form function's body can contain a number of statements. We need to manually specify the return.

With the short-form, our function body consists of a single expression, and that expression will be returned. This is sometimes called an "implicit" return, because there's no return keyword.

When we add the squiggly brackets ({ }), we create a block of statements. We can put as many statements as we want in there. We need to specify what should be returned using a return statement.

Interestingly, if we try to add the return keyword to the short-form syntax, we'll get a syntax error:

```javascript showLineNumbers const add1 = n => return n + 1; // Uncaught SyntaxError: Unexpected token 'return' ```

Why is this an error? Well, return n + 1 is a statement, not an expression. The short form requires an expression. We're not allowed to put a statement there.

Sometimes, we'll see arrow functions written like this:

const shout = sentence => (
  sentence.toUpperCase()
);

What does it mean when we use parentheses (( )) instead of curly braces ({ })?

Parentheses can be added to help us with formatting. By adding parens, we're able to push the returned expression to a new line. And so, we're still using the short-form "implicit" return structure, but we're restructuring it to make it more readable.

To put it another way, these two functions are identical:

// On multiple lines, with parens:
const shoutWithParens = sentence => (
  sentence.toUpperCase()
);

// Or, in a single line without parens:
const shoutWithoutParens = sentence => sentence.toUpperCase();

Optional parameter parentheses

If an arrow function takes a single parameter, the parentheses are optional:

```javascript showLineNumbers // This is valid: const logUser = user => { console.log(user); }

// This is also valid: const logUser = (user) => { console.log(user); }

</CodeBlock>

The parentheses are mandatory if we have more than 1 parameter:

<CodeBlock title="multiple-parameters">
```javascript showLineNumbers
const updateUser = (user, properties, isAdmin) => {
  if (!isAdmin) {
    throw new Error('Not authorized')
  }

  user.setProperties(properties);
}

The parentheses are also mandatory if we have no parameters:

```javascript showLineNumbers const sayHello = () => console.log('Hello!') ```

Implicitly returning objects

Let's suppose we have a function which returns an object:

```javascript showLineNumbers function makeObject() { return { hi: 5, }; } ```

Something sorta funny happens when we try and convert it to a short-form arrow function:

```javascript showLineNumbers const makeObject = () => { hi: 5 }; ```

There are two ways we could interpret this code:

A short-form arrow function that returns an object, { hi: 5 }
A long-form arrow function with a single statement, hi: 5

The problem is that curly braces ({}) serve two purposes in JavaScript: they're used for object notation, but they're also used to create blocks, like in if statements.

When curly braces follow an arrow (=>), the JS engine assumes we're creating a new block, and so we'll get a syntax error, since hi: 5 is not a valid JS statement.

If we want to implicitly return an object, we need to wrap it in parentheses:

```javascript showLineNumbers const makeObject = () => ({ hi: 5 }); ```

In JavaScript, parentheses can be added around any expression, to change its evaluation order. In this case, we don't care about evaluation order, we just need to make it clear that we're trying to pass an expression.

Similarly, it's common to wrap the short-form expression in parentheses when it's too long to fit on a single line:

```javascript showLineNumbers const matchedItem = items.find(item => ( item.color === 'red' && item.size === 'large' )); ```

We can wrap any expression in parentheses, but we can't wrap a block in parentheses. And so, when we wrap the {} characters in parens, the engine can figure out that we're trying to create an object, not a block.

03 Object Destructuring

Object destructuring offers a sleek way to extract some variables from an object.

Here's a quick example:

```javascript showLineNumbers const user = { name: 'François Bouchard', city: 'Saint-Louis-du-Ha! Ha!', province: 'Québec', country: 'Canada', postalCode: 'A1B 2C3', };

const { name, country } = user;

console.log(name); // 'François Bouchard' console.log(country); // 'Canada'

</CodeBlock>

This is effectively the same thing as doing this:

<CodeBlock title="traditional-property-access">
```javascript showLineNumbers
const name = user.name;
const country = user.country;

We can pluck out as many or as few values as we want.

Renaming extracted values

Consider this situation:

```javascript showLineNumbers const name = 'Hello!';

const user = { name: 'Marie-Hélene Pelletier' };

const { name } = user; // Uncaught SyntaxError: // Identifier 'name' has already been declared

</CodeBlock>

We tried to destructure the `name` property into its own variable, but we run into an issue: there's already a variable called `name`!

In these cases, we can rename the value as we unpack it:

<CodeBlock title="renaming-destructured-values">
```javascript showLineNumbers
const name = 'Hello!';

const user = { name: 'Marie-Hélene Pelletier' };

const { name: userName } = user;

console.log(name); // 'Hello!'
console.log(userName); // 'Marie-Hélene Pelletier'

Default values

Here's a question: what happens if we try to destructure a key from an object which isn't defined?

```javascript showLineNumbers const user = { name: 'Marie-Hélene Pelletier' };

const { status } = user;

console.log(status); // ???

</CodeBlock>

Well, `user.status` isn't defined, and so `status` will be set to `undefined`.

If we want, we can set a default value using the assignment operator:

<CodeBlock title="default-values">
```javascript showLineNumbers
const { status = 'idle' } = user;

if the user object has a status property, that value will be plucked out and assigned to the new status constant. Otherwise, status will be assigned to the string "idle".

In order words, it's a modern version of this:

```javascript showLineNumbers const status = typeof user.status === 'undefined' ? 'idle' : user.status; ```

Destructuring function parameters

Let's suppose we have a function which takes an object as its first parameter:

```javascript showLineNumbers function validateUser(user) { if (typeof user.name !== 'string') { return false; }

if (user.password.length < 12) { return false; }

return true; }

</CodeBlock>

If we wanted, we could destructure these values at the top of the function:

<CodeBlock title="destructuring-inside-function">
```javascript showLineNumbers
function validateUser(user) {
  const { name, password } = user;

  if (typeof name !== 'string') {
    return false;
  }

  if (password.length < 12) {
    return false;
  }

  return true;
}

Using parameter destructuring, we can do this destructuring right in the function parameters:

```javascript showLineNumbers function validateUser({ name, password }) { if (typeof name !== 'string') { return false; }

if (password.length < 12) { return false; }

return true; }

</CodeBlock>

All 3 of these code snippets are equivalent, but many developers enjoy using function parameter destructuring. It's especially popular in React to destructure the props in our components.

## Named arguments

Some languages have "named arguments", where the developer can choose to label the arguments they're passing into a function.

JavaScript doesn't have this feature, and as a result, it can be difficult to understand what role different arguments play.

For example, suppose you're working on a codebase, and you stumble upon this code:

<CodeBlock title="mysterious-arguments">
```javascript showLineNumbers
trackSession(user.id, 5, null);

Why does this function receive a 5 and a null? It's totally mysterious. We'd need to hunt down the file where this function is defined to understand what these values are.

Suppose, though, that trackSession took an object as its only argument.

Then it would look like this:

```javascript showLineNumbers trackSession({ userId: user.id, version: 5, additionalMetadata: null, }); ```

By supplying an object, we effectively have to label each value! This works quite a lot like "named arguments" in other languages!

When I write a function, I'll often use parameter destructuring specifically so that I can pass an object in, rather than a bunch of individual arguments. That way, it's easier to understand what the provided data is.

Default parameter values

Like with typical object destructuring, we can supply default values to be used for parameters.

Here's a quick example:

```javascript showLineNumbers function sendApiRequest({ method = 'GET', numOfRetries }) { // Stuff } ```

When I call this function, I can supply my own value for method:

```javascript showLineNumbers sendApiRequest({ method: 'PUT', numOfRetries: 4 }); ```

…Or, if I want it to be equal to GET, I can omit it entirely:

```javascript showLineNumbers sendApiRequest({ numOfRetries: 4 }); ``` Let's suppose we add default values for both of the properties in our function:

function sendApiRequest({ method = 'GET', numOfRetries = 5 }) {
  // Stuff
}

We then call this function without specifying an argument, since we want to use all of the default values:

sendApiRequest();

Unfortunately, we get an error:

Uncaught TypeError: Cannot read properties of undefined (reading 'method')

Here's the problem: we're destructuring the method and numOfRetries properties from an object, but when we call the sendApiRequest function, we're not providing an object.

Here's another example of the same issue, which might make it clearer:

function sendApiRequest(properties) {
  // `properties` is undefined, and so we'll get the same
  // error when we try and extract values from it:
  const {
    method = 'GET',
    numOfRetries = 5
  } = properties;
}

sendApiRequest();

To solve this problem, we can set a default value for the first parameter, the object we're destructuring from:

function sendApiRequest(
  { method = 'GET', numOfRetries = 5 } = {}
) {
  // Stuff
}

sendApiRequest(); // ✅ No problem!

When we call sendApiRequest without passing in any arguments, the first parameter gets initialized to an empty object. Then, the method and numOfRetries properties are initialized using their default values, since they weren't defined in that empty object.

This stuff gets pretty complex. You certainly don't need to take advantage of all of this modern syntax. I just wanted to let you know that this is an issue you might run into.

04 Property Value Shorthand

Objects in modern JavaScript have a nifty little trick up their sleeve. It's a small thing, but if you're not aware of it, it can cause a lot of confusion.

Suppose we have the following code:

```javascript showLineNumbers const name = 'Ahmed'; const age = 26;

const user = { name: name, age: age, };

console.log(user); // { name: 'Ahmed', age: 26 }

</CodeBlock>

We're creating a user object with two properties, `name` and `age`. We're assigning those properties to variables of the same name.

It does feel a bit redundant, though, doesn't it? We're assigning `name` to `name`, and assigning `age` to `age`.

Modern JavaScript gives us a convenient shorthand we can use in this situation:

<CodeBlock title="property-value-shorthand">
```javascript showLineNumbers
const name = 'Ahmed';
const age = 26;

const user = {
  name,
  age,
};

console.log(user);
// { name: 'Ahmed', age: 26 }

This is known as the property value shorthand. When creating an object, we can omit the values if they share the same name as the property.

The end result is the same, but it's a bit more terse.

05 Array Destructuring

Suppose we have some data that lives in an array, and we want to pluck it out and assign it to a variable.

Traditionally, this has been done by accessing an item by index, and assigning it a value with a typical assignment statement:

```javascript showLineNumbers const fruits = ['apple', 'banana', 'cantaloupe']; const firstFruit = fruits[0]; const secondFruit = fruits[1]; ```

Destructuring assignment offers us a nicer way to accomplish this task:

```javascript showLineNumbers const fruits = ['apple', 'banana', 'cantaloupe']; const [firstFruit, secondFruit] = fruits; ```

The first time you see it, those array brackets before the = look pretty wild.

Here's how I think about it: when the [ ] characters are used after the assignment operator (=), they're used to package items into an array. When they're used before, they do the opposite, and they unpack items from an array:

```javascript showLineNumbers // Packing 3 values into an array: const array = [1, 2, 3];

// Unpacking 3 values from an array: const [first, second, third] = array;

</CodeBlock>

Ultimately, this isn't really a game-changer, but it's a neat little party trick that can tidy things up a bit.

<Update title="Disclaimer">
## Skipping items

What if we only wanted to grab the second item, and not the first? Can we use destructuring assignment in that case?

In fact, we can:

```javascript
const fruits = ['apple', 'banana', 'cantaloupe'];
const [, secondFruit] = fruits;

We've removed firstFruit, but kept the comma. Essentially, we've left a gap where the first variable used to be. If you're familiar with sheet music, you can think of it like a rest.

Technically, we can leave many gaps, picking and choosing the items we want:

const fruits = [
  'apple',
  'banana',
  'cantaloupe',
  'durian',
  'eggplant'
];

const [, secondFruit,,, fifthFruit] = fruits;

console.log(secondFruit); // 'banana'
console.log(fifthFruit); // 'eggplant'

This is an interesting little trick with destructuring assignment, but honestly I don't know if it's a great idea in complex cases like this. It feels simpler to me to use the standard notation:

const secondFruit = fruits[1];
const fifthFruit = fruits[4];

06 JavaScript Modules

For a long time, JavaScript had no built-in module system.

In the early days, we wrote our JavaScript programs in .js files, and loaded them all up via <script> tags in our HTML files. This worked alright, but it meant that every script shared the same environment; variables declared in one file could be accessed in another. It was a bit of a mess.

Several third-party solutions were invented, around 2009-2010. The most popular were RequireJS and CommonJS.

Starting in the mid-2010s, however, JS got its own native module system! And it's pretty cool.

Basic premise

When we work with a JS module system, every file becomes a "module". A module is a JavaScript file that can contain one or more exports. We can pull the code from one module into another using the import statement.

If we don't export a piece of data from one module, it won't be available in any other modules. The only way to share anything between modules is through import/export.

In addition to the code we write in our codebase, we can also import third-party modules like React.

The benefit of this rather complex system is that everything is isolated by default. We have to go out of our way to share data between modules. Imports/exports are the "bridges" between modules, and by strategically placing them, we can make complex programs easier to reason about.

Named exports

Each file can define one or more named exports:

```javascript showLineNumbers export const significantNum = 5;

export function doubleNum(num) { return num * 2; }

</CodeBlock>

In this case, our `data.js` module uses the `export` keyword to make a piece of data, `significantNum`, available to other files.

We're also exporting a function, `doubleNum`. We can export any JavaScript data type, including functions and classes.

In our main file, `index.js`, we're importing both of these exports:

<CodeBlock title="index.js">
```javascript showLineNumbers
import { significantNum, doubleNum } from './data';

Inside the curly braces, we list each of the imports we want to bring in, by name. We don't have to import all of the exports, we can pick just the ones we need.

The string at the end, './data', is the path to the module. We're allowed to omit the .js suffix, since it's implied.

The module system uses a linux-style relative path system to locate modules. A single dot, ., refers to the same directory. Two dots, .., refers to a parent directory.

Export statements

It's conventional to export variables as they're declared, like this:

```javascript showLineNumbers export const significantNum = 5; ```

It's also possible to export previously-declared variables using squiggly brackets, like this:

```javascript showLineNumbers const significantNum = 5;

export { significantNum };

</CodeBlock>

Curiously, this syntax is quite rare — I only recently learned it was possible to do this! When it comes to named exports, it's much more common to export them right when they're declared.

We can also export functions as they're declared, like this:

<CodeBlock title="export-function">
```javascript showLineNumbers
// Produces a named export called `someFunction`:
export function someFunction() { /* ... */ }

Renaming imports

Sometimes, we'll run into naming collisions with named imports:

```javascript showLineNumbers import { Wrapper } from './Header'; import { Wrapper } from './Footer'; // 🚫 Identifier 'Wrapper' has already been declared. ```

This happens because named exports don't have to be globally unique. It's perfectly valid for both Header and Footer to use the same name:

```javascript showLineNumbers // Header.js export function Wrapper() { return

Hello

; }

// Footer.js export function Wrapper() { return

; }

</CodeBlock>

We can rename imports with the `as` keyword:

<CodeBlock title="renaming-imports">
```javascript showLineNumbers
import { Wrapper as HeaderWrapper } from './Header';
import { Wrapper as FooterWrapper } from './Footer';
// ✅ No problems

Within the scope of this module, HeaderWrapper will refer to the Wrapper function exported from the /Header.js module. Similarly, FooterWrapper will refer to the other Wrapper function exported from /Footer.js.

Default exports

There's a separate type of export in JS modules: the default export.

Let's look at an example:

```javascript showLineNumbers const magicNumber = 100;

export default magicNumber;

</CodeBlock>

When it comes to default exports, we always export an expression:

<CodeBlock title="default-export-rules">
```javascript showLineNumbers
// ✅ Correct:
const hi = 5;
export default hi;

// 🚫 Incorrect
export default const hi = 10;

Every JS module is limited to a single default export. For example, this is invalid:

```javascript showLineNumbers const hi = 5; const bye = 10;

export default hi; export default bye; // 🚫 SyntaxError: Too many default exports!

</CodeBlock>

When importing default exports, we don't use squiggly brackets:

<CodeBlock title="importing-default">
```javascript showLineNumbers
// ✅ Correct:
import magicNumber from './data';

// 🚫 Incorrect:
import { magicNumber } from './data';

When we're importing a default export, we can name it whatever we want; it doesn't have to match:

```javascript showLineNumbers // ✅ This works import magicNumber from './data';

// ✅ This also works! import helloWorld from './data';

</CodeBlock>

A lot of these differences might seem arbitrary or confusing, but they all stem from this fact: Every module can have multiple named exports, but only a single default export.

For example, we need to use the correct name when importing a named export because we need to specify which export we want! But because there's only a single default export, we can name it whatever we want, there's no ambiguity.

## When to use which

Now that we've covered the fundamentals about named and default exports, you might be wondering: when should I use each type?

In fact, this is a question with no objectively "correct" answer. It all comes down to picking a convention that works for you.

For example, let's say that we have a file that holds a bunch of theme constants (colors and sizes and fonts and stuff). We could structure it like this:

<CodeBlock title="theme-default-export">
```javascript showLineNumbers
const THEME = {
  colors: {
    red: 'hsl(333deg 100% 45%)',
    blue: 'hsl(220deg 80% 40%)',
  },
  spaces: [
    '0.25rem',
    '0.5rem',
    '1rem',
    '1.5rem',
    '2rem',
    '4rem',
    '8rem',
  ],
  fonts: {
    default: '"Helvetica Neue", sans-serif',
    mono: '"Fira Code", monospace',
  },
}

export default THEME;

Or, we could use named exports:

```javascript showLineNumbers export const COLORS = { red: 'hsl(333deg 100% 45%)', blue: 'hsl(220deg 80% 40%)', };

export const SPACES = [ '0.25rem', '0.5rem', '1rem', '1.5rem', '2rem', '4rem', '8rem', ];

export const FONTS = { default: '"Helvetica Neue", sans-serif', mono: '"Fira Code", monospace', }

</CodeBlock>

We can use either a single "grouped" default export, or lots of individual named exports. Both of these options are perfectly valid.

Here's a convention I like to follow, though: if a file has one obvious "main" thing, I make it the default export. Secondary things, like helpers and metadata, can be exported using named exports.

For example, a React component might be set up like this:

<CodeBlock title="react-component-example">
```javascript showLineNumbers
// components/Header.js
export const HEADER_HEIGHT = '5rem';

function Header() {
  return (
    <header style={{ height: HEADER_HEIGHT }}>
      {/* Stuff here */}
    </header>
  )
}

export default Header;

The main "thing" in this Header.js file is the Header component, and so it uses the default export. Anything else will use named exports.

07 Array Iteration Methods

One of the novel things about React is that JSX doesn't include any iteration helpers.

In most templating languages, you have custom syntax like {{#each}} to help you iterate through a set of data. In frameworks like Angular and Vue, you have directives like v-for to manage iteration.

React doesn't provide any abstractions here, and so we'll rely on the built-in methods that are part of the JavaScript language, methods like map and filter.

If we can become comfortable with these core methods, we'll have a much easier time doing iteration in React. In this section, we'll learn about some of the most common and useful methods.

forEach

We use forEach when we want to perform some sort of action on every item in an array.

Here's an example:

```javascript showLineNumbers const pizzaToppings = [ 'cheese', 'avocado', 'halibut', 'custard', ];

pizzaToppings.forEach((topping) => { console.log(topping); });

</CodeBlock>

In this example, we're logging the value of each topping, one at a time. Here's what the console output would be:

cheese avocado halibut custard


The `forEach` method accepts a function as its argument. This is commonly known as a callback function.

The term "callback function" refers to a function that we pass to another function. In this case, we write an arrow function that looks like this:

<CodeBlock title="callback-function">
```javascript showLineNumbers
(topping) => {
  console.log(topping);
}

We don't call this function ourselves; instead, we pass it as an argument to the forEach method. The JavaScript engine will call this function for us, supplying the topping argument as it iterates over the array.

Accessing the index

The callback we pass to forEach takes a second optional parameter:

```javascript showLineNumbers const pizzaToppings = [ 'cheese', 'avocado', 'halibut', 'custard', ];

pizzaToppings.forEach((topping, index) => { console.log(index, topping); });

</CodeBlock>

The `index` is the position in the array of the current item, starting from 0. This code would log:

0 cheese 1 avocado 2 halibut 3 custard


## A common format

JavaScript gives us several tools for iterating over the items in an array. We could have used a `for` loop, and it's arguably much simpler. There are no complicated callback functions! So why should we learn about `.forEach`?

Here's the biggest advantage: `forEach` is part of a family of array iteration methods. Taken as a whole, this family allows us to do all sorts of amazing things, like finding a particular item in the array, filtering a list, and much more.

All of the methods in this family follow the same basic structure. For example, they all support the optional `index` parameter we just looked at!

Let's look at another member of this family: the `filter` method.

## filter

Things start to get really interesting with `filter`.

Here's a quick example:

<CodeBlock title="filter-example">
```javascript showLineNumbers
const students = [
  { name: 'Aisha', grade: 89 },
  { name: 'Bruno', grade: 55 },
  { name: 'Carlos', grade: 68 },
  { name: 'Dacian', grade: 71 },
  { name: 'Esther', grade: 40 },
];

const studentsWhoPassed = students.filter(student => {
  return student.grade >= 60;
});

console.log(studentsWhoPassed);
/*
  [
    { name: 'Aisha', grade: 89 },
    { name: 'Carlos', grade: 68 },
    { name: 'Dacian', grade: 71 },
  ]
*/

In many ways, filter is very similar to forEach. It takes a callback function, and that callback function will be called once per item in the array.

Unlike forEach, however, filter produces a value. Specifically, it produces a new array which contains a subset of items from the original array.

Typically, our callback function should return a boolean value, either true or false. The filter method calls this function once for every item in the array. If the callback returns true, this item is included in the new array. Otherwise, it's excluded.

Important to note: The filter method doesn't modify the original array. This is true for all of the array methods discussed in this lesson.

Here's one more example:

```javascript showLineNumbers const nums = [5, 12, 15, 31, 40];

const evenNums = nums.filter(num => { return num % 2 === 0; });

console.log(nums); // Hasn't changed: [5, 12, 15, 31, 40] console.log(evenNums); // [12, 40]

</CodeBlock>

## map

Finally, we have the `map` method. This is the most commonly-used array method, when working with React.

Let's start with an example:

<CodeBlock title="map-example">
```javascript showLineNumbers
const people = [
  { name: 'Aisha', grade: 89 },
  { name: 'Bruno', grade: 55 },
  { name: 'Carlos', grade: 68 },
  { name: 'Dacian', grade: 71 },
  { name: 'Esther', grade: 40 },
];

const screamedNames = people.map(person => {
  return person.name.toUpperCase();
});

console.log(screamedNames);
/*
  ['AISHA', 'BRUNO', 'CARLOS', 'DACIAN', 'ESTHER']
*/

In many ways, map is quite a lot like forEach. We give it a callback function, and it iterates over the array, calling the function once for each item in the array.

Here's the big difference, though: map produces a brand new array, full of transformed values.

The forEach function will always return undefined:

```javascript showLineNumbers const nums = [1, 2, 3];

const result = nums.forEach(num => num + 1);

console.log(result); // undefined

</CodeBlock>

By contrast, `map` will "collect" all the values we return from our callback, and put them into a new array:

<CodeBlock title="map-returns-array">
```javascript showLineNumbers
const nums = [1, 2, 3];

const result = nums.map(num => num + 1);

console.log(result); // [2, 3, 4]

Like filter, map doesn't mutate the original array; it produces a brand-new array.

Also, the new array will always have the exact same length as the original array. We can't "skip" certain items by returning false or not returning anything at all:

```javascript showLineNumbers const people = [ { id: 'a', name: 'Aisha' }, { id: 'b' }, { id: 'c' }, { id: 'd', name: 'Dacian' }, { id: 'e' }, ];

const screamedNames = people.map(person => { if (person.name) { return person.name.toUpperCase(); } });

console.log(screamedNames); /* ['AISHA', undefined, undefined, 'DACIAN', undefined] */

</CodeBlock>

Here's a helpful way to think about `map`: it's exactly like `forEach`, except it "saves" whatever we return from the callback into a new array.

## Accessing the index with map

Like the other methods we've seen, we can pass a second parameter to access the current item's index:

<CodeBlock title="map-with-index">
```javascript showLineNumbers
const people = [
  { name: 'Aisha', grade: 89 },
  { name: 'Bruno', grade: 55 },
  { name: 'Carlos', grade: 68 },
  { name: 'Dacian', grade: 71 },
  { name: 'Esther', grade: 40 },
];

const numberedNames = people.map((person, index) => {
  return `${index}-${person.name}`;
});

console.log(numberedNames);
/*
  ['0-Aisha', '1-Bruno', '2-Carlos', '3-Dacian', '4-Esther']
*/

Additional methods

We've seen 3 of the most common methods here, but there are actually several more that follow this same format, including find (selecting a single item from the array), every (checking if all items in an array fulfill some condition), and reduce (combine all items in the array into a single final value).

You can learn more about these methods on MDN.

08 Truthy and Falsy

Let's consider the following JavaScript statement:

```javascript showLineNumbers const user = { name: 'J. Script', };

if (user.name) { console.log('This user has a name!'); }

</CodeBlock>

We have a user object, and we want to run a `console.log` depending on a condition. The condition is the JavaScript expression `user.name`.

Interestingly, `user.name` isn't a boolean value. The user's name is neither `true` nor `false`. In many programming languages, this would be an illegal operation. How should the language know if some random string is sufficient or not??

In JavaScript, every value is either "truthy" or "falsy". A truthy value is one that counts as `true` when it comes to conditions.

Most values in JavaScript are truthy. It's faster to list all of the falsy values:

- `false`
- `null`
- `undefined`
- `''` (empty string)
- `0` (and related values, like `0.0` and `-0`)
- `NaN`

In the code above, `user.name` is a truthy value, because it's a string with at least 1 character. Every string other than `''` is truthy.

Somewhat surprisingly, `[]` (empty array) and `{}` (empty object) are truthy values, not falsy. This means that every object/array is truthy.

## Converting to boolean

Sometimes, it's beneficial to convert a truthy value into `true`, or a falsy value into `false`.

The most declarative way to do this is to use the `Boolean()` constructor:

<CodeBlock title="boolean-constructor">
```javascript showLineNumbers
Boolean(4); // true
Boolean(0); // false
Boolean([]); // true
Boolean(''); // false

There's another more-common way to convert to boolean. And, if you're not familiar with it, it can look a bit funky:

```javascript showLineNumbers !!4; // true !!0; // false !![]; // true !!''; // false ```

!! isn't actually a JavaScript operator; we're repeating the NOT operator (!) twice.

We can use ! to flip a boolean value:

```javascript showLineNumbers !true; // false !false; // true ```

If we use the ! with a non-boolean value, it will flip a truthy value to false, or a falsy value to true:

```javascript showLineNumbers !4; // false, since 4 is truthy !0; // true, since 0 is falsy ```

We can stack multiple ! operators to flip it back and forth:

```javascript showLineNumbers !4; // false !!4; // true !!!4; // false !!!!4; // true ```

To break down what's going on here: Each ! is evaluated, one at a time. It's as if there were parens around each set, like this:

```javascript showLineNumbers !(!(!4)) ^^ !4 resolves to `false`

!(!false) ^^^^^^ !false resolves to true

!true ^^^^^ !true resolves to false

</CodeBlock>

I'm not sure why `!!` has become the de facto standard way of converting to boolean; the `Boolean()` constructor seems a lot more intuitive to me!

# 09 Logical Operators

If you've been working with JavaScript for a while, you're probably already familiar with the AND operator (`&&`) and the OR operator (`||`):

<CodeBlock title="basic-logical-operators">
```javascript showLineNumbers
const isLoggedIn = true;
const userRole = 'administrator';

if (isLoggedIn && userRole === 'administrator') {
  // This code only runs if BOTH conditions above are truthy
}

There's something that many JavaScript developers don't realize about these operators, however: they also act as control flow operators.

Let's test your knowledge with a quick multiple-choice question: What is the value of result?

```javascript showLineNumbers const myAge = 35; const result = myAge < 50 && myAge; ```

true
false
35
None of the above

It is totally reasonable to expect that the answer would be true:

myAge < 50 resolves to true
myAge resolves to 35, which is a truthy value
If both sides are truthy, the whole thing should evaluate to true, right?

Afraid not! The && operator isn't designed to produce a boolean value. It's designed to resolve to one of the expressions on either side of the operator.

You can think of && like a gate. We're allowed to move through the gate if the left-hand side is truthy.

This becomes clearer when we chain multiple &&s together:

```javascript showLineNumbers const numOfChildren = 4; const parkingHasBeenValidated = true; const signatureOnWaiver = '';

const admissionTicket = numOfChildren && parkingHasBeenValidated && signatureOnWaiver && generateTicket();

</CodeBlock>

The first expression in this chain is `numOfChildren`, which is `4`. This is a truthy value, and so the first `&&` gate is unlocked.

The second expression is `parkingHasBeenValidated`, which is `true`. We move through the second gate.

The third expression, `signatureOnWaiver`, is an empty string (`''`), which is falsy. This means that the third `&&` gate stays locked. We can't go any further. The current expression, `''`, is what gets resolved.

As a result, `admissionTicket` would be assigned `''`. Not `false`.

Let's suppose `signatureOnWaiver` wasn't an empty string:

<CodeBlock title="all-truthy-and-chain">
```javascript showLineNumbers
const numOfChildren = 4;
const parkingHasBeenValidated = true;
const signatureOnWaiver = 'Becky Chambers';

const admissionTicket =
  numOfChildren &&
  parkingHasBeenValidated &&
  signatureOnWaiver &&
  generateTicket();

Now, when we get to the third expression, we get a truthy value (the string "Becky Chambers"). The final gate is unlocked.

Because all of the gates are unlocked, the final expression will be passed along. admissionTicket will be equal to whatever the generateTicket function returns.

Here's how we'd set up exactly the same code, but using if/else instead of logical operators:

```javascript showLineNumbers let admissionTicket;

if (!numOfChildren) { admissionTicket = numOfChildren; } else if (!parkingHasBeenValidated) { admissionTicket = parkingHasBeenValidated; } else if (!signatureOnWaiver) { admissionTicket = signatureOnWaiver; } else { admissionTicket = generateTicket(); }

</CodeBlock>

`admissionTicket` will be assigned to the first falsy expression. If we make it through all of the gates, `admissionTicket` will be assigned to the final expression, whether it's truthy or falsy.

There's one more interesting takeaway here: The `generateTicket` function is only called if we make it through all the gates. In the first example, when `signatureOnWaiver` was falsy, the `generateTicket` function was never called.

This is because of short-circuiting. If one of the expressions before an `&&` operator evaluates to a falsy value, the rest of the expressions are skipped. They won't be executed at all.

Here's a less-complex example:

<CodeBlock title="short-circuiting-example">
```javascript showLineNumbers
false && console.log('I will never run');

Because false is a falsy value, the && gate remains locked, and the console.log never fires. It's the same as if the console.log was within an if statement:

```javascript showLineNumbers if (false) { console.log('I will never run'); } ```

The OR operator

The || operator is exactly like the && operator, with one key difference: || doesn't stop and provide the first falsy value. It stops and provides the first truthy value.

For example:

```javascript showLineNumbers const userImageSrc = null; const teamImageSrc = null; const defaultImageSrc = '/images/cat.jpg';

const src = userImageSrc || teamImageSrc || defaultImageSrc;

</CodeBlock>

We check the first expression, `userImageSrc`, which is `null`. Because it's falsy, the `||` gate is unlocked, and we proceed onwards.

The second expression, `teamImageSrc`, is also `null`, and so the second `||` gate unlocks.

As with `&&`, when we make it to the final item, the final item is provided regardless of whether it's truthy or falsy. And so `src` will be assigned to `defaultImageSrc`.

However, in this case:

<CodeBlock title="or-operator-truthy-example">
```javascript showLineNumbers
const userImageSrc = '/images/my-avatar.png';
const teamImageSrc = null;
const defaultImageSrc = '/images/cat.jpg';

const src = userImageSrc || teamImageSrc || defaultImageSrc;

The first item, userImageSrc, is truthy! Because it's truthy, the first || gate remains locked, and src is assigned to userImageSrc.

Here's how we'd represent this code using if/else:

```javascript showLineNumbers let src;

if (userImageSrc) { src = userImageSrc; } else if (teamImageSrc) { src = teamImageSrc; } else { src = defaultImageSrc; }

</CodeBlock>

# 10 Assignment Vs. Mutation

in progress...

# 11 Rest / Spread

in progress...

# 12 Intervals and Timeouts

in progress...

# 13 Global Events

in progress...

# 14 Async / Await

in progress...

# 15 HTTP Methods

in progress...

# Fetch

in progress...

# 16 HTTP Status Codes

in progress...

Introduction to Laravel InertiaJS ReactJS

Rami Chabchoub — Sat, 07 Jun 2025 00:00:00 GMT

This comprehensive guide will walk you through building a modern web application using Laravel as the backend, Inertia.js as the bridge, and React for the frontend. We'll create a complete product management system from scratch.

Laravel Installation and Setup

Let's start by setting up a new Laravel project. There are several ways to create a Laravel application:

```bash showLineNumbers # Install global laravel installer composer global require laravel/installer

Create a new Laravel project

laravel new introduction

Alternative: using composer

composer create-project laravel/laravel introduction

Run the development server

php artisan serve npm run dev

Run both with single command (using concurrently, open composer.json)

composer dev

</CodeBlock>

The Laravel installer provides various options including Docker Sail and starter kits like Breeze with Blade or Livewire templates.

## Docker Setup with PostgreSQL

For a consistent development environment, let's set up Docker with PostgreSQL. Create a `docker-compose.yml` file in your project root:

<CodeBlock title="docker-compose.yml">
```yaml showLineNumbers
services:
  db:
    image: postgres:17
    container_name: advantryx_introduction_db
    restart: unless-stopped
    environment:
      POSTGRES_DB: advantryx_introduction
      POSTGRES_USER: laravel
      POSTGRES_PASSWORD: password
      POSTGRES_ROOT_PASSWORD: admin
    ports:
      - '5432:5432'
    volumes:
      - postgres_data:/var/lib/postgresql/data
    networks:
      - advantryx_introduction

networks:
  advantryx_introduction:
    driver: bridge

volumes:
  postgres_data:
    driver: local

Database Configuration

Update your .env file with the PostgreSQL database configuration:

```bash showLineNumbers DB_CONNECTION=pgsql DB_HOST=127.0.0.1 DB_PORT=5432 DB_DATABASE=advantryx_introduction DB_USERNAME=laravel DB_PASSWORD=password ```

Start your PostgreSQL container:

```bash showLineNumbers # Start the PostgreSQL container docker-compose up -d

Check if the container is running

docker-compose ps

View container logs

docker-compose logs db

Stop the container when done

docker-compose down

</CodeBlock>

# Laravel Basics and Creating Products with Routes and Controllers

## Understanding Laravel Core Concepts

Before diving into code, let's understand the key Laravel components:

**Models** provide a powerful and enjoyable interface for you to interact with the tables in your database.

**Migrations** allow you to easily create and modify the tables in your database. They ensure that the same database structure exists everywhere that your application runs.

**Controllers** are responsible for processing requests made to your application and returning a response.

## Creating Products with Routes and Controllers

Let's create a Product model with migration, controller, and resource routes:

<CodeBlock title="create-product-model">
```bash showLineNumbers
php artisan make:model Product -mcr

This command creates:

Model: app/Models/Product.php
Migration: database/migrations/xxxx_create_products_table.php
Controller: app/Http/Controllers/ProductController.php
Resource routes (we'll add manually)

Now let's set up the routes:

```php showLineNumbers Route::resource('products', ProductController::class) ->only(['index', 'store']);

// Alternative individual routes: // Route::get('/products', [ProductController::class, 'index'])->name('products.index'); // Route::post('/products', [ProductController::class, 'store'])->name('products.store');

</CodeBlock>

You can verify your routes using these commands:

<CodeBlock title="route-list">
```bash showLineNumbers
php artisan route:list
php artisan route:list --path=products

Let's update the ProductController to return a basic response:

```php showLineNumbers {7, 14, 16} use App\Models\Product; use Illuminate\Http\Request; use Illuminate\Http\Response;

class ProductController extends Controller { /** * Display a listing of the resource. */ public function index(): Response { return response('Hello, World!'); } ... }

</CodeBlock>

Now let's integrate Inertia.js to render React components:

<CodeBlock title="app/Http/Controllers/ProductController.php">
```php showLineNumbers {8, 17}
<?php

namespace App\Http\Controllers;

use App\Models\Product;
use Illuminate\Http\Request;
use Illuminate\Http\Response;
use Inertia\Inertia;

class ProductController extends Controller
{
    /**
     * Display a listing of the resource.
     */
    public function index(): Response
    {
        return Inertia::render('Products/Index');
    }
}

Frontend Setup with Inertia.js and React

Now that we have our backend set up, let's create the React frontend component that will handle product creation.

Creating the Products Index Component

Create the React component that will be rendered by our Inertia controller:

```jsx showLineNumbers import AppLayout from '@/layouts/app-layout'; import InputError from '@/components/input-error'; import { Button } from '@/components/ui/button'; import { Input } from '@/components/ui/input'; import { useForm, Head } from '@inertiajs/react'; import { FormEventHandler } from 'react';

export default function Index() { const { data, setData, post, processing, reset, errors } = useForm({ name: '', });

const submit: FormEventHandler = (e) => {
    e.preventDefault();
    post(route('products.store'), { onSuccess: () => reset() });
};

return (
    <AppLayout>
        <Head title="Products" />

        <div className="mx-auto max-w-2xl p-4 sm:p-6 lg:p-8">
            <form onSubmit={submit}>
                <Input
                    value={data.name}
                    placeholder="Name of the product"
                    onChange={(e) => setData('name', e.target.value)}
                />
                <InputError message={errors.name} className="mt-2" />
                <Button className="mt-4" disabled={processing}>
                    Create
                </Button>
            </form>
        </div>
    </AppLayout>
);

}

</CodeBlock>

This component demonstrates several key Inertia.js and React concepts:

- **useForm hook**: Manages form state, submission, and validation errors
- **Head component**: Sets the page title
- **route() helper**: Generates URLs for named routes
- **Form handling**: Prevents default submission and uses Inertia's post method

## Adding Navigation

To make the products page accessible, let's add it to the sidebar navigation:

<CodeBlock title="resources/js/components/app-sidebar.tsx">
```tsx showLineNumbers {3-7}
// resources/js/components/app-sidebar.tsx
const mainNavItems: NavItem[] = [
    {
        title: 'Products',
        href: '/products',
        icon: Package,
    },
];

This adds a "Products" link to your application's sidebar with a Package icon.

Database Relationships and Eloquent

Now let's set up proper database relationships and implement the store functionality for our products.

Setting Up the Database Migration

First, let's update our products migration to include the necessary fields and foreign key relationships:

```php showLineNumbers {12-15} id(); $table->foreignId('user_id')->constrained()->cascadeOnDelete(); // Shorthand // $table->unsignedBigInteger('user_id'); // $table->foreign('user_id')->references('id')->on('users')->onDelete('cascade'); $table->string('name'); $table->timestamps(); }); } ... }; ```

Implementing the Store Method

Let's update our ProductController to handle product creation with proper validation:

```php showLineNumbers {17, 19-25} namespace App\Http\Controllers;

use App\Models\Product; use Illuminate\Http\RedirectResponse; use Illuminate\Http\Request; use Inertia\Inertia; use Inertia\Response;

class ProductController extends Controller { ... /** * Store a newly created resource in storage. */ public function store(Request $request): RedirectResponse { $validated = $request->validate([ 'name' => 'required|string|max:255', ]);

    $request->user()->products()->create($validated);

    return redirect(route('products.index'));
}

... }

</CodeBlock>

## Setting Up Eloquent Relationships

Now let's define the relationships between User and Product models. Check out the <A href="https://laravel.com/docs/12.x/eloquent-relationships">Eloquent Relationships documentation</A> for more details.

### User Model Relationship

<CodeBlock title="user-model-relationship">
```php showLineNumbers {3, 11-14}
<?php
 ...
use Illuminate\Database\Eloquent\Relations\HasMany;
use Illuminate\Foundation\Auth\User as Authenticatable;
use Illuminate\Notifications\Notifiable;
use Laravel\Sanctum\HasApiTokens;

class User extends Authenticatable
{
 ...
    public function products(): HasMany
    {
        return $this->hasMany(Product::class);
    }
}

Product Model Configuration

```php showLineNumbers class Product extends Model { protected $fillable = ['name']; // protected $guarded = []; // if you want to allow all fields (not recommended) }

</CodeBlock>

## Running Migrations

<CodeBlock title="migration-commands">
```bash showLineNumbers
php artisan migrate
php artisan migrate:rollback

During development, you can add new database fields without creating a new migration file by modifying the existing migration before running it.

You can test your models using Laravel Tinker:

```bash showLineNumbers php artisan tinker App\Models\Product::all(); ```

Displaying Products

Now that we have our database relationships set up, let's implement the functionality to display products with their associated user information.

Updating the Controller to Fetch Products

Let's modify our ProductController to fetch products with their related user data:

```php showLineNumbers {11} Product::with('user:id,name')->latest()->get(), ]); } ... } ```

Adding Product Model Relationship

We need to add the belongsTo relationship in our Product model:

```php showLineNumbers {2, 6-9} belongsTo(User::class); } } ```

Creating the Product Component

Let's create a reusable Product component to display individual products:

```jsx showLineNumbers // resources/js/components/Product.tsx import { User } from 'lucide-react';

export interface ProductProps { id: number; name: string; user: { name: string; }; created_at: string; }

export default function Product(product: ProductProps) { return (

{product.user.name} {new Date(product.created_at).toLocaleString()}

{product.name}

); }

</CodeBlock>

## Updating the Index Page

Now let's update our Products Index page to display the list of products:

<CodeBlock title="updated-index-page">
```jsx showLineNumbers
// resources/js/pages/Products/Index.tsx
import InputError from '@/components/input-error';
import Product, { ProductProps } from '@/components/Product';
import { Button } from '@/components/ui/button';
import { Input } from '@/components/ui/input';
import AppLayout from '@/layouts/app-layout';
import { Head, useForm } from '@inertiajs/react';
import { FormEventHandler } from 'react';

export default function Index({ products }: { products: ProductProps[] }) {
    const { data, setData, post, processing, reset, errors } = useForm({
        name: '',
    });

    const submit: FormEventHandler = (e) => {
        e.preventDefault();
        post(route('products.store'), { onSuccess: () => reset() });
    };

    return (
        <AppLayout>
            <Head title="Products" />

            <div className="mx-auto max-w-2xl p-4 sm:p-6 lg:p-8">
                <form onSubmit={submit}>
                    <Input value={data.name} placeholder="Name of the product" onChange={(e) => setData('name', e.target.value)} />
                    <InputError message={errors.name} className="mt-2" />
                    <Button className="mt-4" disabled={processing}>
                        Create
                    </Button>
                </form>
            </div>
            <div className="mt-6 divide-y rounded-lg bg-white shadow-sm">
                {products.map((product) => (
                    <Product key={product.id} {...product} />
                ))}
            </div>
        </AppLayout>
    );
}

N+1 Query Problems and Solutions

One of the most common performance issues in Laravel applications is the N+1 query problem. Let's understand what it is and how to solve it.

Understanding the N+1 Problem

```php showLineNumbers class ProductController extends Controller { /** * Display a listing of the resource. */ public function index() { $products = Product::latest()->get();

// This will trigger N+1 queries when we access user relationship
// For each product, Laravel will make a separate query to fetch the user
// If you have 100 products, it will make 1 query for products + 100 queries for users = 101 queries
$products->each(function ($product) {
    $product->user;
});

return Inertia::render('Products/Index', [
    'products' => $products,
]);

// With eager loading
// This makes only 2 queries: 1 for products + 1 for all related users
// return Inertia::render('Products/Index', [
//     'products' => Product::with('user:id,name')->latest()->get(),
// ]);

}

</CodeBlock>

## Preventing Lazy Loading in Development

Add this to your AppServiceProvider to detect N+1 problems during development:

<CodeBlock title="prevent-lazy-loading">
```php showLineNumbers
# app/Providers/AppServiceProvider.php
public function boot(): void
{
    // Detect N+1 query problems in development
    // This will throw an exception when lazy loading occurs
    if (app()->environment('local')) {
        Model::preventLazyLoading();
    }
}

Improving Date Display

Let's install and use dayjs for better date formatting:

```bash showLineNumbers npm install dayjs ``` --- ```jsx showLineNumbers // resources/js/components/Product.tsx import dayjs from 'dayjs'; import relativeTime from 'dayjs/plugin/relativeTime';

dayjs.extend(relativeTime);

... {dayjs(product.created_at).fromNow()} ...

</CodeBlock>

## Filtering User-Specific Products

You can also filter products to show only those belonging to the authenticated user:

<CodeBlock title="user-specific-products">
```php showLineNumbers
# get only user products
class ProductController extends Controller
{
    public function index()
    {
        return Inertia::render('Products/Index', [
            'products' => Auth::user()->products()->with('user:id,name')->latest()->get(),
        ]);
    }
}

Editing Products

Now let's implement the ability to edit products with proper authorization to ensure users can only edit their own products.

Adding Update Route

First, let's add the update route to our resource routes:

```php showLineNumbers {4} only(['index', 'store', 'update']) ->middleware(['auth', 'verified']); ... ```

Enhanced Product Component with Editing

Let's update our Product component to include editing functionality:

```jsx showLineNumbers // resources/js/components/Product.tsx import React, { useState } from 'react'; import dayjs from 'dayjs'; import relativeTime from 'dayjs/plugin/relativeTime'; import { MoreHorizontal, User } from 'lucide-react'; import { useForm, usePage } from '@inertiajs/react';

import InputError from '@/components/input-error'; import { Button } from '@/components/ui/button'; import { DropdownMenu, DropdownMenuContent, DropdownMenuItem, DropdownMenuTrigger } from '@/components/ui/dropdown-menu'; import { Input } from '@/components/ui/input'; import { type SharedData } from '@/types';

dayjs.extend(relativeTime);

export interface ProductProps { id: number; name: string; user: { id: number; name: string; }; created_at: string; updated_at: string; }

export default function Product(product: ProductProps) { const { auth } = usePage().props; const [editing, setEditing] = useState(false);

const { data, setData, patch, clearErrors, reset, errors } = useForm({ name: product.name, });

const submit = (e: React.FormEvent) => { e.preventDefault(); patch(route('products.update', product.id), { onSuccess: () => setEditing(false) }); };

return (

{product.user.name} {dayjs(product.created_at).fromNow()} {product.created_at !== product.updated_at && ( · edited )}

{product.user.id === auth.user.id && ( <DropdownMenuItem onClick={() => setEditing(true)}> Edit )}

{editing ? (

<Input value={data.name} onChange={e => setData('name', e.target.value)} className="mt-4" />

Save <Button type="button" variant="ghost" className="mt-4" onClick={() => { setEditing(false); reset(); clearErrors(); }} > Cancel

) : (

{product.name}

)}

); }

</CodeBlock>

## Implementing the Update Controller Method

Now let's implement the update method in our ProductController:

<CodeBlock title="update-controller-method">
```php showLineNumbers
<?php
class ProductController extends Controller
{
/**
 * Update the specified resource in storage.
 */
    public function update(Request $request, Product $product): RedirectResponse
    {
        Gate::authorize('update', $product);
        // if ($product->user_id !== $request->user()->id) {
        //     abort(403, 'Unauthorized action.');
        // }

        $validated = $request->validate([
            'name' => 'required|string|max:255',
        ]);

        $product->update($validated);

        return redirect(route('products.index'));
    }
}

Authorization with Policies

For proper authorization, let's create a policy to control who can update products:

```bash showLineNumbers php artisan make:policy ProductPolicy --model=Product ``` ```php showLineNumbers # app/Policies/ProductPolicy.php class ProductPolicy { /** * Determine whether the user can update the model. */ public function update(User $user, Product $product): bool { return $product->user_id === $user->id; // return $product->user()->is($user); } } ```

Security Testing Example

Here's an example of how you can test authorization without proper Gate protection. This demonstrates why authorization is crucial.

Steps to test:

Open Network Tab in browser
Edit a product that the user owns
Copy the X-XSRF-TOKEN from Request Headers
Run this console command:

```javascript showLineNumbers fetch('/products/11', { // Change to a product ID you don't own method: 'PATCH', headers: { 'Content-Type': 'application/json', 'X-XSRF-TOKEN': 'eyJpdiI6IjRFTy9Ma3Q0Ylc0NUlHRXJMRVcwUVE9PSIsInZhbHVlIjoiR1JoVHVpZithdlFqclArdHExcHdybC83VzJPVzRqbFd3eTJjRFZCUVJmNEhTUENvZXlISW1LTXBIZTdWRU9qaFBKL3VuTWFFOW1saFhYZDRBRnlsSzBBM2dEVGluckpjeUdCU0htZUpHd1FFUFVWT2hiL3JFV0U0anNodzJBZ1YiLCJtYWMiOiI1NjRkYTJhYmFiOWQyOTNmYjQzOGYzZTYyN2IzMjYxZDU0MTc0ZDZjYTcwMGRjMGM3M2JhZWZmODViYjlkNDA4IiwidGFnIjoiIn0=', 'X-Inertia': 'true', 'X-Requested-With': 'XMLHttpRequest', }, body: JSON.stringify({ name: 'HACKED PRODUCT!', }), }); ```

Deleting Products

Finally, let's implement the delete functionality with proper authorization.

Adding Destroy Route

```php showLineNumbers {2} Route::resource('products', ProductController::class) ->only(['index', 'store', 'update', 'destroy']) ->middleware(['auth', 'verified']); ```

Implementing the Destroy Method

```php showLineNumbers {1, 3-5} public function destroy(Product $product): RedirectResponse { Gate::authorize('delete', $product); $product->delete(); return redirect(route('products.index')); } ```

Adding Delete Policy

```php showLineNumbers public function delete(User $user, Product $product): bool { return $this->update($user, $product); } ```

Adding Delete Button to Component

```jsx showLineNumbers {2-4, 7} // resources/js/components/Product.tsx const { data, setData, patch, clearErrors, reset, errors, delete: destroy } = useForm({ name: product.name, });

... <DropdownMenuItem onClick={() => destroy(route('products.destroy', product.id))}>Delete

</CodeBlock>

## Conclusion

You now have a complete Laravel + Inertia.js + React application with:

- ✅ Product creation with validation
- ✅ Product listing with relationships
- ✅ Product editing with authorization
- ✅ Product deletion with security
- ✅ N+1 query optimization
- ✅ Proper database relationships
- ✅ User authentication and authorization

This foundation provides you with all the essential patterns for building modern web applications using this powerful stack.

# Bonus: Laravel Factory and Seeder for Products

Laravel factories and seeders provide a powerful way to generate test data for your application. This is especially useful during development and testing phases.

## Creating Product Factory

Generate a factory for the Product model:

<CodeBlock title="create-factory">
```bash showLineNumbers
php artisan make:factory ProductFactory

Make sure your Product model uses the `HasFactory` trait to enable factory functionality. ```php showLineNumbers {5, 11} namespace App\Models;

use Illuminate\Database\Eloquent\Factories\HasFactory; use Illuminate\Database\Eloquent\Model; use Illuminate\Database\Eloquent\Relations\BelongsTo;

class Product extends Model { use HasFactory;

protected $fillable = ['name'];

public function user(): BelongsTo
{
    return $this->belongsTo(User::class);
}

}

</CodeBlock>

Update the ProductFactory to define how fake products should be generated:

<CodeBlock title="database/factories/ProductFactory.php">
```php showLineNumbers {13-14}
<?php

namespace Database\Factories;

use App\Models\User;
use Illuminate\Database\Eloquent\Factories\Factory;

class ProductFactory extends Factory
{
    public function definition(): array
    {
        return [
            'user_id' => User::inRandomOrder()->first()?->id ?? User::factory(),
            'name' => fake()->words(3, true),
        ];
    }
}

Creating Product Seeder

Generate a seeder to populate your database with sample products:

```bash showLineNumbers php artisan make:seeder ProductSeeder ```

Update the ProductSeeder:

```php showLineNumbers {12} namespace Database\Seeders;

use App\Models\Product; use Illuminate\Database\Seeder;

class ProductSeeder extends Seeder { public function run(): void { Product::factory(50)->create(); } }

</CodeBlock>

## Running Seeders

Add the ProductSeeder to your DatabaseSeeder:

<CodeBlock title="database/seeders/DatabaseSeeder.php">
```php showLineNumbers {11-13}
<?php

namespace Database\Seeders;

use Illuminate\Database\Seeder;

class DatabaseSeeder extends Seeder
{
    public function run(): void
    {
        $this->call([
            ProductSeeder::class,
        ]);
    }
}

Run the seeders to populate your database:

```bash showLineNumbers # Run all seeders php artisan db:seed

Run specific seeder

php artisan db:seed --class=ProductSeeder

Fresh migration with seeding

php artisan migrate:fresh --seed

</CodeBlock>

## Using Factories in Tinker

You can also use factories directly in Tinker for quick testing:

<CodeBlock title="tinker-factories">
```bash showLineNumbers
php artisan tinker

# Create a single product
Product::factory()->create();

# Create 5 products
Product::factory()->count(5)->create();

# Create products for a specific user
Product::factory()->count(3)->create(['user_id' => 1]);

Factories and seeders are essential for maintaining consistent test data across different environments and team members.

Bonus: Laravel Middleware for Authorization

Laravel middleware provides a convenient mechanism for filtering HTTP requests entering your application. Instead of placing authorization logic directly in controllers, middleware offers a cleaner, more reusable approach.

Understanding Middleware

Middleware acts as a bridge between a request and a response. It's like a series of layers that your request must pass through before reaching your application's core logic. Each middleware can examine the request, modify it, or even terminate it entirely.

Creating Custom Middleware

Let's create middleware to ensure users can only access their own products:

```bash showLineNumbers php artisan make:middleware EnsureProductOwnership ```

This creates a new middleware file at app/Http/Middleware/EnsureProductOwnership.php:

```php showLineNumbers {16-22} namespace App\Http\Middleware;

use Closure; use Illuminate\Http\Request; use Symfony\Component\HttpFoundation\Response;

class EnsureProductOwnership { /** * Handle an incoming request. */ public function handle(Request $request, Closure $next): Response { $product = $request->route('product');

    if ($product && $product->user_id !== auth()->id()) {
        abort(403, 'Unauthorized access to product.');
    }

    return $next($request);
}

}

</CodeBlock>

## Registering Middleware in Laravel 12

In Laravel 12, middleware registration has been simplified. Register your middleware in `bootstrap/app.php`:

<CodeBlock title="bootstrap/app.php">
```php showLineNumbers {9-11}
<?php

use Illuminate\Foundation\Application;
use Illuminate\Foundation\Configuration\Exceptions;
use Illuminate\Foundation\Configuration\Middleware;

return Application::configure(basePath: dirname(__DIR__))
    ->withMiddleware(function (Middleware $middleware) {
        $middleware->alias([
            'product.owner' => \App\Http\Middleware\EnsureProductOwnership::class,
        ]);
    })
    ->withExceptions(function (Exceptions $exceptions) {
        //
    })->create();

Applying Middleware to Routes

Now you can apply the middleware to your routes in several ways:

Option 1: Individual Routes

```php showLineNumbers {3-4} Route::resource('products', ProductController::class) ->only(['index', 'store', 'update', 'destroy']) ->middleware(['auth', 'verified']);

Route::middleware('product.owner')->group(function () { Route::patch('/products/{product}', [ProductController::class, 'update'])->name('products.update'); Route::delete('/products/{product}', [ProductController::class, 'destroy'])->name('products.destroy'); });

</CodeBlock>

### Option 2: Route Groups

<CodeBlock title="routes/web.php">
```php showLineNumbers
Route::middleware(['auth', 'verified'])->group(function () {
    Route::get('/products', [ProductController::class, 'index'])->name('products.index');
    Route::post('/products', [ProductController::class, 'store'])->name('products.store');

    Route::middleware('product.owner')->group(function () {
        Route::patch('/products/{product}', [ProductController::class, 'update'])->name('products.update');
        Route::delete('/products/{product}', [ProductController::class, 'destroy'])->name('products.destroy');
    });
});

Option 3: Controller Constructor

```php showLineNumbers {5-8} class ProductController extends Controller { public function __construct() { $this->middleware('product.owner')->only(['update', 'destroy']); }

// ... rest of controller methods

}

</CodeBlock>

## Simplifying Controller Methods

With middleware handling authorization, you can remove the authorization logic from your controller methods:

### Global Middleware

For middleware that should run on every request, add it to the global middleware stack:

<CodeBlock title="global-middleware">
```php showLineNumbers
// bootstrap/app.php
->withMiddleware(function (Middleware $middleware) {
    $middleware->append(\App\Http\Middleware\LogRequests::class);
})

Benefits of Middleware Approach

Separation of Concerns: Authorization logic is separated from business logic
Reusability: Same middleware can be applied to multiple routes
Consistency: Ensures authorization is always checked
Security: Harder to forget authorization checks
Maintainability: Centralized authorization logic
Performance: Can terminate requests early without hitting controllers

Use middleware for cross-cutting concerns like authentication, authorization, logging, and rate limiting. Keep your controllers focused on business logic.

Bonus: Laravel Pail - Real-time Log Monitoring

Laravel Pail allows you to monitor your application's logs in real-time directly from the console. It works with any log driver and provides filtering options.

Installation and Usage

```bash showLineNumbers # Install Laravel Pail composer require laravel/pail

Basic usage

php artisan pail

Verbose output (avoid truncation)

php artisan pail -v

Maximum verbosity with stack traces

php artisan pail -vv

</CodeBlock>

## Example with Logging

Add logging to your ProductController:

<CodeBlock title="ProductController.php">
```php showLineNumbers {5-9}
public function index(): Response
{
    $products = Product::with('user:id,name')->latest()->get();

    Log::info('Products index accessed', [
        'user_id' => auth()->id(),
        'products_count' => $products->count(),
        'products' => $products->toArray()
    ]);

    return Inertia::render('Products/Index', [
        'products' => $products,
    ]);
}

Now monitor your logs in real-time:

```bash showLineNumbers # Monitor all logs with verbose output php artisan pail -v

Filter by specific content

php artisan pail --filter="Products index accessed"

</CodeBlock>

---

# Shadcn Tanstack DataTable:

<CodeBlock title="shadcn datatable">
```jsx showLineNumbers
// resources/js/components/Product.tsx
import { router, useForm, usePage } from '@inertiajs/react';
import {
    ColumnDef,
    ColumnFiltersState,
    flexRender,
    getCoreRowModel,
    getFilteredRowModel,
    getPaginationRowModel,
    getSortedRowModel,
    SortingState,
    useReactTable,
} from '@tanstack/react-table';
import dayjs from 'dayjs';
import relativeTime from 'dayjs/plugin/relativeTime';
import { ArrowUpDown, ChevronLeft, ChevronRight, Edit, Search, Trash2, X, Check } from 'lucide-react';
import { useState } from 'react';

import InputError from '@/components/input-error';
import { Button } from '@/components/ui/button';
import { Input } from '@/components/ui/input';
import { Table, TableBody, TableCell, TableHead, TableHeader, TableRow } from '@/components/ui/table';
import { type SharedData } from '@/types';

dayjs.extend(relativeTime);

export interface ProductProps {
    id: number;
    name: string;
    user: {
        id: number;
        name: string;
    };
    created_at: string;
    updated_at: string;
}

interface ProductsTableProps {
    products: ProductProps[];
}

export default function ProductsTable({ products }: ProductsTableProps) {
    const { auth } = usePage<SharedData>().props;
    const [sorting, setSorting] = useState<SortingState>([]);
    const [columnFilters, setColumnFilters] = useState<ColumnFiltersState>([]);
    const [globalFilter, setGlobalFilter] = useState('');
    const [editingId, setEditingId] = useState<number | null>(null);

    // Form for editing
    const { data, setData, patch, clearErrors, reset, errors } = useForm({
        name: '',
    });

    const startEdit = (product: ProductProps) => {
        setEditingId(product.id);
        setData('name', product.name);
        clearErrors();
    };

    const saveEdit = (productId: number) => {
        patch(route('products.update', productId), {
            onSuccess: () => {
                setEditingId(null);
                reset();
            },
        });
    };

    const cancelEdit = () => {
        setEditingId(null);
        reset();
        clearErrors();
    };

    const columns: ColumnDef<ProductProps>[] = [
        {
            accessorKey: "name",
            header: ({ column }) => {
                return (
                    <Button
                        variant="ghost"
                        onClick={() => column.toggleSorting(column.getIsSorted() === "asc")}
                        className="h-auto p-0 font-medium"
                    >
                        Product Name
                        <ArrowUpDown className="ml-2 h-4 w-4" />
                    </Button>
                )
            },
            cell: ({ row }) => {
                const product = row.original;
                const isEditing = editingId === product.id;

                if (isEditing) {
                    return (
                        <div className="flex items-center space-x-2">
                            <Input
                                value={data.name}
                                onChange={(e) => setData('name', e.target.value)}
                                className="h-8"
                                autoFocus
                            />
                            {errors.name && (
                                <InputError message={errors.name} className="mt-1" />
                            )}
                        </div>
                    );
                }

                return <div className="font-medium max-w-xs truncate">{row.getValue("name")}</div>;
            },
            size: 300,
        },
        {
            accessorKey: "user.name",
            header: "Created By",
            cell: ({ row }) => <div className="text-sm">{row.original.user.name}</div>,
            size: 150,
        },
        {
            accessorKey: "created_at",
            header: ({ column }) => {
                return (
                    <Button
                        variant="ghost"
                        onClick={() => column.toggleSorting(column.getIsSorted() === "asc")}
                        className="h-auto p-0 font-medium"
                    >
                        Created
                        <ArrowUpDown className="ml-2 h-4 w-4" />
                    </Button>
                )
            },
            cell: ({ row }) => {
                const date = row.getValue("created_at") as string;
                return <div className="text-sm text-muted-foreground">{dayjs(date).fromNow()}</div>;
            },
            size: 120,
        },
        {
            id: "actions",
            header: "Actions",
            enableHiding: false,
            cell: ({ row }) => {
                const product = row.original;
                const canEdit = product.user.id === auth.user.id;
                const isEditing = editingId === product.id;

                if (!canEdit) return <div className="w-32"></div>;

                if (isEditing) {
                    return (
                        <div className="flex space-x-2">
                            <Button
                                variant="outline"
                                size="sm"
                                onClick={() => saveEdit(product.id)}
                            >
                                <Check className="h-4 w-4 mr-1" />
                                Save
                            </Button>
                            <Button
                                variant="ghost"
                                size="sm"
                                onClick={cancelEdit}
                            >
                                <X className="h-4 w-4 mr-1" />
                                Cancel
                            </Button>
                        </div>
                    );
                }

                return (
                    <div className="flex space-x-2">
                        <Button
                            variant="outline"
                            size="sm"
                            onClick={() => startEdit(product)}
                        >
                            <Edit className="h-4 w-4 mr-1" />
                            Edit
                        </Button>
                        <Button
                            variant="destructive"
                            size="sm"
                            onClick={() => {
                                if (confirm('Are you sure you want to delete this product?')) {
                                    router.delete(route('products.destroy', product.id));
                                }
                            }}
                        >
                            <Trash2 className="h-4 w-4 mr-1" />
                            Delete
                        </Button>
                    </div>
                );
            },
            size: 200,
        },
    ];

    const table = useReactTable({
        data: products,
        columns,
        onSortingChange: setSorting,
        onColumnFiltersChange: setColumnFilters,
        getCoreRowModel: getCoreRowModel(),
        getPaginationRowModel: getPaginationRowModel(),
        getSortedRowModel: getSortedRowModel(),
        getFilteredRowModel: getFilteredRowModel(),
        onGlobalFilterChange: setGlobalFilter,
        globalFilterFn: 'includesString',
        state: {
            sorting,
            columnFilters,
            globalFilter,
        },
    });

    return (
        <div className="w-full">
            {/* Search Input */}
            <div className="flex items-center py-4">
                <div className="relative max-w-sm">
                    <Search className="absolute left-3 top-1/2 h-4 w-4 -translate-y-1/2 text-muted-foreground" />
                    <Input
                        placeholder="Search products..."
                        value={globalFilter ?? ''}
                        onChange={(event) => setGlobalFilter(String(event.target.value))}
                        className="pl-10"
                    />
                </div>
            </div>

            <div className="rounded-md border bg-white shadow-sm">
                <Table>
                    <TableHeader>
                        {table.getHeaderGroups().map((headerGroup) => (
                            <TableRow key={headerGroup.id} className="border-b">
                                {headerGroup.headers.map((header, index) => {
                                    let className = "text-left font-medium";

                                    // Set specific widths for each column
                                    if (index === 0) className += " w-2/5"; // Product Name - 40%
                                    else if (index === 1) className += " w-1/5"; // Created By - 20%
                                    else if (index === 2) className += " w-1/5"; // Created - 20%
                                    else if (index === 3) className += " w-1/5"; // Actions - 20%

                                    return (
                                        <TableHead key={header.id} className={className}>
                                            {header.isPlaceholder
                                                ? null
                                                : flexRender(
                                                    header.column.columnDef.header,
                                                    header.getContext()
                                                )}
                                        </TableHead>
                                    )
                                })}
                            </TableRow>
                        ))}
                    </TableHeader>
                    <TableBody>
                        {table.getRowModel().rows?.length ? (
                            table.getRowModel().rows.map((row) => (
                                <TableRow
                                    key={row.id}
                                    data-state={row.getIsSelected() && "selected"}
                                    className="border-b hover:bg-gray-50"
                                >
                                    {row.getVisibleCells().map((cell, index) => {
                                        let className = "py-3";

                                        // Set specific widths for each column
                                        if (index === 0) className += " w-2/5"; // Product Name
                                        else if (index === 1) className += " w-1/5"; // Created By
                                        else if (index === 2) className += " w-1/5"; // Created
                                        else if (index === 3) className += " w-1/5"; // Actions

                                        return (
                                            <TableCell key={cell.id} className={className}>
                                                {flexRender(
                                                    cell.column.columnDef.cell,
                                                    cell.getContext()
                                                )}
                                            </TableCell>
                                        )
                                    })}
                                </TableRow>
                            ))
                        ) : (
                            <TableRow>
                                <TableCell
                                    colSpan={columns.length}
                                    className="h-24 text-center text-muted-foreground"
                                >
                                    No products found.
                                </TableCell>
                            </TableRow>
                        )}
                    </TableBody>
                </Table>
            </div>

            {/* Pagination Controls */}
            <div className="flex items-center justify-between space-x-2 py-4">
                <div className="text-sm text-muted-foreground">
                    {table.getFilteredSelectedRowModel().rows.length} of{" "}
                    {table.getFilteredRowModel().rows.length} row(s) selected.
                </div>
                <div className="flex items-center space-x-2">
                    <p className="text-sm font-medium">
                        Page {table.getState().pagination.pageIndex + 1} of{" "}
                        {table.getPageCount()}
                    </p>
                    <div className="flex items-center space-x-2">
                        <Button
                            variant="outline"
                            size="sm"
                            onClick={() => table.previousPage()}
                            disabled={!table.getCanPreviousPage()}
                        >
                            <ChevronLeft className="h-4 w-4" />
                            Previous
                        </Button>
                        <Button
                            variant="outline"
                            size="sm"
                            onClick={() => table.nextPage()}
                            disabled={!table.getCanNextPage()}
                        >
                            Next
                            <ChevronRight className="h-4 w-4" />
                        </Button>
                    </div>
                </div>
            </div>
        </div>
    );
}

```tsx ShowLineNumbers // resources/js/pages/Products/Index.tsx import InputError from '@/components/input-error'; import ProductsTable, { ProductProps } from '@/components/Product'; import { Button } from '@/components/ui/button'; import { Input } from '@/components/ui/input'; import AppLayout from '@/layouts/app-layout'; import { Head, useForm } from '@inertiajs/react'; import { FormEventHandler } from 'react';

export default function Index({ products }: { products: ProductProps[] }) { const { data, setData, post, processing, reset, errors } = useForm({ name: '', });

const submit: FormEventHandler = (e) => {
    e.preventDefault();
    post(route('products.store'), { onSuccess: () => reset() });
};

return (
    <AppLayout>
        <Head title="Products" />

        <div className="mx-auto max-w-2xl p-4 sm:p-6 lg:p-8">
            <form onSubmit={submit} className="flex items-center gap-4">
                <Input value={data.name} placeholder="Name of the product" onChange={(e) => setData('name', e.target.value)} />
                <Button disabled={processing}>Create</Button>
            </form>
            <InputError message={errors.name} className="mt-2" />
        </div>
        <div className="mx-auto mt-6 max-w-7xl px-4 sm:px-6 lg:px-8">
            <ProductsTable products={products} />
        </div>
    </AppLayout>
);

}

</CodeBlock>
---
# Lravel Pagination

<CodeBlock title="ProductController.php">
```php showLineNumbers
public function index(Request $request)
{
    $perPage = $request->get('per_page', 10); // Default 10 items per page

    $products = Product::with('user:id,name')
        ->latest()
        ->paginate($perPage);

    return Inertia::render('Products/Index', [
        'products' => $products,
    ]);
}

--- ```tsx showLineNumbers // resources/js/types/index.d.ts export interface PaginatedData { data: T[]; current_page: number; first_page_url: string; from: number; last_page: number; last_page_url: string; links: PaginationLink[]; next_page_url: string | null; path: string; per_page: number; prev_page_url: string | null; to: number; total: number; }

export interface PaginationLink { url: string | null; label: string; active: boolean; }

</CodeBlock>
---
<CodeBlock title="Product.tsx">
```tsx showLineNumbers {2, 5, 9, 23, 24, 32, 36, 42, 43, 51, 52}
// resources/js/components/Paginat.tsx
import { type SharedData, type PaginatedData } from '@/types';

interface ProductsTableProps {
    products: PaginatedData<ProductProps>;
}

const table = useReactTable({
    data: products.data,
    columns,
    onSortingChange: setSorting,
    onColumnFiltersChange: setColumnFilters,
    getCoreRowModel: getCoreRowModel(),
    getSortedRowModel: getSortedRowModel(),
    getFilteredRowModel: getFilteredRowModel(),
    onGlobalFilterChange: setGlobalFilter,
    globalFilterFn: 'includesString',
    state: {
        sorting,
        columnFilters,
        globalFilter,
    },
    manualPagination: true, // Tell TanStack Table we're handling pagination manually
    pageCount: products.last_page,
});

...

{/* Server-Side Pagination Controls */}
<div className="flex items-center justify-between space-x-2 py-4">
    <div className="text-sm text-muted-foreground">
        Showing {products.from} to {products.to} of {products.total} results
    </div>
    <div className="flex items-center space-x-2">
        <p className="text-sm font-medium">
            Page {products.current_page} of {products.last_page}
        </p>
        <div className="flex items-center space-x-2">
            <Button
                variant="outline"
                size="sm"
                onClick={() => router.get(products.prev_page_url || '')}
                disabled={!products.prev_page_url}
            >
                <ChevronLeft className="h-4 w-4" />
                Previous
            </Button>
            <Button
                variant="outline"
                size="sm"
                onClick={() => router.get(products.next_page_url || '')}
                disabled={!products.next_page_url}
            >
                Next
                <ChevronRight className="h-4 w-4" />
            </Button>
        </div>
    </div>
</div>

Memoization with useMemo, useCallback and React.memo

Rami Chabchoub — Tue, 21 Jan 2025 00:00:00 GMT

Now that we know the most important composition patterns and how they work, it's time to talk about performance some more. More precisely, let's discuss the topic that is strongly associated with improving performance in React, but in reality, doesn't work as we intend to at least half the time we're doing it. Memoization. Our favorite useMemo and useCallback hooks and the React.memo higher-order component. And I'm not joking or exaggerating about half the time by the way. Doing memoization properly is hard, much harder than it seems. By the end of this chapter, hopefully, you'll agree with me. Here you'll learn:

What is the problem we're trying to solve with memoization (and it's not performance per se!).
How useMemo and useCallback work under the hood, and what is the difference between them.
Why memoizing props on a component by itself is an anti-pattern.
What React.memo is, why we need it, and what are the basic rules for using it successfully.
How to use it properly with the "elements as children" pattern.
What is the role of useMemo in expensive calculations.

The problem: comparing values

It's all about comparing values in JavaScript. Primitive values like strings or booleans we compare by their actual value:

```js const a = 1; const b = 1; a === b; // will be true, values are exactly the same ```

With objects and anything inherited from objects (like arrays or functions), it's a different story.

When we create a variable with an object const a = { id: 1 }, the value stored there is not the actual value. It's just a reference to some part of the memory that holds that object. When we create another variable with the same data const b = { id: 1 }, it will be stored in another part of memory. And since it's a different part, the reference to it will also be different.

So even if these objects look exactly the same, the values in our fresh a and b variables are different: they point to different objects in memory. As a result, a simple comparison between them will always return false:

```js const a = { id: 1 }; const b = { id: 1 }; a === b; // will always be false ```

To make the comparison of a === b return true , we need to make sure that the reference in b is exactly the same as the reference in a. Something like this:

```js const a = { id: 1 }; const b = a; a === b; // will be true ```

This is what React has to deal with any time it needs to compare values between re-renders. It does this comparison every time we use hooks with dependencies, like in useEffect for example:

```js const Component = () => { const submit = () => {}; useEffect(() => { // call the function here submit(); // it's declared outside of the useEffect // so should be in the dependencies }, [submit]); return ... } ```

In this example, the submit function is declared outside of the useEffect hook. So if I want to use it inside the hook, it should be declared as a dependency. But since submit is declared locally inside Component , it will be re-created every time Component re-renders. Remember we discussed in Chapter 2. Elements, children as props, and re-renders - a re-render is just React calling the component's functions. Every local variable during that will be re-created, exactly the same as any function in JavaScript. So React will compare submit before and after re-render in order to determine whether it should run the useEffect hook this time. The comparison will always return false since it's a new reference each time. As a result, the useEffect hook will be triggered on every re- render.

useMemo and useCallback: how they work

In order to battle that, we need a way to preserve the reference to the submit function between re-renders. So that the comparison returns true and the hook is not triggered unnecessarily. This is where useMemo and useCallback hooks come in. Both have a similar API and serve a similar purpose: to make sure that the reference in the variable those hooks are assigned to changes only when the dependency of the hook changes. If I wrap that submit in useCallback :

```js const submit = useCallback(() => { // no dependencies, reference won't change between re-renders }, []); } ```

then the value in the submit variable will be the same reference between re-renders, the comparison will return true , and the useEffect hook that depends on it won't be triggered every time:

```js const Component = () => { const submit = useCallback(() => { // submit something here }, []) useEffect(() => { submit(); // submit is memoized, so useEffect won't be triggered on every re-render }, [submit]); return ... } ```

Exactly the same story with useMemo , only in this case, I need to return the function I want to memoize:

```js const submit = useMemo(() => { return () => { // this is out submit function - it's returned from the function that is passed to memo }; }, []); ```

As you can see, there is a slight difference in the API. useCallback accepts the function that we want to memoize as the first argument, while useMemo accepts a function and memoizes its return value. There is also a slight difference in their behavior because of that. Since both hooks accept a function as the first argument, and since we declare these functions inside a React component, that means on every re-render, this function as the first argument will always be re-created. It's your normal JavaScript, nothing to do with React. If I declare a function that accepts another function as an argument and then call it multiple times with an inline function, that inline function will be re- created from scratch with each call.

```js // function that accepts a function as a first argument const func = (callback) => { // do something with this callback here }; // function as an argument - first call func(() => {}); // function as an argument - second call, new function as an argument func(() => {}); ```

And our hooks are just functions integrated into the React lifecycle, nothing more. So in order to return exactly the same reference in the useCallback hook, React does something like this:

```js let cachedCallback; const func = (callback) => { if (dependenciesEqual()) { return cachedCallback; } cachedCallback = callback; return callback; }; ```

It caches the very first function that is passed as an argument and then just returns it every time if the dependencies of the hook haven't changed. And if dependencies have changed, it updates the cache and returns the refreshed function. With useMemo , it's pretty much the same, only instead of returning the function, React calls it and returns the result:

```js let cachedResult; const func = (callback) => { if (dependenciesEqual()) { return cachedResult; } cachedResult = callback(); return cachedResult; }; ```

The real implementation is slightly more complex, of course, but this is the basic idea. Why is all of this important? For real-world applications, it's not, other than for understanding the difference in the API. However, there is this belief that sometimes pops up here and there that useMemo is better for performance than useCallback , since useCallback re-creates the function passed to it with each re-render, and useMemo doesn't do that. As you can see, this is not true. The function in the first argument will be re-created for both of them. The only time that I can think of where it would actually matter, in theory, is when we pass as the first argument not the function itself, but a result of another function execution hardcoded inline. Basically this:

```js const submit = useCallback(something(), []); ```

In this case, the something function will be called every re-render, even though the submit reference won't change. So avoid doing expensive calculations in those functions.

Antipattern: memoizing props

The second most popular use case for memoization hooks, after memoized values as dependencies, is passing them to props. You surely have seen code like this:

```js const Component = () => { const onClick = useCallback(() => { // do something on click }, []); return ; }; ```

Unfortunately, this useCallback here is just useless. There is this widespread belief that even ChatGPT seems to hold, that memoizing props prevents components from re-rendering. But as we know already from the previous chapters, if a component re-renders, every component inside that component will also re-render.

So whether we wrap our onClick function in useCallback or not doesn't matter at all here. All we did was make React do a little more work and make our code a little harder to read. When it's just one useCallback , it doesn't look that bad. But it's never just one, is it? There will be another, then another, they will start depending on each other, and before you know it, the logic in the app is just buried under the incomprehensible and undebuggable mess of useMemo and useCallback .

There are only two major use cases where we actually need to memoize props on a component. The first one is when this prop is used as a dependency in another hook in the downstream component.

```js const Parent = () => { // this needs to be memoized! // Child uses it inside useEffect const fetch = () => {}; return ; }; const Child = ({ onMount }) => { useEffect(() => { onMount(); }, [onMount]); }; ```

This should be self-explanatory: if a non-primitive value goes into a dependency, it should have a stable reference between re-renders, even if it comes from a chain of props.

And the second one is when a component is wrapped in React.memo

What is React.memo

React.memo or just memo is a very useful util that React gives us. It allows us to memoize the component itself. If a component's re-render is triggered by its parent (and only then), and if this component is wrapped in React.memo , then and only then will React stop and check its props. If none of the props change, then the component will not be re- rendered, and the normal chain of re-renders will be stopped.

This is again the case when React performs that comparison we talked about at the beginning of the chapter. If even one of the props has changed, then the component wrapped in React.memo will be re- rendered as usual:

```js const Child = ({ data, onChange }) => {}; const ChildMemo = React.memo(Child); const Component = () => { // object and function declared inline // will change with every re-render return {...}} /> } ```

And in the case of the example above, data and onChange are declared inline, so they will change with every re-render.

This is where useMemo and useCallback shine:

```js const Child = ({ data, onChange }) => {}; const ChildMemo = React.memo(Child); const Component = () => { const data = useMemo(() => ({ ... }), []); // some object const onChange = useCallback(() => {}, []); // some callback // data and onChange now have stable reference // re-renders of ChildMemo will be prevented return } ```

By memoizing data and onChange , we're preserving the reference to those objects between re-renders. Now, when React compares props on the ChildMemo component, the check will pass, and the component won't re-render.

But making sure that all props are memoized is not as easy as it sounds. We're doing it wrong in so many cases! And just one single mistake leads to broken props check, and as a result - every React.memo , useCallback , and useMemo become completely useless.

React.memo and props from props

The first and simplest case of broken memoization is props that are passed from props. Especially when the spreading of props in components in between is involved. Imagine you have a chain of components like this:

```js const Child = () => {}; const ChildMemo = React.memo(Child); const Component = (props) => { return ; }; const ComponentInBetween = (props) => { return ; }; const InitialComponent = (props) => { // this one will have state and will trigger re-render of Component return ( ); }; ```

How likely do you think that those who need to add that additional data to the InitialComponent will go through every single component inside, and deeper and deeper, to check whether any of them is wrapped in React.memo ? Especially if all of those are spread among different files and are quite complicated in implementation. Never going to happen.

But as a result, the InitialComponent breaks the memoization of the ChildMemo component since it passes a non-memoized data prop to it.

So unless you're prepared and able to enforce the rule that every single prop everywhere should be memoized, using the React.memo function on components has to follow certain rules.

Rule 1: never spread props that are coming from other components.

Instead of this:

const Component = (props) => {
return <ChildMemo {...props} />;
};

it has to be something explicit like this:

```js const Component = (props) => { return ; }; ```

Rule 2: avoid passing non-primitive props that are coming from other components.

Even the explicit example like the one above is still quite fragile. If any of those props are non-memoized objects or functions, memoization will break again.

Rule 3: avoid passing non-primitive values that are coming from custom hooks.

This seems almost contradictory to the generally accepted practice of extracting stateful logic into custom hooks. But their convenience is a double-edged sword here: they surely hide complexities away, but also hide away whether the data or functions have stable references as well. Consider this:

```js const Component = () => { const { submit } = useForm(); return ; }; ```

The submit function is hidden in the useForm custom hook. And every custom hook will be triggered on every re-render. Can you tell from the code above whether it's safe to pass that submit to our ChildMemo ?

Nope, you can't. And chances are, it will look something like this:

```js const useForm = () => { // lots and lots of code to control the form state const submit = () => { // do something on submit, like data validation }; return { submit, }; }; ```

By passing that submit function to our ChildMemo , we just broke its memoization - from now on, it will re-render as if it's not wrapped in React.memo.

See how fragile this pattern is already? It gets worse.

React.memo and children

Let's take a look at this code:

```js const ChildMemo = React.memo(Child); const Component = () => { return (

Some text here

); }; ```

Seems innocent enough: a memoized component with no props, renders some div inside, right? Well, memoization is broken here again, and the React.memo wrapper is completely useless.

Remember what we discussed in Chapter 2. Elements, children as props, and re-renders? This nice nesting syntax is nothing more than syntax sugar for the children prop. I can just rewrite this code like this:

```js const Component = () => { return Some text here} />; }; ```

and it will behave exactly the same. And as we covered in Chapter 2. Elements, children as props, and re-renders, everything that is JSX is just syntax sugar for React.createElement and actually just an object. In this case, it will be an object with the type "div":

```bash { type: "div", ... // the rest of the stuff } ```

So what we have here from a memoization and props perspective is a component that is wrapped in React.memo and has a prop with a non- memoized object in it!

In order to fix it, we need to memoize the div as well:

```js const Component = () => { const content = useMemo( () =>

Some text here

, [], ); return ; }; ```

or, back to the pretty syntax:

```js const Component = () => { const content = useMemo( () =>

Some text here

, [], ); return {content}; }; ```

Exactly the same story applies to children as a render prop, by the way. This will be broken:

```js const Component = () => { return ( {() =>

Some text here

} ); }; ```

Our children here is a function that is re-created on every re-render. Also need to memoize it with useMemo :

```js const Component = () => { const content = useMemo( () => () =>

Some text here

, [], ); return {content}; }; ```

Or just use useCallback :

```js const Component = () => { const content = useCallback( () =>

Some text here

, [], ); return {content}; }; ```

Take a look at your app right now. How many of these have slipped through the cracks?

React.memo and memoized children (almost)

If you went through your app, fixed all those patterns, and feel confident that memoization is in a good state now, don't rush. When has life ever been so easy! What do you think about this one? Is it okay or broken?

```js const ChildMemo = React.memo(Child); const ParentMemo = React.memo(Parent); const Component = () => { return ( ); }; ```

Both of them are memoized, so it has to be okay, right? Wrong. ParentMemo will behave as if it is not wrapped in React.memo - its children are actually not memoized! Let's take a closer look at what's happening. As we already know,

Elements are just syntax sugar for React.createElement , which returns an object with the type that points to the component. If I were creating a <Parent /> Element, it would be this:

```bash { type: Parent, ... // the rest of the stuff } ```

With memoized components, it's exactly the same. The <ParentMemo/> element will be converted into an object of a similar shape. Only the "type" property will contain information about our ParentMemo .

And this object is just an object, it's not memoized by itself. So again, from the memoization and props perspective, we have a ParentMemo component that has a children prop that contains a non-memoized object. Hence, broken memoization on ParentMemo .

To fix it, we need to memoize the object itself:

```js const Component = () => { const child = useMemo(() => , []); return {child}; }; ```

And then we might not even need the ChildMemo at all. Depends on its content and our intentions, of course. At least for the purpose of preventing ParentMemo from re-rendering, ChildMemo is unnecessary, and it can return back to being just a normal Child

```js const Component = () => { const child = useMemo(() => , []); return {child}; }; ```

useMemo and expensive calculations

And the final, quite popular performance-related use case for useMemo is memoizing "expensive calculations." In quotes, since it's actually misused quite often as well.

First of all, what is an "expensive calculation"? Is concatenating strings expensive? Or sorting an array of 300 items? Or running a regular expression on a text of 5000 words? I don't know. And you don't. And no one knows until it's actually measured:

on a device that is representative of your user base
in context
in comparison with the rest of the stuff that is happening at the same time
in comparison with how it was before or the ideal state

Sorting an array of 300 items on my laptop, even with a 6x slowed-down CPU, takes less than 2ms. But on some old Android 2 mobile phone, it might take a second.

Executing a regular expression on a text that takes 100ms feels slow. But if it's run as a result of a button click, once in a blue moon, buried somewhere deep in the settings screen, then it's almost instant. A regular expression that takes 30ms to run seems fast enough. But if it's run on the main page on every mouse move or scroll event, it's unforgivably slow and needs to be improved.

It always depends. "Measure first" should be the default thinking when there is an urge to wrap something in useMemo because it's an "expensive calculation."

The second thing to think about is React. In particular, rendering of components in comparison to raw JavaScript calculations. More likely than not, anything that is calculated within useMemo will be an order of magnitude faster than re-rendering actual elements anyway. For example, sorting that array of 300 items on my laptop took less than 2ms. Re-rendering list elements from that array, even when they were just simple buttons with some text, took more than 20ms. If I want to improve the performance of that component, the best thing to do would be to get rid of the unnecessary re-renders of everything, not memoizing something that takes less than 2ms.

So an addition to the "measure first" rule, when it comes to memoization, should be: "don't forget to measure how long it takes to re- render component elements as well." And if you wrap every JavaScript calculation in useMemo and gain 10ms from it, but re-rendering of actual components still takes almost 200ms, then what's the point? All it does is complicate the code without any visible gain.

And finally, useMemo is only useful for re-renders. That's the whole point of it and how it works. If your component never re-renders, then useMemo just does nothing.

More than nothing, it forces React to do additional work on the initial render. Don't forget: the very first time the useMemo hook runs, when the component is first mounted, React needs to cache it. It will use a little bit of memory and computational power for that, which otherwise would be free. With just one useMemo , the impact won't be measurable, of course. But in large apps, with hundreds of them scattered everywhere, it actually can measurably slow down the initial render. It will be death by a thousand cuts in the end.

Key takeaways

Well, that's depressing. Does all of this mean we shouldn't use memoization? Not at all. It can be a very valuable tool in our performance battle. But considering so many caveats and complexities that surround it, I would recommend using composition-based optimization techniques as much as possible first. React.memo should be the last resort when all other things have failed.

And let's remember:

React compares objects/arrays/functions by their reference, not their value. That comparison happens in hooks' dependencies and in props of components wrapped in React.memo .
The inline function passed as an argument to either useMemo or useCallback will be re-created on every re-render.
useCallback memoizes that function itself, useMemo memoizes the result of its execution.
Memoizing props on a component makes sense only when:
- This component is wrapped in React.memo .
- This component uses those props as dependencies in any of the hooks.
- This component passes those props down to other components, and they have either of the situations from above.
If a component is wrapped in React.memo and its re-render is triggered by its parent, then React will not re-render this component if its props haven't changed. In any other case, re- render will proceed as usual.
Memoizing all props on a component wrapped in React.memo is harder than it seems. Avoid passing non-primitive values that are coming from other props or hooks to it.
When memoizing props, remember that "children" is also a non- primitive prop that needs to be memoized.

Practical React Query

Rami Chabchoub — Mon, 15 Jan 2024 00:00:00 GMT

When GraphQL and especially Apollo Client became popular in ca. 2018, there was a lot of fuss about it completely replacing redux, and the question Is Redux dead yet? has beed asked a lot.

I distictly remember not understanding what this was all about. Why would some data fetching library replace your global state manager? What doas one even have to do with the other?

I was under the impression that GraphQL clients like Apollo would only fetch the data for you, similiar to what e.g. axios does for REST, and that you would still obviously need some way of making that data accessible to your application.

I couldn't have been more wrong.

Client State vs. Server State

What Apollo gives you is not just the ability to describe which data you want and to fetch that data, it also comes with a cache for that server data. This means that you can just use the same useQuery hook in multiple components, and it will only fetch data once and then subsequently return it from the cache.

This sounds very familiar with what we, and probably many other teams as well, have mainly been using redux for: Fetch data from the server and make it available everywhere.

So it seems that we have always been treating this server state like any other client state. Except that when it comes to server state (think: A list of articles that you fetch, the details of a User you want to display, ...), your app does not own it. We have only borrowed it to display the most recent version of it on the screen for the user. It is the server who owns the data.

To me, that introduced a paradigm shift in how to think about data. If we can leverage the cache to display data that we do not own, there isn't really much left that is real client state that also needs to be made available to the whole app. That made me understand why many think that Apollo can replace redux in lots of instances.

React Query

I have never had the chance to use GraphQL. We have an existing REST API, don't really experience problems with over-fetching, it just works, etc. Clearly, there aren't enough pain points for us to warrant a switch, especially given that you'd also have to adapt the backend, which isn't quite so simple.

Yet I still envied the simplicity of how data fetching can look like on the frontend, including the handling of loading and error states. If only there were something similar in React for REST APIs...

Enter React Query.

Made by the open sourcerer Tanner Linsley in late 2019, React Query takes the good parts of Apollo and brings them to REST. It works with any function that returns a Promise and embraces the stale-while-revalidate caching strategy. The library operates on sane defaults that try to keep your data as fresh as possible while at the same time showing data to the user as early as possible, making it feel near instant at times and thus providing a great UX. On top of that, it is also very flexible and lets you customize various settings for when the defaults are not enough.

This article is not going to be an introduction to React Query though.

I think the docs are great at explaining Guides & Concepts, there are Videos from various Talks that you can watch, and Tanner has a React Query Essentials Course you can take if you want to get familiar with the library.

I've been working on a brand new course together with ui.dev. If you enjoy the content I've been creating so far, you'll love query.gg.

I want to focus more on some practical tips that go beyond the docs, which might be useful when you are already working with the library. These are things I have picked up over the last couple of months when I was not only actively using the library at work, but also got involved in the React Query community, answering questions on Discord and in GitHub Discussions.

The Defaults explained

I believe the React Query Defaults are very well-chosen, but they can catch you off guard from time to time, especially at the beginning.

First of all: React Query does not invoke the queryFn on every re-render, even with the default staleTime of zero. Your app can re-render for various reasons at any time, so fetching every time would be insane!

Always code for re-renders, and a lot of them. I like to call it render resiliency.

If you see a refetch that you are not expecting, it is likely because you just focused the window and React Query is doing a refetchOnWindowFocus, which is a great feature for production: If the user goes to a different browser tab, and then comes back to your app, a background refetch will be triggered automatically, and data on the screen will be updated if something has changed on the server in the meantime. All of this happens without a loading spinner being shown, and your component will not re-render if the data is the same as you currently have in the cache.

During development, this will probably be triggered more frequently, especially because focusing between the Browser DevTools and your app will also cause a fetch, so be aware of that.

Since React Query v5, `refetchOnWindowFocus` no longer listens to the `focus` event - the `visibilitychange` event is used exclusively. This means you'll get fewer unwanted re-fetches in development mode, while still retaining the trigger for most production cases. It also fixes a bunch of issues as shown here.

Secondly, there seems to be a bit of confusion between gcTime and staleTime, so let me try to clear that up:

staleTime: The duration until a query transitions from fresh to stale. As long as the query is fresh, data will always be read from the cache only - no network request will happen! If the query is stale (which per default is: instantly), you will still get data from the cache, but a background refetch can happen under certain conditions.
gcTime: The duration until inactive queries will be removed from the cache. This defaults to 5 minutes. Queries transition to the inactive state as soon as there are no observers registered, so when all components which use that query have unmounted.Most of the time, if you want to change one of these settings, it's the staleTime that needs adjusting. I have rarely ever needed to tamper with the gcTime. There is a good explanation by example in the docs as well.

`gcTime` was previously known as `cacheTime`, but it got renamed in v5 to better reflect what it's doing.

Use the React Query DevTools

This will help you immensely in understanding the state a query is in. The DevTools will also tell you what data is currently in the cache, so you'll have an easier time debugging. In addition to that, I have found that it helps to throttle your network connection in the browser DevTools if you want to better recognize background refetches, since dev-servers are usually pretty fast.

Treat the query key like a dependency array

I am referring to the dependency array of the useEffect hook here, which I assume you are familiar with.

Why are these two similar?

Because React Query will trigger a refetch whenever the query key changes. So when we pass a variable parameter to our queryFn, we almost always want to fetch data when that value changes. Instead of orchestrating complex effects to manually trigger a refetch, we can utilize the query key:

```typescript showLineNumbers type State = 'all' | 'open' | 'done' type Todo = { id: number state: State } type Todos = ReadonlyArray

const fetchTodos = async (state: State): Promise => { const response = await axios.get(todos/${state}) return response.data }

export const useTodosQuery = (state: State) => useQuery({ queryKey: ['todos', state], queryFn: () => fetchTodos(state), })

</CodeBlock>

Here, imagine that our UI displays a list of todos along with a filter option.
We would have some local state to store that filtering, and as soon as the user changes their selection, we would update that local state, and React Query will automatically trigger the refetch for us, because the query key changes.
We are thus keeping the user's filter selection in sync with the query function, which is very similar to what a dependency array represents for useEffect.
I don't think I have ever passed a variable to the `queryFn` that was not part of the `queryKey`, too.

# A new cache entry

Because the query key is used as a key for the cache, you will get a new cache entry when you switch from 'all' to 'done', and that will result in a hard loading state (probably showing a loading spinner) when you switch for the first time.
This is certainly not ideal, so if possible, we can try to pre-fill the newly created cache entry with <A href="https://tanstack.com/query/latest/docs/framework/react/guides/initial-query-data#initial-data-from-cache">initialData</A>.
The above example is perfect for that, because we can do some client side pre-filtering on our todos:

<CodeBlock title="pre-filtering">
```typescript showLineNumbers {17-26}
type State = 'all' | 'open' | 'done'
type Todo = {
  id: number
  state: State
}
type Todos = ReadonlyArray<Todo>

const fetchTodos = async (state: State): Promise<Todos> => {
  const response = await axios.get(`todos/${state}`)
  return response.data
}

export const useTodosQuery = (state: State) => {
  useQuery({
    queryKey: ['todos', state],
    queryFn: () => fetchTodos(state),
    initialData: () => {
      const allTodos = queryClient.getQueryData<Todos>([
        'todos',
        'all',
      ])
      const filteredData =
        allTodos?.filter((todo) => todo.state === state) ?? []

      return filteredData.length > 0 ? filteredData : undefined
    },
  })

Now, every time the user switches between states, if we don't have data yet, we try to show data from the 'all todos' cache. We can instantly show the 'done' todos that we have to the user, and they will still see the updated list once the background fetch finishes.

I think this is a great ux improvement for just a few lines of code.

Keep server and client state separate

This goes hand in hand with putting-props-to-use-state, an article I have written last month: If you get data from useQuery, try not to put that data into local state. The main reason is that you implicitly opt out of all background updates that React Query does for you, because the state "copy" will not update with it.

This is fine if you want to e.g. fetch some default values for a Form, and render your Form once you have data. Background updates are very unlikely to yield something new, and even if, your Form has already been initialized. So if you do that on purpose, make sure to not fire off unnecessary background refetches by setting staleTime:

```typescript showLineNumbers const App = () => { const { data } = useQuery({ queryKey: ['key'], queryFn, staleTime: Infinity, })

return data ? : null }

const MyForm = ({ initialData }) => { const [data, setData] = React.useState(initialData) ... }

</CodeBlock>

This concept will be a bit harder to follow through when you display data that you also want to allow the user to edit, but it has many advantages.
I have prepared a little codesandbox example:

<IFrame 
  src="https://codesandbox.io/embed/inspiring-mayer-rp3jx?fontsize=14&hidenavigation=1&theme=dark&view=preview"
  height={500}
/>

The important part of this demo is that we never put the value that we get from React Query into local state.
This makes sure that we always see the latest data, because there is no local "copy" of it.

# The enabled option is very powerful

The `useQuery` hook has many options that you can pass in to customize its behaviour, and the `enabled` option is a very powerful one that enables you to do many cool things (pun intended).
Here is a short list of things that we were able to accomplish thanks to this option:

* <A href="https://tanstack.com/query/latest/docs/framework/react/guides/dependent-queries">Dependent Queries</A>

    Fetch data in one query and have a second query only run once we have successfully obtained data from the first query.

* Turn queries on and off

    We have one query that polls data regularly thanks to `refetchInterval`, but we can temporarily pause it if a Modal is open to avoid updates in the back of the screen.

* Wait for user input

    Have some filter criteria in the query key, but disable it for as long as the user has not applied their filters.

* Disable a query after some user input

    e.g. if we then have a draft value that should take precedence over the server data. See the above example.

# Don't use the queryCache as a local state manager

If you tamper with the queryCache (`queryClient.setQueryData`), it should only be for optimistic updates or for writing data that you receive from the backend after a mutation.
Remember that every background refetch might override that data, so <A href="https://react.dev/reference/react/useState">use</A> <A href="https://zustand-demo.pmnd.rs/">something</A> <A href="https://redux.js.org/">else</A> for local state.

# Create custom hooks

Even if it's only for wrapping one `useQuery` call, creating a custom hook usually pays off because:

* You can keep the actual data fetching out of the ui, but co-located with your `useQuery` call.
* You can keep all usages of one query key (and potentially type definitions) in one file.
* If you need to tweak some settings or add some data transformation, you can do that in one place.
* You have already seen an example of that in the todos queries above.

You have already seen an example of that in the <A href="#treat-the-query-key-like-a-dependency-array">todos queries above</A>.

---

I hope that these practical tips will help you to get started with React Query, so go check it out :)

React Native Tech Stack 2025: The Ultimate Guide to Building Modern Mobile Apps

Rami Chabchoub — Fri, 24 Jan 2025 00:00:00 GMT

React Native Tech Stack 2025: The Ultimate Guide

The mobile development landscape in 2025 has evolved significantly, and React Native stands at the forefront of this evolution. As the framework becomes more robust, performant, and stable, choosing the right tools and packages for your project has never been more crucial. This comprehensive guide will help you navigate the vast ecosystem of React Native development and make informed decisions for your next project.

Core Development Setup

When starting a new React Native project in 2025, there are two fundamental choices that form the foundation of your development setup:

Expo Framework

Expo has emerged as the de-facto standard for React Native development in 2025. Here's why you should choose Expo for your next project:

Official Recognition: Expo is now the recommended framework in the React Native documentation
Production Ready: Major companies have adopted Expo for their production applications
Developer Experience: Provides a comprehensive development environment out of the box
Framework Benefits: Avoiding the need to build your own framework from scratch
Migration Friendly: Even legacy projects using the React Native CLI can gradually migrate to Expo

TypeScript Integration

TypeScript has become an essential tool in modern React Native development. Here's why you should embrace it:

Enhanced Developer Experience: Get real-time feedback from your IDE
Bug Prevention: Catch type-related errors before they reach production
Maintainability: Makes your codebase more maintainable and self-documenting
Practical Usage: Focus on practical type implementations rather than complex type patterns
IDE Support: Excellent integration with modern development environments

While it's possible to develop React Native applications without TypeScript, the benefits it brings to your development workflow are invaluable. The type system helps prevent common errors and provides better code documentation, making it easier for teams to collaborate and maintain code over time.

Navigation Solutions

When it comes to navigation in React Native, there are two main contenders in 2025:

Expo Router vs React Navigation

Both solutions are powerful, but they serve different needs:

Expo Router

Expo Router has become the preferred choice for modern React Native applications. Here's why:

File-based Routing: Intuitive and familiar for web developers
Cross-platform Focus: Excellent support for iOS, Android, and web
Advanced Features:
- API routes support
- RC (Remote Components) support
- Built-in layouts system
Future-proof: Regular updates and new features from the Expo team

React Navigation

React Navigation remains a solid choice, especially if:

You're focusing solely on native mobile platforms
You prefer a more traditional screen-based approach
You need more granular control over navigation

Enhanced Navigation Components

For tab-based navigation, consider using React Native Bottom Tabs, which provides:

Native bottom tabs implementation
Smooth animations on both platforms
Better performance than custom implementations

UI and Styling Solutions

The UI and styling landscape in React Native has evolved to offer multiple approaches, each with its own strengths:

Modern Styling Solutions

1. **NativeWind** NativeWind brings Tailwind CSS to React Native: - Familiar Tailwind syntax - Growing ecosystem with NativeWind UI components - Strong community adoption

UniStyles

UniStyles offers:

Familiar StyleSheet-like API
Enhanced functionality
C++ bindings for optimal performance
Version 3.0 with new features

Tamagui

Tamagui provides:

Cross-platform styling solution
Optimized compiler
Built-in component library
Strong performance optimizations

Component Libraries

While traditional component libraries like React Native Paper and React Native Elements still have their place, modern development tends to favor more flexible solutions:

NativeWind UI: Pre-built components using NativeWind
React Native Reusables: Chakra-inspired components for React Native
Tamagui Components: Cross-platform optimized components

Choosing the Right Solution

Your choice should depend on:

Project requirements
Team expertise
Performance needs
Cross-platform requirements
Design system flexibility

For most modern projects, NativeWind offers an excellent balance of features, familiarity, and flexibility. However, UniStyles provides a more native-feeling approach, while Tamagui excels in cross-platform scenarios with its optimization features.

Animation Libraries

Animation is crucial for creating engaging mobile experiences. Here are the top choices for 2025:

React Native Reanimated

React Native Reanimated remains the gold standard for animations:

High-performance native animations
Declarative API
Excellent TypeScript support
Rich ecosystem and community

Moti

Moti offers a simpler approach to animations:

Built on top of Reanimated
Easier learning curve
Preset animations
Great for quick implementations

State Management

Modern React Native apps require different state management solutions for different use cases:

Server State Management

TanStack Query (formerly React Query) is the clear winner for managing server state:

Powerful data synchronization
Built-in caching
Automatic background updates
Optimistic updates
Request deduplication

Alternative: Redux Toolkit Query

If your project is already using Redux for client state management, Redux Toolkit Query (RTK Query) is an excellent alternative: - Tight integration with Redux ecosystem - Code generation for API endpoints - Automatic cache management - Built-in TypeScript support - Familiar Redux patterns

The choice between TanStack Query and RTK Query often depends on your existing architecture:

Choose TanStack Query for new projects or when you prefer a standalone solution
Use RTK Query when you're already invested in the Redux ecosystem

Application State Management

Several solutions exist for managing client-side state:

1. **Zustand** Zustand is the preferred choice for most applications: - Simple and lightweight - Familiar store concept - Great TypeScript support - Strong community adoption

Legend State

Legend State for local-first applications:

Built-in sync capabilities
Supabase integration
Offline-first approach

Context API React's built-in Context API might be sufficient for:

Simple state requirements
Small to medium applications
Component-level state sharing

Data Storage Solutions

Database ORM Solutions

Drizzle ORM

Drizzle ORM has emerged as the modern, lightweight alternative to traditional ORMs in 2025:

Key Features:
- TypeScript-first approach
- SQL-like query builder
- Zero abstractions over SQL
- Significantly smaller bundle size
- Better performance than traditional ORMs
- Built-in schema migrations
- Native Edge runtime support
Benefits:
- Type-safe database queries
- Minimal runtime overhead
- Direct SQL-like syntax
- Easy integration with SQLite and Postgres
- Excellent developer experience
- Strong community growth

While Prisma has been widely used in previous years, Drizzle represents the future of database interactions with its lightweight approach and modern architecture. It's particularly well-suited for React Native applications due to its:

Smaller bundle size impact
Better performance characteristics
Simpler mental model
Native Edge compatibility

Migration from Prisma

If you're coming from Prisma, Drizzle offers several advantages:

More predictable query generation
Faster query execution
No need for additional CLI tools
Direct SQL-like syntax that's easier to debug
Better suited for edge environments

Supabase

Supabase has become the go-to backend solution for React Native applications in 2025:

Core Features:
- PostgreSQL Database with real-time capabilities
- Built-in authentication and user management
- Edge Functions for serverless computing
- Storage solution for files and media
- Auto-generated TypeScript types
- Official React Native SDK
Key Benefits:
- Excellent offline-first capabilities
- Row Level Security (RLS) for data protection
- WebSocket connections for real-time features
- Competitive pricing with generous free tier
- Strong TypeScript integration

SQLite with Expo

Expo SQLite provides a reliable and easy-to-use local database solution:

Key Features:
- Built into Expo SDK
- Full SQLite API access
- Async/Sync API support
- Transaction support
- TypeScript support
- Key-value storage API
Use Cases:
- Offline-first applications
- Local data caching
- Complex local queries
- Structured data storage
- Migration from existing SQLite databases
Integration Options:
- SQL query execution
- Prepared statements
- Database migrations
- Key-value storage mode
- React hooks integration with SQLiteProvider

Choose SQLite when you need:

Complete control over your data structure
Complex local queries
Familiar SQL syntax
Proven reliability
Small app size

Essential Developer Tools

Testing Tools

Maestro

Maestro for UI testing:

Easy setup
Reliable UI testing
Great developer experience

React Native Testing Library

React Native Testing Library:

Industry standard for unit testing
Comprehensive documentation
Large community support

Monitoring and Debugging

Sentry

Sentry for production monitoring:

Real-time error tracking
Performance monitoring
Crash reporting
Debug information

Reactotron

Reactotron for development debugging:

API monitoring
State management debugging
Performance tracking

CI/CD Solutions

Expo EAS (Expo Application Services) EAS provides:

Cloud builds
Automatic app submission
Over-the-air updates
Workflow automation
Seamless integration with Expo projects

These tools form a robust development environment that can significantly improve your React Native development workflow. The combination of these solutions provides a comprehensive setup for building, testing, and deploying professional React Native applications.

Essential Utility Packages

These packages are considered must-haves for specific functionalities in React Native development:

Storage and Performance

React Native MMKV

MMKV for high-performance storage:

Fastest key-value storage available
Native implementation
Perfect alternative to AsyncStorage
Minimal setup required

FlashList

FlashList for optimized list rendering:

Drop-in replacement for FlatList
Significantly better performance
Similar API to FlatList
Built-in recycling system

Form Management

React Hook Form React Hook Form with Zod for form handling:

Performant form validation
Type-safe with Zod integration
Minimal re-renders
Great React Native support

Image Management

Expo Image Expo Image for optimized image handling:

Built-in caching
Memory management
Progressive loading
Cross-platform optimization

UI Interactions

Zego

Zego for advanced UI interactions:

Beautiful dropdown menus
Context menus
Force touch overlays
Native feel

React Native Gesture Handler

Gesture Handler for native-powered gestures:

Pan gestures
Long press
Rotation
Fling gestures
Built-in Expo support

Authentication and Monetization

Clerk

Clerk for comprehensive auth management:

Complete user management
Social provider integration
Security best practices
Easy implementation

RevenueCat

RevenueCat for in-app purchases:

Cross-platform purchase management
Easy product sync
Analytics and insights
Simplified implementation

Camera Integration

React Native Vision Camera Vision Camera for advanced camera features:

High-performance camera access
Photo and video capture
QR code scanning
Barcode recognition
Native implementation

Conclusion

The React Native ecosystem in 2025 is more mature and robust than ever. While the UI landscape might continue to evolve, the core tools and utilities have stabilized, providing a solid foundation for building professional mobile applications. This tech stack represents the best-in-class solutions for various development needs, backed by strong communities and proven in production environments.

The combination of these tools enables developers to create high-performance, maintainable, and feature-rich applications while maintaining excellent developer experience. As the React Native ecosystem continues to grow, these recommendations will help you make informed decisions for your next mobile project.

React Query Data Transformations

Rami Chabchoub — Fri, 17 Jan 2025 00:00:00 GMT

Welcome to Part 2 of "Things I have to say about react-query". As I've become more and more involved with the library and the community around it, I've observed some more patterns people frequently ask about. Initially, I wanted to write them all down in one big article, but then decided to break them down into more manageable pieces. The first one is about a quite common and important task: Data Transformation.

Data Transformation

Let's face it - most of us are not using GraphQL. If you do, then you can be very happy because you have the luxury of requesting your data in the format that you desire.

If you are working with REST though, you are constrained by what the backend returns. So how and where do you best transform data when working with react-query? The only answer worth a damn in software development applies here as well:

It depends.

Here are 3+1 approaches on where you can transform data with their respective pros and cons:

0. On the backend

This is my favourite approach, if you can afford it. If the backend returns data in exactly the structure we want, there is nothing we need to do. While this might sound unrealistic in many cases, e.g. when working with public REST APIs, it is also quite possible to achieve in enterprise applications. If you are in control of the backend and have an endpoint that returns data for your exact use-case, prefer to deliver the data the way you expect it.

🟢 no work on the frontend

🔴 not always possible

1. In the queryFn

The queryFn is the function that you pass to useQuery. It expects you to return a Promise, and the resulting data winds up in the query cache. But it doesn't mean that you have to absolutely return data in the structure that the backend delivers here. You can transform it before doing so:

```typescript showLineNumbers const fetchTodos = async (): Promise => { const response = await axios.get('todos') const data: Todos = response.data

return data.map((todo) => todo.name.toUpperCase()) }

export const useTodosQuery = () => useQuery({ queryKey: ['todos'], queryFn: fetchTodos, })

</CodeBlock>

On the frontend, you can then work with this data "as if it came like this from the backend".
No where in your code will you actually work with todo names that are not upper-cased.
You will also not have access to the original structure.
If you look at the react-query-devtools, you will see the transformed structure.
If you look at the network trace, you'll see the original structure.
This might be confusing, so keep that in mind.

Also, there is no optimization that react-query can do for you here.
Every time a fetch is executed, your transformation will run.
If it's expensive, consider one of the other alternatives.
Some companies also have a shared api layer that abstracts data fetching, so you might not have access to this layer to do your transformations.

🟢   very "close to the backend" in terms of co-location

🟡   the transformed structure winds up in the cache, so you don't have access to the original structure

🔴   runs on every fetch

🔴   not feasible if you have a shared api layer that you cannot freely modify

## 2. In the render function
As advised in <A href="https://tkdodo.eu/blog/practical-react-query">Part 1</A>, if you create custom hooks, you can easily do transformations there:

<CodeBlock title="custom-hook-transformation">
```typescript showLineNumbers {12-15}
const fetchTodos = async (): Promise<Todos> => {
  const response = await axios.get('todos')
  return response.data
}

export const useTodosQuery = () => {
  const queryInfo = useQuery({
    queryKey: ['todos'],
    queryFn: fetchTodos,
  })

  return {
    ...queryInfo,
    data: queryInfo.data?.map((todo) => todo.name.toUpperCase()),
  }
}

As it stands, this will not only run every time your fetch function runs, but actually on every render (even those that do not involve data fetching). This is likely not a problem at all, but if it is, you can optimize with useMemo. Be careful to define your dependencies as narrow as possible. data inside the queryInfo will be referentially stable unless something really changed (in which case you want to recompute your transformation), but the queryInfo itself will not. If you add queryInfo as your dependency, the transformation will again run on every render:

```typescript showLineNumbers export const useTodosQuery = () => { const queryInfo = useQuery({ queryKey: ['todos'], queryFn: fetchTodos })

return { ...queryInfo, // 🚨 don't do this - the useMemo does nothing at all here! data: React.useMemo( () => queryInfo.data?.map((todo) => todo.name.toUpperCase()), [queryInfo] ),

// ✅ correctly memoizes by queryInfo.data
data: React.useMemo(
  () => queryInfo.data?.map((todo) => todo.name.toUpperCase()),
  [queryInfo.data]
),

} }

</CodeBlock>

Especially if you have additional logic in your custom hook to combine with your data transformation, this is a good option. Be aware that data can be potentially undefined, so use optional chaining when working with it.

<Update>
Since React Query has tracked queries turned on per default since v4, spreading ...queryInfo is no longer recommended, because it invokes getters on all properties.
</Update>

🟢   optimizable via useMemo

🟡   exact structure cannot be inspected in the devtools

🔴   a bit more convoluted syntax

🔴   data can be potentially undefined

🔴   not recommended with tracked queries

## 3. using the select option
v3 introduced built-in selectors, which can also be used to transform data:

<CodeBlock title="select-transformation">
```typescript showLineNumbers {5}
export const useTodosQuery = () =>
  useQuery({
    queryKey: ['todos'],
    queryFn: fetchTodos,
    select: (data) => data.map((todo) => todo.name.toUpperCase()),
  })

selectors will only be called if data exists, so you don't have to care about undefined here. Selectors like the one above will also run on every render, because the functional identity changes (it's an inline function). If your transformation is expensive, you can memoize it either with useCallback, or by extracting it to a stable function reference:

```typescript showLineNumbers {8,9, 16-20} const transformTodoNames = (data: Todos) => data.map((todo) => todo.name.toUpperCase())

export const useTodosQuery = () => useQuery({ queryKey: ['todos'], queryFn: fetchTodos, // ✅ uses a stable function reference select: transformTodoNames, })

export const useTodosQuery = () => useQuery({ queryKey: ['todos'], queryFn: fetchTodos, // ✅ memoizes with useCallback select: React.useCallback( (data: Todos) => data.map((todo) => todo.name.toUpperCase()), [] ), })

</CodeBlock>

Further, the select option can also be used to subscribe to only parts of the data.
This is what makes this approach truly unique. Consider the following example:

<CodeBlock title="select-partial-subscriptions">
```javascript showLineNumbers
export const useTodosQuery = (select) =>
  useQuery({
    queryKey: ['todos'],
    queryFn: fetchTodos,
    select,
  })

export const useTodosCount = () =>
  useTodosQuery((data) => data.length)
export const useTodo = (id) =>
  useTodosQuery((data) => data.find((todo) => todo.id === id))

Here, we've created a useSelector like API by passing a custom selector to our useTodosQuery. The custom hooks still works like before, as select will be undefined if you don't pass it, so the whole state will be returned.

But if you pass a selector, you are now only subscribed to the result of the selector function. This is quite powerful, because it means that even if we update the name of a todo, our component that only subscribes to the count via useTodosCount will not rerender. The count hasn't changed, so react-query can choose to not inform this observer about the update 🥳 (Please note that this is a bit simplified here and technically not entirely true - I will talk in more detail about render optimizations in Part 3).

🟢 best optimizations

🟢 allows for partial subscriptions

🟡 structure can be different for every observer

🟡 structural sharing is performed twice (I will also talk about this in more detail in Part 3)

That's all I have for today 👋.

React Query Render Optimizations

Rami Chabchoub — Sat, 18 Jan 2025 00:00:00 GMT

Render optimizations are an advanced concept for any app. React Query already comes with very good optimizations and defaults out of the box, and most of the time, no further optimizations are needed. "Unneeded re-renders" is a topic that many people tend to put a lot of focus on, which is why I've decided to cover it. But I wanted to point out once again, that usually, for most apps, render optimizations probably don't matter as much as you'd think. Re-renders are a good thing. They make sure your app is up-to-date. I'd take an "unnecessary re-render" over a "missing render-that-should-have-been-there" all day every day. For more on this topic, please read: * Fix the slow render before you fix the re-render by Kent C. Dodds * this article by @ryanflorence about premature optimizations

I've already written quite a bit about render optimizations when describing the select option in #2: React Query Data Transformations. However, "Why does React Query re-render my component two times even though nothing changed in my data" is the question I probably needed to answer the most (apart from maybe: "Where can I find the v2 docs" 😅). So let me try to explain it in-depth.

isFetching transition

I haven't been entirely honest in the last example when I said that this component will only re-render if the length of todos change:

```typescript showLineNumbers export const useTodosQuery = (select) => useQuery({ queryKey: ['todos'], queryFn: fetchTodos, select, }) export const useTodosCount = () => useTodosQuery((data) => data.length)

function TodosCount() { const todosCount = useTodosCount()

return

{todosCount.data}

}

</CodeBlock>

Every time you make a background refetch, this component will re-render twice with the following query info:

```bash
{ status: 'success', data: 2, isFetching: true }
{ status: 'success', data: 2, isFetching: false }

That is because React Query exposes a lot of meta information for each query, and isFetching is one of them. This flag will always be true when a request is in-flight. This is quite useful if you want to display a background loading indicator. But it's also kinda unnecessary if you don't do that.

notifyOnChangeProps

For this use-case, React Query has the notifyOnChangeProps option. It can be set on a per-observer level to tell React Query: Please only inform this observer about changes if one of these props change. By setting this option to ['data'], we will find the optimized version we seek:

```typescript showLineNumbers {1, 6, 9} export const useTodosQuery = (select, notifyOnChangeProps) => useQuery({ queryKey: ['todos'], queryFn: fetchTodos, select, notifyOnChangeProps, }) export const useTodosCount = () => useTodosQuery((data) => data.length, ['data']) ```

You can see this in action in the optimistic-updates-typescript example in the docs.

Staying in sync

While the above code works well, it can get out of sync quite easily. What if we want to react to the error, too? Or we start to use the isLoading flag? We have to keep the notifyOnChangeProps list in sync with whichever fields we are actually using in our components. If we forget to do that, and we only observe the data property, but get an error that we also display, our component will not re-render and is thus outdated. This is especially troublesome if we hard-code this in our custom hook, because the hook does not know what the component will actually use:

```typescript showLineNumbers export const useTodosCount = () => useTodosQuery((data) => data.length, ['data'])

function TodosCount() { // 🚨 we are using error, // but we are not getting notified if error changes! const { error, data } = useTodosCount()

return (

{error ? error : null} {data ? data : null}

) }

</CodeBlock>

As I have hinted in the disclaimer in the beginning, I think this is way worse than the occasional unneeded re-render.
Of course, we can pass the option to the custom hook, but this still feels quite manual and boilerplate-y.
Is there a way to do this automatically? Turns out, there is:

# Tracked Queries
I'm quite proud of this feature, given that it was my first major contribution to the library.
If you set `notifyOnChangeProps` to `'tracked'`, React Query will keep track of the fields you are using during render, and will use this to compute the list.
This will optimize exactly the same way as specifying the list manually, except that you don't have to think about it.
You can also turn this on globally for all your queries:

<CodeBlock title="tracked-queries">
```typescript showLineNumbers
const queryClient = new QueryClient({
  defaultOptions: {
    queries: {
      notifyOnChangeProps: 'tracked',
    },
  },
})
function App() {
  return (
    <QueryClientProvider client={queryClient}>
      <Example />
    </QueryClientProvider>
  )
}

With this, you never have to think about re-renders again. Of course, tracking the usages has a bit of an overhead as well, so make sure you use this wisely. There are also some limitations to tracked queries, which is why this is an opt-in feature:

If you use object rest destructuring, you are effectively observing all fields. Normal destructuring is fine, just don't do this:

```typescript showLineNumbers // 🚨 will track all fields const { isLoading, ...queryInfo } = useQuery(...)

// ✅ this is totally fine const { isLoading, data } = useQuery(...)

</CodeBlock>

* Tracked queries only work "during render".
If you only access fields during effects, they will not be tracked.
This is quite the edge case though because of dependency arrays:

<CodeBlock title="tracking-effects">
```typescript showLineNumbers
const queryInfo = useQuery(...)

// 🚨 will not corectly track data
React.useEffect(() => {
    console.log(queryInfo.data)
})

// ✅ fine because the dependency array is accessed during render
React.useEffect(() => {
    console.log(queryInfo.data)
}, [queryInfo.data])

Tracked queries don't reset on each render, so if you track a field once, you'll track it for the lifetime of the observer:

```typescript showLineNumbers const queryInfo = useQuery(...)

if (someCondition()) { // 🟡 we will track the data field if someCondition was true in any previous render cycle return

{queryInfo.data}

}

</CodeBlock>

<Update>
Starting with v4, tracked queries are turned on per default in React Query, and you can opt out of the feature with `notifyOnChangeProps: 'all'`.
</Update>

# Structural sharing
A different, but no less important render optimization that React Query has turned on out of the box is structural sharing.
This feature makes sure that we keep referential identity of our `data` on every level.
As an example, suppose you have the following data structure:

<CodeBlock>
```json showLineNumbers
[
  { "id": 1, "name": "Learn React", "status": "active" },
  { "id": 2, "name": "Learn React Query", "status": "todo" }
]

Now suppose we transition our first todo into the done state, and we make a background refetch. We'll get a completely new json from our backend:

```diff showLineNumbers [ - { "id": 1, "name": "Learn React", "status": "active" }, + { "id": 1, "name": "Learn React", "status": "done" }, { "id": 2, "name": "Learn React Query", "status": "todo" } ] ```

Now React Query will attempt to compare the old state and the new and keep as much of the previous state as possible. In our example, the todos array will be new, because we updated a todo. The object with id 1 will also be new, but the object for id 2 will be the same reference as the one in the previous state - React Query will just copy it over to the new result because nothing has changed in it.

This comes in very handy when using selectors for partial subscriptions:

```typescript showLineNumbers // ✅ will only re-render if _something_ within todo with id:2 changes // thanks to structural sharing const { data } = useTodo(2) ```

As I've hinted before, for selectors, structural sharing will be done twice: Once on the result returned from the queryFn to determine if anything changed at all, and then once more on the result of the selector function. In some instances, especially when having very large datasets, structural sharing can be a bottleneck. It also only works on json-serializable data. If you don't need this optimization, you can turn it off by setting structuralSharing: false on any query.

Have a look at the replaceEqualDeep tests if you want to learn more about what happens under the hood.

Status Checks in React Query

Rami Chabchoub — Sun, 19 Jan 2025 00:00:00 GMT

One advantage of React Query is the easy access to status fields of the query. You instantly know if your query is loading or if it's erroneous. For this, the library exposes a bunch of boolean flags, which are mostly derived from the internal state machine. Looking at the types, your query can be in one of the following states:

success: Your query was successful, and you have data for it
error: Your query did not work, and an error is set
pending: Your query has no data

Note that the isFetching flag is not part of the internal state machine - it is an additional flag that will be true whenever a request is in-flight. You can be fetching and success, you can be fetching and error - but you cannot be loading and success at the same time. The state machine makes sure of that.

Before v5, pending was named loading, and before v4, there was a fourth state called idle.

Also, the isFetching flag is derived from a secondary fetchStatus - just like the isPaused flag. You can read more about this in #13: Offline React Query.

The standard example

Most examples look something like this:

```typescript showLineNumbers const todos = useTodos()

if (todos.isPending) { return 'Loading...' } if (todos.error) { return 'An error has occurred: ' + todos.error.message }

return

{todos.data.map(renderTodo)}

</CodeBlock>

Here, we check for pending and error first, and then display our data.
This is probably fine for some use-cases, but not for others.
Many data fetching solutions, especially hand-crafted ones, have no refetch mechanism, or only refetch on explicit user interactions.

But React Query does.

It refetches quite aggressively per default, and does so without the user actively requesting a refetch.
The concepts of `refetchOnMount`, `refetchOnWindowFocus` and `refetchOnReconnect` are great for keeping your data accurate, but they might cause a confusing ux if such an automatic background refetch fails.

# Background errors
In many situations, if a background refetch fails, it could be silently ignored.
But the code above does not do that. Let's look at two examples:

* The user opens a page, and the initial query loads successfully.
They are working on the page for some time, then switch browser tabs to check emails.
They come back some minutes later, and React Query will do a background refetch. Now that fetch fails.
* Our user is on page with a list view, and they click on one item to drill down to the detail view.
This works fine, so they go back to the list view. Once they go to the detail view again, they will see data from the cache.
This is great - except if the background refetch fails.

In both situations, our query will be in the following state:

<CodeBlock>
```bash showLineNumbers
{
  "status": "error",
  "error": { "message": "Something went wrong" },
  "data": [{ ... }]
}

As you can see, we will have both an error and the stale data available. This is what makes React Query great - it embraces the stale-while-revalidate caching mechanism, which means it will always give you data if it exists, even if it's stale.

Now it's up to us to decide what we display. Is it important to show the error? Is it enough to show the stale data only, if we have any? Should we show both, maybe with a little background error indicator?

There is no clear answer to this question - it depends on your exact use-case. However, given the two above examples, I think it would be a somewhat confusing user experience if data would be replaced with an error screen.

This is even more relevant when we take into account that React Query will retry failed queries three times per default with exponential backoff, so it might take a couple of seconds until the stale data is replaced with the error screen. If you also have no background fetching indicator, this can be really perplexing.

This is why I usually check for data-availability first:

```typescript showLineNumbers const todos = useTodos()

if (todos.data) { return

{todos.data.map(renderTodo)}

} if (todos.error) { return 'An error has occurred: ' + todos.error.message }

return 'Loading...'

</CodeBlock>

Again, there is no clear principle of what is right, as it is highly dependent on the use-case.
Everyone should be aware of the consequences that aggressive refetching has, and we have to structure our code accordingly rather than strictly following the simple todo-examples 😉.

Special thanks go to <A href="https://github.com/boschni">Niek Bosch</A> who first highlighted to me why this pattern of status checking can be harmful in some situations.

Testing React Query

Rami Chabchoub — Mon, 20 Jan 2025 00:00:00 GMT

Questions around the testing topic come up quite often together with React Query, so I'll try to answer some of them here. I think one reason for that is that testing "smart" components (also called container components) is not the easiest thing to do. With the rise of hooks, this split has been largely deprecated. It is now encouraged to consume hooks directly where you need them rather than doing a mostly arbitrary split and drill props down.

I think this is generally a very good improvement for colocation and code readability, but we now have more components that consume dependencies outside of "just props".

They might useContext. They might useSelector. Or they might useQuery.

Those components are technically no longer pure, because calling them in different environments leads to different results. When testing them, you need to carefully setup those surrounding environments to get things working.

Mocking network requests

Since React Query is an async server state management library, your components will likely make requests to a backend. When testing, this backend is not available to actually deliver data, and even if, you likely don't want to make your tests dependent on that.

There are tons of articles out there on how to mock data with jest. You can mock your api client if you have one. You can mock fetch or axios directly. I can only second what Kent C. Dodds has written in his article Stop mocking fetch:

Use mock service worker by @ApiMocking

It can be your single source of truth when it comes to mocking your apis:

works in node for testing
supports REST and GraphQL
has a storybook addon so you can write stories for your components that useQuery
works in the browser for development purposes, and you'll still see the requests going out in the browser devtools
works with cypress, similar to fixtures With our network layer being taken care of, we can start talking about React Query specific things to keep an eye on:

QueryClientProvider

Whenever you use React Query, you need a QueryClientProvider and give it a queryClient - a vessel which holds the QueryCache. The cache will in turn hold the data of your queries.

I prefer to give each test its own QueryClientProvider and create a new QueryClient for each test. That way, tests are completely isolated from each other. A different approach might be to clear the cache after each test, but I like to keep shared state between tests as minimal as possible. Otherwise, you might get unexpected and flaky results if you run your tests in parallel.

For custom hooks If you are testing custom hooks, I'm quite certain you're using react-hooks-testing-library. It's the easiest thing there is to test hooks. With that library, we can wrap our hook in a wrapper, which is a React component to wrap the test component in when rendering. I think this is the perfect place to create the QueryClient, because it will be executed once per test:

```typescript showLineNumbers const createWrapper = () => { // ✅ creates a new QueryClient for each test const queryClient = new QueryClient() return ({ children }) => ( {children} ) }

test('my first test', async () => { const { result } = renderHook(() => useCustomHook(), { wrapper: createWrapper(), }) })

</CodeBlock>

# For components
If you want to test a Component that uses a `useQuery` hook, you also need to wrap that Component in QueryClientProvider.
A small wrapper around `render` from <A href="https://testing-library.com/docs/react-testing-library/intro/">react-testing-library</A> seems like a good choice.
Have a look at how React Query does it <A href="https://github.com/TanStack/query/blob/ead2e5dd5237f3d004b66316b5f36af718286d2d/src/react/tests/utils.tsx#L6-L17">internally for their tests</A>.

# Turn off retries
It's one of the most common "gotchas" with React Query and testing: The library defaults to three retries with exponential backoff, which means that your tests are likely to timeout if you want to test an erroneous query.
The easiest way to turn retries off is, again, via the QueryClientProvider.
Let's extend the above example:

<CodeBlock title="no-retries">
```typescript showLineNumbers {2-9}
const createWrapper = () => {
  const queryClient = new QueryClient({
    defaultOptions: {
      queries: {
        // ✅ turns retries off
        retry: false,
      },
    },
  })

  return ({ children }) => (
    <QueryClientProvider client={queryClient}>
      {children}
    </QueryClientProvider>
  )
}

test("my first test", async () => {
  const { result } = renderHook(() => useCustomHook(), {
    wrapper: createWrapper()
  })
})

This will set the defaults for all queries in the component tree to "no retries". It is important to know that this will only work if your actual useQuery has no explicit retries set. If you have a query that wants 5 retries, this will still take precedence, because defaults are only taken as a fallback.

setQueryDefaults

The best advice I can give you for this problem is: Don't set these options on useQuery directly. Try to use and override the defaults as much as possible, and if you really need to change something for specific queries, use queryClient.setQueryDefaults.

So for example, instead of setting retry on useQuery:

```typescript showLineNumbers const queryClient = new QueryClient()

function App() { return ( ) }

function Example() { // 🚨 you cannot override this setting for tests! const queryInfo = useQuery({ queryKey: ['todos'], queryFn: fetchTodos, retry: 5, }) }

</CodeBlock>

Set it like this:

<CodeBlock title="setQueryDefaults">
```typescript showLineNumbers {9,10}
const queryClient = new QueryClient({
  defaultOptions: {
    queries: {
      retry: 2,
    },
  },
})

// ✅ only todos will retry 5 times
queryClient.setQueryDefaults(['todos'], { retry: 5 })

function App() {
  return (
    <QueryClientProvider client={queryClient}>
      <Example />
    </QueryClientProvider>
  )
}

Here, all queries will retry two times, only todos will retry five times, and I still have the option to turn it off for all queries in my tests 🙌.

ReactQueryConfigProvider

Of course, this only works for known query keys. Sometimes, you really want to set some configs on a subset of your component tree. In v2, React Query had a ReactQueryConfigProvider for that exact use-case. You can achieve the same thing in v3 with a couple of lines of codes:

```typescript showLineNumbers const ReactQueryConfigProvider = ({ children, defaultOptions }) => { const client = useQueryClient() const [newClient] = React.useState( () => new QueryClient({ queryCache: client.getQueryCache(), muationCache: client.getMutationCache(), defaultOptions, }) )

return ( {children} ) }

</CodeBlock>

You can see this in action in this <A href="https://codesandbox.io/p/sandbox/react-query-config-provider-v3-lt00f">codesandbox example</A>.

# Always await the query
Since React Query is async by nature, when running the hook, you won't immediately get a result.
It usually will be in loading state and without data to check.
The <A href="https://react-hooks-testing-library.com/reference/api#async-utilities">async utilities</A> from react-hooks-testing-library offer a lot of ways to solve this problem.
For the simplest case, we can just wait until the query has transitioned to success state:

<CodeBlock title="waitFor">
```typescript showLineNumbers {21-24}
const createWrapper = () => {
  const queryClient = new QueryClient({
    defaultOptions: {
      queries: {
        retry: false,
      },
    },
  })
  return ({ children }) => (
    <QueryClientProvider client={queryClient}>
      {children}
    </QueryClientProvider>
  )
}

test("my first test", async () => {
  const { result, waitFor } = renderHook(() => useCustomHook(), {
    wrapper: createWrapper()
  })

  // ✅ wait until the query has transitioned to success state
  await waitFor(() => result.current.isSuccess)

  expect(result.current.data).toBeDefined()
}

@testing-library/react v13.1.0 also has a new renderHook that you can use. However, it doesn't return its own `waitFor` util, so you'll have to use the one you can import from @testing-library/react instead. The API is a bit different, as it doesn't allow to return a boolean, but expects a Promise instead. That means we must adapt our code slightly: ```typescript showLineNumbers {8-11} import { waitFor, renderHook } from '@testing-library/react'

test("my first test", async () => { const { result } = renderHook(() => useCustomHook(), { wrapper: createWrapper() })

// ✅ return a Promise via expect to waitFor await waitFor(() => expect(result.current.isSuccess).toBe(true))

expect(result.current.data).toBeDefined() }

</CodeBlock>
</Update>

# Putting it all together
I've set up a quick repository where all of this comes nicely together: mock-service-worker, react-testing-library and the mentioned wrapper.
It contains four tests - basic failure and success tests for custom hooks and components.
Have a look here: <A href="https://github.com/TkDodo/testing-react-query">https://github.com/TkDodo/testing-react-query</A>