DEV Community: Nik

JS Promises #3: Garbage collection and memory leaks

Nik — Thu, 19 Jan 2023 21:07:04 +0000

Promises in JavaScript are a way to handle asynchronous operations. One of the trickiest part of async operations is that we may accidentally have a memory leak and therefore it's extremely important to understand when the promises is GCed and what prevents a promise from being garbage collected.

TL&DRs

This codesandbox has all the examples for promises and then chains. Open sandbox and reload it. You can run Promise example first and then example after.
In the end of the article you will find key findings from the article.

Some notes about tools we will use
This article is for advanced users, it researches how GC (garbage collector) works with promises. If you want to get base information about promises, check earlier articles in the series.

We will use FinalizationRegistry to find when the element is GCed. Check this article if you're not familiar with FinalizationRegistry.
To speed up GC we will create tons of mock object and remove strong refs to them.

Please, do not run the experiments in dev tools console. Dev Tools keeps all the objects alive and therefore you will have false-negative results.

FinalizationRegistry prints in the console the line and the time spend.

It is important to keep in mind that if a promise is eligible for GC, it does not mean that it will be immediately collected. The GC process in JavaScript is not deterministic and occurs at the discretion of the JavaScript runtime.

Let's draft possible scenarios:

Explicitly keep the reference to the Promise:

const promise = new Promise((resolve, reject) => {...});

In this case we have a strong reference to the Promise and we won't GC it as long as const promise exists.

📝 As long as you keep explicit reference to your promise, it won't be GCed

Lose the references to promise, resolve and reject functions:

let promiseWithoutResolve = new Promise((resolve) => {
  setTimeout(() => {
    console.log("Timeout for the promise that keeps no refs");
  }, 100000);
});

finalizationRegistry.register(promiseWithoutResolve, " which keeps no references"); 
promiseWithoutResolve = null;

For that test we keep neither strong ref to the promise, nor resolve function, however, the promise function has quite a long timeout operation.

📝 When you lose all refs to the resolve, reject and instance itself the object is marked to GC and as soon as GC starts it will be collected. (Note: JS GC has several generations and therefore if your promise is in the 3rd generation, it might not be collected).

Cache `resolve` and/or `reject` method without strong ref to the promise instance itself

In real codebases you can find something similar to:

let resolve;
let promise = new Promise((_resolve) => { 
  resolve = _resolve;
});
// Let's remove the reference to promise
promise = null;

This code performs 2 things:
1) Removes the strong reference to promise
2) Caches resolve function outside callback in the promise constructor.

We don't have a direct access to the promise anymore but it's unclear if this promise will be queued for GC or it will stay as long as we keep the link to the resolve.

To test this behaviour we can draft an experiment:

let promiseWithResolve = new Promise((resolve) => {
  setTimeout(() => {
    resolve();
  }, 100000);
});

finalizationRegistry.register(promiseWithResolve , " which keeps resolve function"); 
promiseWithResolve = null;

For such an experiment we have an output:

Promise  which keeps resolve function. Time taken: 155765.

📝 The promise will be kept in memory as long as we have the reference to resolve or reject callbacks.
📝 If we have a promise which lives for a long period of time it may get to the older generation, which means it will take even more time between losing all the refs to the promise and getting it GCed.

`.then` chaining

Day-to-day use case:

new Promise(() => {}).then(() => {/* Some async code */})

Experiment to test:

let promiseWithThen = new Promise(() => {});
let then = promiseWithThen.then(() => {
  console.log("then reached");
});

finalizationRegistry.register(promiseWithThen, " with `then` chain");
finalizationRegistry.register(then, " then callback");

promiseWithThen = then = null;

The output:

Promise  with `then` chain. Time taken: 191. 
Promise  then callback. Time taken: 732.

The original promiseWithThen will never be resolved but it's chained by following then operation, which may keep the reference to the original promise. Luckily, then doesn't prevent promise from being GCed.

📝 .then doesn't prevent promise from GC. Only explicit references to promise itself, resolve and reject matter.

What would happen if we add `.then` to these experiments?

As we found, .then. doesn't prevent promises from garbage collection. Which means, it shouldn't have any effect.

To prove this we can draft the experiment which is under Then example in this sandbox: https://codesandbox.io/s/promises-article-first-example-8jfyh?file=/src/index.js

When you run the experiment you will see that then really has no effect and it doesn't change any behaviour.

Why several .then chains keep promise alive?

Sometimes in the code we have .then chains:

Promise.resolve()
  .then(asyncCode1)
  .then(asyncCode2)
  ...
  .then(asyncCodeN);

Even though we don't keep reference to the promise, it isn't scheduled to be GC before the chain completes.
The thing is: Promise.resolve() returns the resolved promise, and the first .then plans a microtask to run, since the previous promise is resolved. So, we will have a planned scope to execute.

.then returns a promise which is chained by the following async operation (asyncCode2, ...). And the value for the async operation is the return value of the previous .then block (in our case it's the fn asyncCode1).

📝 if your .then chain gets "control" (planned for execution or even started execution), the function scope has the reference to resolve or reject the promise which is returned by .then and therefore this promise won't be GCed.

To sum up:

Short list of key findings:

📝 References to: the promise instance itself, resolve, reject keep the promise from being garbage collected.

📝 .then doesn't prevent promise from GC.

📝 If we have a promise which lives for a long period of time it may get to the older generation, which means it will take even more time between losing all the refs to the promise and getting it GCed.

JavaScript memory management 101: Strong and Weak refs, FinalizationRegistry

Nik — Sun, 21 Aug 2022 17:25:18 +0000

When we assign something to the variable it can be either primitive (value) type or object (reference) type.

This article gives you an overview of the types, the difference between strong and weak ref, and how to track the object garbage-collection (GC).

Primitive and reference types

Value and reference types are different. The most notable differences are: comparison, storage, and how engines manage these data.

📝 Comparison. Primitive types are compared by its value, reference types are compared by reference:

1 === 1 // true
{} === {} // false

📝 Storage: value types are stored in the stack, reference types are stored in the heap. The value itself is just a pointer to the place in the heap, where it's stored.

// obj is a reference to the `{}`
const obj = {};

// a stores the number 123 in stack
const a = 123;

📝 When the variable is stored in the stack, it gets cleared as soon as the execution context ends:

// When we call foo, we put the function context to the callstack
foo();

function foo() {
  // We add fooVariable to the stack and foo2 as well
  let fooVariable = 123;
  let foo2;

  function bar() {
    // Put barVariable to the stack
    let barVariable = 1234;

    // Here we copy the value
    foo2 = barVariable;

    // We get out from `bar` function, which means `barVariable` will be disposed
  }
  // Put `bar` function context to the callstack
  bar();

  // We get out from `foo` fn, so `fooVariable` and `foo2` will be disposed
}

Note: we have 2 object types declarations in this example, can you find them?

Answer
We declared 2 functions: bar and foo. They are object types

📝 As reference types are stored in the heap, engines should "understand" when they can garbage collect the object and clear unused data, otherwise, you would get a memory leak. To do so, engines use Garbage-collector (GC).

The simplest GC implementation is the reference counter:

As you can see, we don't clear the object as soon as we get out of the function in comparison with value types. It's stored all the time we have any pointers to it.

Modern engines use complex GCs, which have lots of optimizations, such as generations, etc. (let me know if you're interested in it, we can cover it in the future 😊)

All the variables we were using so far are strong refs. We use them most of the time:

// Strong reference to array
const array = []; 

// Strong reference to object
const obj = {};

// Strong reference to map
const map = new Map();

In opposite to strong refs, many languages allow developers to use weak refs.

Weak refs

📝 Weak refs are garbage-collectible references to objects. In other words, they don't prevent the object from being GCed.

WeakRefs are relatively new to the JS ecosystem. They don't prevent the stored value from being GCed:

📝 Weak references are used to prevent objects from being kept in the memory when there are no other strong references and you don't want this ref to prevent it.

Some examples which I saw before:

If you want to control the execution order for promises. One of the most popular ways to do it is to execute them in declaration order: e.g. "stack promises". To prevent possible memory leaks, you can create the list of WeakRef<Promise>, and if any of the promises would be GCed, you just ignore the entry in your list.
If you have a Map, which keys are objects and you don't want this map to keep objects in memory. As an example, such maps can be used to keep additional data associated with the object itself, like metadata. In this case, you can use WeakMap
Temporal caches: we can have a cache, which has a limit for maximum entries inside the cache (e.g. LRU). Another use case is to create a cache that keeps the list of WeakRefs. Such a cache would keep the data as long as we have either a link for it or up to the moment when GC would remove unused entries.

JavaScript allows us to use 3 types of Weak* structures:
📝 1. WeakRef is an object that keeps a weak reference to another object without preventing it from being GCed.
📝 2. WeakMap is a map but the keys are weak references. Primitive types as keys are prohibited in WeakMaps. It covers the 2nd use case from the examples above (additional data to existing objects, like meta-data).
📝 3. WeakSet is the set of WeakRefs to the objects.

Important note: do not perform tests with WeakRefs in dev tools. Your objects won't be GCed in it due to DevTools specific behaviour. Instead, use jsbin, codesandbox, runkit or perform tests in Node.js. Localhost is okay when you open files using http:// protocol, as file:// also has specific behaviour.

Let's test some base WeakRef behaviour. How we can find that the object was GCed? To perform the test we need:

Lose/remove all strong references to the object
Allocate a lot of memory and remove strong refs to these objects too
Make macrotasks pauses to increase chances for the GC
Test WeakRef.

That's how we can allocate a lot of memory and make pauses

// Creates lots of objects to consume additional memory, and lost references to them, to speed up GC call
async function createLotsOfGarbageAndPause() {
  for (let i = 0; i < 1000; i++) {
    const a = new Array(100000);
  }
  await tick();
}
// Creates a separate Macro Task, so that it increases chances to have GC performed
function tick() {
  return new Promise((resolve) => {
    setTimeout(resolve, 0);
  });
}

Now let's prepare the test code:


    
async function createLotsOfGarbageAndPause() {
  for (let i = 0; i < 1000; i++) {
    const a = new Array(100000);
  }
  await tick();
}
function tick() {
  return new Promise((resolve) => {
    setTimeout(resolve, 0);
  });
}


    
console.log("WeakRef example started");
let one = new WeakRef({
  field:
    "this object usually will be presented in console, cause GC wouldn't be called"
});

// This one may be GCed in really rare cases
console.log(
  "To access the object inside WeakRef in js you have to call deref:",
  one.deref()
);

let two = new WeakRef({
  field: "However, once we allocate a lot of memory, we may have the object GCed"
});
for (let i = 0; i < 10; i++) {
  await createLotsOfGarbageAndPause();
}
// This one can be either defined or GCed
console.log(
  "Instead of previous one this weakRef has more chances to be GCed",
  two.deref() == null ? 'The object is GCed' : 'The object still exists, try to re-run example'
);
console.log("WeakRef example completed");
// !!!!!! SETUP LATEST NODE VERSION before running the code snippet !!!!

If Runkit didn't show the example

console.log("WeakRef example started");
let one = new WeakRef({
  field:
    "this object usually will be presented in console, cause GC wouldn't be called"
});

// This one may be GCed in really rare cases
console.log(
  "To access the object inside WeakRef in js you have to call deref:",
  one.deref()
);

let two = new WeakRef({
  field: "However, once we allocate a lot of memory, we may have the object GCed"
});
for (let i = 0; i < 10; i++) {
  await createLotsOfGarbageAndPause();
}
// This one can be either defined or GCed
console.log(
  "Instead of previous one this weakRef has more chances to be GCed",
  two.deref() == null ? 'The object is GCed' : 'The object still exists, try to re-run example'
);
console.log("WeakRef example completed");

As you can see, when GC is executed we lose access to the Object with WeakRef. However, we may still have 2 questions:

Why do we have separate data types for WeakMaps and WeakSets?

Let's create a Map with objects as keys:


    
const map = new Map();
const a = {};
const b = {};
const weakRef = new WeakRef(b);
map.set(a, 10);
map.set(weakRef, 20);

console.log('Obj a key', map.get(a));
console.log('Obj b key', map.get(b));
console.log('Obj weakRef key', map.get(weakRef));
// !!!!!! SETUP LATEST NODE VERSION before running the code snippet !!!!

When you save a weakRef as a key, you refer to the WeakRef object itself instead of the real one (b = {}). This means, that to save the weak ref as a key in a map you need to use a special type:


    
async function createLotsOfGarbageAndPause() {
  for (let i = 0; i < 1000; i++) {
    const a = new Array(100000);
  }
  await tick();
}
function tick() {
  return new Promise((resolve) => {
    setTimeout(resolve, 0);
  });
}


    
console.log("WeakMap example started");
let one = new WeakRef({
  field:
    "This object doesn't have a strong reference to itself"
});

let map = new WeakMap();
map.set(one.deref(), 10);

for (let i = 0; i < 10; i++) {
  await createLotsOfGarbageAndPause();
}
// This one can be either defined or GCed
console.log(
  "Check if object exists",
  one.deref()
);

if (one.deref() == null) {
  console.log('The object was GCed, and therefore it means WeakMap did not prevent it from being garbage-collected');
}

console.log("WeakMap example completed");

// !!!!!! SETUP LATEST NODE VERSION before running the code snippet !!!!
// !!!!!! Code takes some time to run, as we allocate a lot of memory !!!!

If Runkit didn't show the example

console.log("WeakMap example started");
let one = new WeakRef({
  field:
    "This object doesn't have a strong reference to itself"
});

let map = new WeakMap();
map.set(one.deref(), 10);

for (let i = 0; i < 10; i++) {
  await createLotsOfGarbageAndPause();
}
// This one can be either defined or GCed
console.log(
  "Check if object exists",
  one.deref()
);

if (one.deref() == null) {
  console.log('The object was GCed, and therefore it means WeakMap did not prevent it from being garbage-collected');
}

console.log("WeakMap example completed");

📝 The regular Map doesn't allow you to use WeakRefs as keys, you can either refer to the WeakRef object itself or have a strong reference as a key.
📝 WeakMap creates a WeakRef for objects which we use as keys and doesn't prevent them to be GCed.
📝 WeakMap doesn't have .entries or .keys methods as regular Map, and therefore we cannot iterate through WeakMap elements. WeakMap has following methods: .has, .get, .set.

How to get the exact moment when the object gets GCed?

JavaScript provides FinalizationRegistry.

📝 FinalizationRegistry provides a way to set up a callback that gets called when an object in this registry is GCed.

The code for the test will be almost the same but we will include FinalizationRegistry to log the moment when the object gets GCed:


    
async function createLotsOfGarbageAndPause() {
  for (let i = 0; i < 1000; i++) {
    const a = new Array(100000);
  }
  await tick();
}
function tick() {
  return new Promise((resolve) => {
    setTimeout(resolve, 0);
  });
}


    
console.log("FinalizationRegistry example started");
// Create a strong ref to the object
let strongRef = {
  field:
    "Once this object is garbage collected (finalized), we will see it in the console"
};

const weakRef = new WeakRef(strongRef);
const time = performance.now();
let collected = false;
// Create a FinalizationRegistry (observer);
const registry = new FinalizationRegistry((value) => {
  // weakRef.deref should be undefined here
  console.log(
    'The object with field: ' + value + ' was just finalized. TimeConsumed: ' + (
      performance.now() - time
    ).toFixed() + '. WeakRef: ' + weakRef.deref()
  );
  collected = true;
});

// Register our object
registry.register(strongRef, strongRef.field);

// remove all StrongRefs from the object
strongRef = null;

// Wait!
while (collected !== true) {
  await createLotsOfGarbageAndPause();
}
console.log("FinalizationRegistry example completed");
// !!!!!! SETUP LATEST NODE VERSION before running the code snippet !!!!

If Runkit didn't show the example
console.log("FinalizationRegistry example started");
// Create a strong ref to the object
let strongRef = {
field:
"Once this object is garbage collected (finalized), we will see it in the console"
};

const weakRef = new WeakRef(strongRef);
const time = performance.now();
let collected = false;
// Create a FinalizationRegistry (observer);
const registry = new FinalizationRegistry((value) => {
// weakRef.deref should be undefined here
console.log(
'The object with field: ' + value + ' was just finalized. TimeConsumed: ' + (
performance.now() - time
).toFixed() + '. WeakRef: ' + weakRef.deref()
);
collected = true;
});

// Register our object
registry.register(strongRef, strongRef.field);

// remove all StrongRefs from the object
strongRef = null;

// Wait!
while (collected !== true) {
await createLotsOfGarbageAndPause();
}
console.log("FinalizationRegistry example completed");

📝 One of the most popular use cases for FinalizationRegistry is memory logging. If your application works with big data chunks, you can use FinalizationRegistry to make reports to understand whether your app has potential memory leaks.

What about browser support?

You can use these tools in almost all modern browsers: https://caniuse.com/?search=Weak

Today we have discussed primitive and object types followed weak and strong references, and experimented on how to track the moment when the object is about to be GCed.

JS Promises #2: how to get current promise status and build your own promise queue?

Nik — Fri, 05 Aug 2022 20:57:00 +0000

1. How promises work

The first article described the base information about promises.
Before we get to more complicated topics, I'd suggest thinking about the tools and utility functions we can create on top of promises. For this article let's think about getting the current promise status and building a promise queue.

TL&DR

Check promise status



const pending = {
  state: 'pending',
};

function getPromiseState(promise) {
  // We put `pending` promise after the promise to test, 
  // which forces .race to test `promise` first
  return Promise.race([promise, pending]).then(
    (value) => {
      if (value === pending) {
        return value;
      }
      return {
        state: 'resolved',
        value
      };
    },
    (reason) => ({ state: 'rejected', reason })
  );
}

Promise queue



class Queue {
  _queue = Promise.resolve();

  enqueue(fn) {
    const result = this._queue.then(fn);
    this._queue = result.then(() => {}, () => {});

    // we changed return result to return result.then() 
    // to re-arm the promise
    return result.then();
  }

  wait() {
    return this._queue;
  }
}

How to get current promise status

After you created a promise, you cannot get an info at runtime whether the promise is still pending, fulfilled or rejected.

You can see the current promise status in debugger:

From the debugger we see that the Symbol [[PromiseState]] is in charge of that. However, PromiseState is not well-known symbol, so we can treat this state, as a private field which we can't get "right now".

However, we can use Promise.race to test the current promise status. To do so, we may use the feature of Promise.race:

📝 Promise.race checks promises in their order. For example:



const a = Promise.resolve(1);
const b = Promise.resolve(2);
Promise.race([a, b]).then(console.log); // 1

And at the time:



const a = Promise.resolve(1);
const b = Promise.resolve(2);
Promise.race([b, a]).then(console.log); // 2

📝 This code tests the promise status:



const pending = {
  state: 'pending',
};

function getPromiseState(promise) {
  // We put `pending` promise after the promise to test, 
  // which forces .race to test `promise` first
  return Promise.race([promise, pending]).then(
    (value) => {
      if (value === pending) {
        return value;
      }
      return {
        state: 'resolved',
        value
      };
    },
    (reason) => ({ state: 'rejected', reason })
  );
}

Usage https://codesandbox.io/s/restless-sun-njun1?file=/src/index.js



(async function () {
  let result = await getPromiseState(Promise.resolve("resolved hello world"));
  console.log(result);

  result = await getPromiseState(Promise.reject("rejected hello world"));
  console.log(result);

  result = await getPromiseState(new Promise(() => {}));
  console.log(result);

  result = await getPromiseState("Hello world");
  console.log(result);
})();

In addition to the check, this feature of Promise.race can be helpful to run some code with timeouts. E.g:



const TIMEOUT = 5000;
const timeout = new Promise((_, reject) => setTimeout(() => reject('timeout'), TIMEOUT));

// We may want to test check if timeout is rejected 
// before time consuming operations in the async code
// to cancel execution
async function someAsyncCode() {/*...*/}

const result = Promise.race([someAsyncCode(), timeout]);

How to build your own promise queue

Sometimes you have to execute different code blocks in some order one-after-another. It's useful, when you have many heavy async blocks, which you want execute sequentially. We should remember, that:
📝 JS is single-threaded and therefore, we can have concurrent execution, but not parallel.

To do so, we can implement promise queue. This queue would put every function after all previously added async functions.

Let's check this codeblock:



class Queue {
  // By default the queue is empty
  _queue = Promise.resolve();

  enqueue(fn) {
    // Plan new operation in the queue
    const result = this._queue.then(fn);

    // avoid side effects. 
    // We can also provide an error handler as an improvement
    this._queue = result.then(() => {}, () => {});

    // To preserve promise approach, let's return the `fn` result
    return result;
  }

  // If we want just to understand when the queue is over
  wait() {
    return this._queue;
  }
}

Let's test it:



// Work emulator
const emulateWork = (name, time) => () => {
    console.log(`Start ${name}`);
    return new Promise((resolve) => {setTimeout(() => console.log(`End ${name}`) || resolve(), time)})
}

// Let's check if the queue works correctly if the promise fails
const failTest = () => () => {
    console.log(`Start fail`);
    return Promise.reject();
}
const queue = new Queue();
queue.enqueue(emulateWork('A', 500));
queue.enqueue(emulateWork('B', 500));
queue.enqueue(emulateWork('C', 900));
queue.enqueue(emulateWork('D', 1200));
queue.enqueue(emulateWork('E', 200));
queue.enqueue(failTest());
queue.enqueue(emulateWork('F', 900));

We would have the output:

However, when the promise gets rejected, we swallowed the error completely.
It means, if the real code fails, we may never know about it.

📝 If you work with promises, remember to use .catch at the end of the promise chain, otherwise you may miss failures in your application!

To fix the situation we can either provide a callback for the constructor:



class Queue {
  _queue = Promise.resolve();

  // By default onError is empty
  _onError = () => {};

  constructor(onError) {
    this._onError = onError;
  }

  enqueue(fn) {
    const result = this._queue.then(fn);

    this._queue = result.then(() => {}, this._onError);

    return result;
  }

  wait() {
    return this._queue;
  }
}

Or we can re-arm the promise!



class Queue {
  _queue = Promise.resolve();

  enqueue(fn) {
    const result = this._queue.then(fn);
    this._queue = result.then(() => {}, () => {});

    // we changed return result to return result.then() 
    // to re-arm the promise
    return result.then();
  }

  wait() {
    return this._queue;
  }
}

The same test would report a error!

📝 Every promise chain may cause an unhandledRejection error.

If you want to experiment with the code we build: https://codesandbox.io/s/adoring-platform-cfygr5?file=/src/index.js

Wrapping up

Promises are extremely helpful when we need to resolve some complex async interactions.

In the next articles we will talk why JS promises are called sometimes as thenable objects and continue our experiments.

JavaScript Promises #1: how promises work

Nik — Mon, 01 Aug 2022 08:10:00 +0000

TL&DR picture:

Promise is a then-able object. JS has native Promise impl, which is aligned with Promises/A+ standard https://promisesaplus.com/

new Promise((resolve, reject) => {...})

The constructor receives 2 arguments: resolve to fulfill the promise and reject to reject it.

📝 Promise can be in 1 of 3 different states: pending, fulfilled, rejected.

📝 Once a promise changes its state from pending to either fulfilled or rejected, it cannot be changed again

const result = new Promise((resolve, reject) => {
  resolve(1); // pending => fulfilled with value === 1
  resolve(2); // promise is already fulfilled. No effect
  resolve(3); // promise is already fulfilled. No effect
});

result.then((value) => console.log(value)); // 1

Here we use .then, one of the most important elements in promises:

function onResolve(value) {}
function onReject(reason) {}
new Promise((resolve, reject) => {...}).then(onResolve, onReject)

then callback allows you to execute code when the previous promise is fulfilled or rejected.

📝 Every .then callback can be called only once. There are 2 possible scenarios

Promise gets fulfilled
Promise was fulfilled before we call .then, so the callback will be executed in microtask after we reach the end of the current task and execute previously planned microtasks

// we enter to the main task
let resolve; 
const result = new Promise((_resolve) => {
  resolve = _resolve;
});

setTimeout(() => {console.log(3)}, 0); // Plan a timeout, 
// which will be executed in a separate macro task

result.then(value => console.log(1)); // Plan an onResolve callback 
// to the promise, which is in pending state

resolve('Hey'); // resolve the promise with the value == 'Hey'
// At this point, all previously planned `.then` callbacks 
// will be placed in microtask queue. 
// We will have microtask queue:
// value => console.log(1);

result.then(value => console.log(2)); // Put a new callback
// Microtask queue:
// value => console.log(1);
// value => console.log(2)

// End of macrotask
// Execute 2 microtasks one after another and print 1, 2
// End of all planned microtasks
// Execute a new macrotask from timeout
// print 3

📝 Every single then call returns a new promise instance. It allows us to "chain" promises:

📝 .then callbacks are executed in microtask queue:

If we have 3 macrotasks in the queue they will be executed one after another:

However if we plan a microtask during the execution one of the tasks this microtask will be executed right after current macrotask:

If code plans a microtask during the second task execution, this microtask will be executed right after the second task end, but before the third task, despite the third task might be placed in a queue earlier.

📝 Microtasks postpones macrotask execution

An infinite promise chain may "freeze" the tab:

function freeze(value) {
  console.log(value)
  return Promise.resolve(value + 1)
    .then(freeze); // We have async operation here
  // but it plans a new microtask, 
  // which prevents any other macrotask from the execution,
  // including UI updates
}
freeze(1);

As promises are executed in microtask queue, they have slightly different error handling.
Let's take a closer look at it.
To handle an error we can either provide the second callback to .then method or use .catch.
Generally speaking .catch is an alias for .then without the first argument:

.catch(onReject)
// is equal to:
.then(value => value, onReject)

📝 When promise gets rejected, it ignores all onResolve callbacks up to the first onReject handler

Promise.reject('fail')
 .then(value => console.log(1)) // Nothing happens
 .then(value => console.log(2)) // Nothing happens
 .catch(reason => console.log(reason)) // prints "fail"

📝 .catch, .then with onReject callback returns a promise. If you don't reject promise again, it will be fulfilled:

Promise.reject('fail')
 .catch(reason => console.log(reason)) // prints "fail", returns `undefined`
 .then(value => console.log(value)) // prints `undefined`
 .catch(reason => console.log('fail 2')) // Nothing happens, promise is resolved

It's similar to try{}catch(e) {} blocks. If you get into catch(e) {} block you have to re-throw an error, if you want to handle it later. The same works with promises.

📝 Instead of error event, unhandled promise rejections create unhandledrejection event

globalThis.addEventListener("unhandledrejection", (event) => {
  console.warn(`unhandledrejection: ${event.reason}`);
});
Promise.reject('test');

// Would print: "unhandledrejection: test"

📝 Throw in microtask code would reject the promise:

Promise.resolve(1)
  .then(value => {throw value + 1})
  .catch(reason => console.log(reason)) // prints 2

Alternatively you can return Promise.reject:

Promise.resolve(1)
  .then(value => Promise.reject(value + 1))
  .catch(reason => console.log(reason)) // prints 2

When you resolve a promise, resolving it with Promise.reject would also reject it:

new Promise(resolve => resolve(Promise.reject(1)))
  .then(value => Promise.reject(2))
  .catch(reason => console.log(reason)) // prints 1

Utility methods

📝 Promise.all allows you to await before all the promises change their state to fulfilled, or at least one promise gets rejected

const a = Promise.resolve(1);
const b = new Promise((resolve) => {
  setTimeout(() => resolve('foo'), 1000);
});
const c = Promise.resolve('bar');

Promise.all([a, b, c]).then(console.log); // [1, 'foo', 'bar']

If any of the promises gets rejected, Promise.all will be rejected too:

const a = Promise.reject(1); // Now we reject the promise
const b = new Promise((resolve) => {
  setTimeout(() => resolve('foo'), 1000);
});
const c = Promise.resolve('bar');

Promise.all([a, b, c])
  .then(console.log) // Nothing
  .catch(console.log); // 1

📝 Promise.allSettled awaits all promises to change their state. It returns an array with values and the promise statuses

const a = Promise.reject(1); // rejected promise

// 2 resolved promises
const b = new Promise((resolve) => {
  setTimeout(() => resolve('foo'), 1000);
});
const c = Promise.resolve('bar');

Promise.allSettled([a, b, c]).then(console.log); 
// [
//   {status: 'rejected', reason: 1}
//   {status: 'fulfilled', value: 'foo'}
//   {status: 'fulfilled', value: 'bar'}
// ]

📝 Promise.race() method returns a promise that fulfills or rejects as soon as one of the promises fulfills or rejects with the value or reason from that promise

const a = Promise.reject(1); // rejected promise

// 2 resolved promises
const b = new Promise((resolve) => {
  setTimeout(() => resolve('foo'), 1000);
});
const c = Promise.resolve('bar');

Promise.race([a, b, c])
  .then(console.log) // nothing, as the first promise `a` is rejected
  .catch(console.log) // 1

📝 If you put several already fulfilled or rejected promises to the Promise.race, Promise.race will depend on the order of the elements.

So if we change Promise.race([a,b,c]) from the first example, to Promise.race([b,c,a]), the returned promise will be fulfilled with 'bar' value:

const a = Promise.reject(1); // rejected promise

// 2 resolved promises
const b = new Promise((resolve) => {
  setTimeout(() => resolve('foo'), 1000);
});
const c = Promise.resolve('bar');

// We put 'a' at the very end
Promise.race([b, c, a])
  .then(console.log) // 'bar'
  .catch(console.log) // nothing

You can use this trick to test if the promise you have is already resolved or fulfilled.

Summing it up, this article covers base promise mechanisms and execution details. The following articles will cover concurrent and sequential execution, garbage collection, and some of the experiments on top of thenable objects.

Hitchhiker's guide to frontend performance optimization. Part 1. Critical render path

Nik — Mon, 21 Sep 2020 12:45:19 +0000

Critical Render Path. Tutorial

Hi! I'm Nik and I'm a frontend developer. Besides writing code, I was a mentor at HeadHunter's developers school: https://school.hh.ru/

We recorded our lectures in 2018-2019. These lectures are opened on our YouTube channel (but in Russian). Here is a playlist https://www.youtube.com/watch?v=eHWMtfqxjes&list=PLGn25JCaSSFQQOab_xMXI3vJ0tDUkFaCI However, in 2019-2020 school we didn't record our lectures. I had a talk dedicated to frontend performance optimization. After it, I decided to make an article based on the material. As the lecture was 3 hours long, I divided the article into 2 parts.

This longread could be useful as a handbook. We will cover:

Why performance is important;
FMP (First Meaningful Paint), TTI (Time To Interactive);
Critical render path, DOM, CSSOM, RenderTree;
Base steps to improve performance.

The rest of the themes, which were in my lecture, will be in the second article. The second part will cover such topics as layout, reflow, repaint, composite, and their optimization.

Why performance is important. Motivational part.

0.1 seconds — it is a gap when we perceive a connection between our mouse click or keyboard press and changes in the application or interface.

I think almost everybody saw a lag when you input a text, but the interface handles only a previous word. A similar problem exists with button clicks. The good UX helps me, it tells me: "Okay, just a moment and everything will be done". The latest example I had was when I tried to remove a huge number of emails through a web-version in one email webapp (let it be an anonymous service). When I selected emails and clicked the "remove" button, nothing happened. At those moments I didn't understand either I misclicked or the interface had a lag. The second variant was correct :) It is frustrating. I want to have a responsive interface.

Why should it be 0.1 seconds? The key is that our consciousness makes connections between our actions and the definite changes in the website and 100ms is a good time for it.

Let me show an example. Here is a video clip of 30 Seconds to mars — Hurricane (be careful, it is an explicit one, and has some NSFW parts. You can open the clip on 9:30 and you will be able to catch frames, which we are talking about, during the next 30 seconds): https://www.youtube.com/watch?v=MjyvlD0TwiA this clip has several moments when a screen appears for only 1-2 frames. Our consciousness not only handles this screen but recognizes content (partly).

1 second is a perfect time to load a site. Users perceive surfing smoothly in this case. If your service could be loaded within 1 second you are awesome! Unfortunately, we have a different situation in general.

Let's count what we have to do when a user navigates to our site: network outgoings, backend processings, microservice queries (usually), DB queries, templating, data processing on the client-side (we are going to talk about it today), static resource loading, script initialization. Summing up: it's painful.

That's why usually 1 second is ideal timing.

10 seconds. Lots of analytics tell us that people spend about 30 seconds visiting a website on average. A site that is loaded 5 seconds consumes 1/6 of user time. 10 seconds — a third.

The next numbers are 1 minute and 10 minutes. 1 minute is a perfect time to complete a small task using a site like reading product info or getting registered. Why should it be only a minute? We don't spend much time these days concentrating on one thing. We change objects of our attention pretty often.

Opened an article, read the tenth part of it, then a colleague sent a meme on Slack, web-site trigger alerted, wow coronavirus news, all of it. Only in the evening, you get time to read an article.

When a user spent 10 minutes on a site, it means they tried to solve their problem at least. They compared plans, made an order, etc.

Big companies have good analytics for performance metrics:

Walmart: 1 second means + 2% conversion
Amazon: 0,1 seconds increase proceeds for 1%

The latest motivator is from Wikipedia:

https://twitter.com/wikipedia/status/585186967685619712

Let's go further:

Two eternal questions

Let's run a lighthouse check on hh.ru. Looks pretty bad (pay attention it's a mobile configuration of the lighthouse):

Here we have 2 traditional questions:

1) Who's to blame for this? :) (and it's better to replace with a question why we have this)

2) What do we do with it?

Spoiler: there won't be a picture of how good our metrics became at the end.

Let's dive

We have 3 common scenarios:

First paint
Page processing (user clicks, data input, etc.)
SPA — changing pages without reloading

Talking about first-page loading, we have 2 the most important stages of page readiness from the user's point of view: FMP (First Meaningful Paint) and TTI (Time to interactive):

FMP for users indicates that we have text, and they can start consuming content (of course in case you are not Instagram or youtube).

TTI === the site is ready to work. Scripts are downloaded, initialized, all resources are ready.

The most important metric for HeadHunter (hh.ru) is FMP, as applicants base behavior is to open vacancies search and then open each vacancy in a new tab so that users can read them one by one and make a decision whether they want to apply to this vacancy or not.

With some nuances, FMP is one of the best metrics to measure websites' critical render path. A critical render path is a number of actions, resources, which should be downloaded and processed by the browser before showing a first result appropriate to users' work. Minimal resources, we have to download, are HTML, CSS stylesheets, and blocking js scripts.

Critical render path or what the browsers do to show user text

TL&DR;

0) Make a navigate request (DNS resolve, TCP request, etc.)

1) Receive HTML-doc;

2) Parse HTML

3) Build the DOM (Document object model)

4) Send requests to download blocking resources (works in parallel with the previous process)

5) Receive blocking resources, especially CSS-code. In case we have blocking JS code, execute it.

6) Rebuild the DOM if needed (especially in case blocking JS mutates DOM)

7) Make CSSOM tree

8) Build Render tree

9) Draw a page (Layout ⇒ paint ⇒ Composite)

Note: Reflow could be executed additionally on previous stages, due to the fact that js could force it. We will cover this part in the second article

In details:

Request

Make a request, resolve DNS, IP, TCP, etc. Bytes are running through the sockets, the server receives a request.

Response

Backends execute a request, write bytes into the socket. We receive the answer like this:

We receive a bunch of bytes, form a string due to the text/html data type. Interesting thing: first requests are marked by the browser as a "navigate" request. You can see it if you subscribe to fetch action in ServiceWorker. After receiving data, the browser should parse it and make DOM.

DOM processing

DOM

We receive a string or a Stream. In this stage browser parses it and transform a string into a special object (DOM):

This is only a carcass. At this point, the browser knows nothing about styles, hence it doesn't know how to render the page.

Downloading of Blocking resources

Browsers synchronously process HTML. Each resource either CSS or JS could be downloaded synchronously or asynchronously. When we download a resource synchronously we block the rest of DOM processing before we receive it. That's why people recommend putting blocking javascript without defer and async attributes right before the closing body tag.

So each time browsers get to the blocking resource, they make a request, parse the response, and so on. Here we have some limitations such as the max number of simultaneous domain requests.

After all blocking resources are received, we can form CSSOM

CSSOM

Let's suggest, besides meta and title tags we have style or link. Now browsers merge DOM and CSS and make an object model for CSS:

The left part of the object (head and the children) isn't interesting for CSSOM, as it wouldn't be shown to the user. For the rest of the nodes, we define styles, which browsers will apply.

CSSOM is important, as it helps us to form RenderTree.

RenderTree

The last step between making trees and render.

At this stage, we form a tree that will be rendered. In our example, the left part won't be rendered, so we will remove it:

This tree will be rendered.

However, we could get a question. Why do we render "RenderTree" instead of DOM? We can check it easily by opening DevTools. Even though DevTools has all DOM elements, all computed styles are based on RenderTree:

Here we selected a button in the Elements tab. We got all the computed data of the button: its size, position, styles, even inherited ones, etc.

After making the RenderTree the browser's next task is to execute Layout ⇒ Paint ⇒ Composite for our app. Once the Composite is ended user will see the site.

Layout ⇒ Paint ⇒ Composite could be a problem not only for the first render but also during user interaction with the website. it's why I moved this part to another article.

What can we do to improve FMP and TTI?

TL&DR;

1) Resource optimization:

1.1) Split blocking resources by pages both js and css. Store reusable code either into common chunks, or small separated modules;

1.2) Load what the user needs at the beginning of work with the page (very controversial part!).

1.3) Separate third-party scripts

1.4) Download images lazily

2) HTTP2.0 / HTTP3.0:

2.1) Multiplexing

2.2) Headers compression

2.3) Server push

3) Brotli

4) Cache, ETag + Service worker

Detailed:

Working with resources

Splitting blocking resources. JS

The main pain is 2 things: blocking resources and their size.

The general advice for big sites is to split blocking styles and resources by pages. All reusable code should be stored in common chunks or separated modules. For this purpose, we are able to use suppositive https://github.com/gregberge/loadable-components or https://github.com/theKashey/react-imported-component to react or any similar solution for vue, angular, and etc. In case our components import styles it becomes easy to split them too.

As a result we get:

1) Bundles with reused js modules and page ones. Splitting strategies could be varied. it's possible to make bundles that combine common code for 2 or more pages or just split whether it's page part or common with only 1 common bundle.

Better to see the difference on a scheme:

Initial arrangement:

Strategy 1 makes a dependency: module ⇒ pages that use it:

So, to load the main page (index.html) we should download 2 bundles: Common.js + applicant+index.js. /applicant page is required to load all 4 bundles. It's common to have a huge number of such chunks for big sites. In this case, it helps us to fix this problem using HTTP2.0.

Summing this strategy up:

+: Code is distributed between pages, we don't download unnecessary chunks;

+: Modules could be cached. Releases don't require to update all the bundles, only necessary ones;

-: A lot of network costs to get separated chunks. (fixed by HTTP2.0 multiplexing).

Strategy 2: store each reused module separately

Each file that is used more than in 1 page will be stored in a separate file. It means we get a tragic increase in small files. The most frustrating part is that chrome doesn't cache files which less than 1Kb. So that we are going to lose caching following this strategy.

+: Releases have the smallest influence on our users' caches;

-: The bigger amount of network costs in comparison with 1 strategy;

-: Caches could not work properly as lots of files could be less than 1 Kb. The only way to fix it is to use a Service worker. We'll talk about it below.

This strategy could be quite good, as all the cons could be solved.

Strategy 3: Store a big bundle of all modules which is used more than in 1 page:

+: The smallest amount of files. Any page requires only %page%.js + Common.js;

-: Significant amount of unused js will be downloaded during the first load;

-: A high probability of losing Common.js cache after release. (as it seems, that each release is about to have changed in a module which is included by Common.js)

My advice is not to use this strategy or use it only for small websites.

But this strategy is still not as bad as the next one:

Anti-strategy 1: Each page has its own dependencies. We separate modules which are included by all the pages (common for all pages):

The biggest overhead we get here. When a user changes the page, they have to download modules they already have. For instance, a user opens the main page and gets 2 chunks: Common.js + Index.js. Then they authorized and navigates to the applicant page. So, Dropwon.js and Graph.js will be downloaded twice.

Please, don't do this ;)

Wrapping this up: The first two strategies are the most suitable for big websites. Likely they will have notable improvement of TTI. If you have render-blocking JS, the main question is why it's blocking. Should it block render? Try to eliminate such resources or decrease their number.

Offtopic. Why 30Kb of JS is more tragic than 30Kb of images

Suggest we have JS that animate a page and make some popups. Besides js, we have a picture of the same size (in Kb).

To run JS it's required to download the code, parse it, serialize to code which will be suitable for the interpretation, and finally execute it. So, it's why the costs of executing JS are higher than processing an image.

Splitting blocking resources. CSS

This improvement has a direct influence on FMP (of course in case you don't work with async CSS).

If you use react \ vue \ angular all the things you should do is the same as JS splitting. As for example in your react code it's likely you have direct imports:



import './styles.css'

It means during JS bundling we are able to split CSS also, following to one of the described strategies. We'll get common.css, applicant-page.css, and applicant+employer.css as well.

In case you don't have direct imports, you could try https://github.com/theKashey/used-styles to define page styles. Here is an article about this tool https://dev.to/thekashey/optimising-css-delivery-57eh.

It helps to speed up the download. For example in the case of hh.ru for almost a second according to lighthouse analytics:

Load what the user sees, not the whole page.

Likely your page has several screens, in other words a user doesn't see the whole page on their first screen. Besides it, some functions hide under the clicks, actions, etc.

The idea of optimization is to manage the resources loading process. In the beginning, load in a blocking way the CSS, which is vital to open the page. All CSS that refers to pop-ups or hidden under JS code could be loaded asynchronously, for instance, by adding rel=stylesheet from JS code or by using prefetch with onload callback. There is no general advice on how to do it. You have to check the site and find out which elements could be downloaded asynchronously.

In this case, we increase the complexity but improve the FMP metric.

Taking out third-party scripts

We do have a huge amount of 3d-party scripts at hh.ru

7 out of 10 the heaviest scripts are third-party:

What can we do with this?

Make sure, all the resources will load asynchronously and don't have an influence on FMP
Reduce the harmful influence to your code from ads and other things like analytics, technical support popups. You can postpone their initialization using requestIdleCallback. This function will plan callback with the lowest priority when it wouldn't be any tasks in the queue.

This recipe allows us to retrench on FMP, but TTI will still have downgrades. As we just postpone them, to reach a better user experience.

Loading images lazily

Images affect our TTI. If you find out that the users suffer from heavy images, try to load images that don't appear on the first screen lazily. In other words:

Images from the first screen should be loaded as usual
The rest of the images should have special attributes, to load them when the user's viewport reaches each image.
To load images we can use any library or our own solution. Here is an article about this method: https://css-tricks.com/the-complete-guide-to-lazy-loading-images/

HTTP2.0

In general, you don't reach a high level of optimization, but it's still important

HTTP2.0 Multiplexing

In case the website downloads a lot of resources HTTP2.0 with multiplexing could help.

Suggest, we have 6 render-blocking resources placed on the same domain. Styles, blocking js code, etc.

The browser makes parallel request to each resource:

Browsers limit the number of simultaneous requests to the domain in one browser's tab. Hence, some resources will be requested after receiving a response from the previous resource.

Each resource has time-consuming stages like TCP handshake and other costs. They aren't big but exist.

it's why developers reduce the number of resources that are needed to render the page.

What is multiplexing?

Multiplexing allows us to load resources inside the exact one HTTP-request:

Of course, we could have not the exact 1 request. It could be 2, 3, and so on. Each request loads some resources. It allows us to save time on handshakes, resolves, etc, and we optimize the limitation of simultaneously downloading resources

HTTP2.0 Headers compressing

We haven't had headers compressing before http2.0. HTTP2.0 announced HPACK that is in charge of it. More detailed information: https://tools.ietf.org/html/rfc7541

Sometimes headers could be big. Here is how HPACK works in short:

Huffman coding as an algorithm and 2 dictionaries:

1) Static one — for base headers

2) Dynamic — for custom

HTTP2.0 Server push

For small websites, static ones, or landing pages it's not a problem to implement server push. The idea is simple: we encapsulate the information to our web-server that the user has to download several resources besides the requested page.

Nginx example:



location = /index.html {
    http2_push /style.css;
    http2_push /bundle.js;
    http2_push /image.jpg;  
}

Let's check it:

In case you have a big website you have to set up a complex pipe-line when after bundling, chunk names should be listed in some dictionary, which will be used as a base for you nginx htt2_push config.

Resource compressing

The most popular solution is to use gzip or brotli. This website gives a good comparison between these algorithms: https://tools.paulcalvano.com/compression.php

We migrated from gzip to brotli one and a half years ago. The size of our main bundle was reduced from 736 Kb to 657. We saved almost 12%.

The biggest disadvantage of Brotli that it has bigger costs for "packing" data. It's heavier than gzip on average. So you could make a rule on nginx to cache resources that are packed by brotli or put already brotled resources. (the same thing you could do with gzip).

But brotli in most cases is better than gzip. It allows saving 1-1.5 sec of downloading in poor 3G networks, which notably improve both user experience and lighthouse metrics.

Caching

Note: Described method doesn't improve your lighthouse metrics, but it helps for real users. It could improve both FMP and TTI.

The base cache could be turned on using headers. An advanced way is to use the Service worker additionally.

Talking about headers we have 3 params:

1) last-modified or expires

2) ETag

3) Cache-control

The first two params (last-modified and expires) work around the date, the second ETag is a key (or hash-sum) that is used during the request, and if the requested key is the same as the server's one, the server response with 304. In case they are not the same, the server sends the whole resource. It's easy to turn on caching:



location ~* ^.+\.(js|css)$ {    
  ...
    etag on;
}

Disk cache is checkable using dev tools:

Cache-control is a strategy of how we're going to cache the resources. We are able to turn it off by setting cache-control: no-cache, which is quite suitable for html requests that change a lot (like search pages). The second strategy is to set a big value for max-age so that data store as long as possible. For our static at hh.ru we use the following:



cache-control: max-age=315360000, public

We release our services often (several times per day for each service). It means, people have to load our new bundles, parse code, and so on several times each day.

To dive deeper how browsers execute code and use caches I advice to read a great article in v8 blog: https://v8.dev/blog/code-caching-for-devs

We are interested in this scheme:

So there are "3 ways" of running our application: cold \ warm, and hot run.

The ideal scenario for us is to run the application in the "hot run" way. It allows us not to spend our time for code compilation. It's enough just to deserialize it.

To get hot run a user has to get to the site 3 times (for the same resources) per 72 hours timeslot. If a user gets to the website only 2 times it will be a warm run, which still compiles the data and serialize it to the disk cache.

But we do have a workaround and can force hot run using Service Worker. The method is the following:

1) Set up Service Worker

2) Subscribe to fetch

3) If fetch is evaluated to get site static, save static into the cache

4) If fetch is evaluated to get cached static resource, send it.

This method forces the disk cache to store the data and to use the hot run starting the second time. Also, it leads to bigger optimization for mobile devices as they reset the regular cache more often than desktops.

Minimal code for Service Worker:



self.addEventListener('fetch', function(event) {

        // Cache static resource, but not the images

    if (event.request.url.indexOf(staticHost) !== -1 && event.request.url.search(/.(svg|png|jpeg|jpg|gif)/) === -1) {

        return event.respondWith(

                        // Check whether data in cache

            caches.match(event.request).then(function(response) {

                if (response) {

                    return response;

                }

                                // If we don't have the resource in the cache, make a request and cache it

                return fetch(event.request).then(function(response) {

                    caches.open(cacheStatic).then(function(cache) {

                        cache.add(event.request.url);

                    });

                <span class="k">return</span> <span class="nx">response</span><span class="p">;</span>
            <span class="p">});</span>
        <span class="p">})</span>
    <span class="p">);</span>
<span class="p">}</span>



});

Summing up

We dived into our Critical render path from the client-side (but we don't check such things like DNS resolving, handshakes, DB request, and etc.) We defined steps in which browsers arrange to render a page for users.

We reviewed different optimization methods like content splitting, caching, compressing.

The second part will be dedicated to websites runtime and how browsers "draw" frames.

Dealing with callbacks as props in React

Nik — Sun, 17 Feb 2019 15:58:43 +0000

TL;DR

Don't mix JSX and business-logic in one place, keep your code simple and understandable.
For small optimizations, you can cache function in class properties for classes or use the useCallback hook for function components. In this case, pure components won't be re-rendered every time when their parent gets re-rendered. Especially, callbacks caching is effective to avoid excess updating cycles when you pass functions as a prop to PureComponents.
Don't forget that event handler receives a synthetic event, not the original event. If you exit from the current function scope, you won't get access to synthetic event fields. If you want to get fields outside the function scope you can cache fields you need.

Part 1. Event handlers, caching and code readability

React has quite a convenient way to add event handlers for DOM elements.
This is one of the first basic things that beginners face with.

class MyComponent extends Component {
  render() {
    return <button onClick={() => console.log('Hello world!')}>Click me</button>;
  }
}

It's quite easy, isn't it? When you see this code, it isn't complicated to understand what will happen when a user clicks the button.
But what should we do, if the amount of the code in event handlers become more and more?
Let's assume, we want to load the list of developers, filter them (user.team === 'search-team') and sort using their age when the button was clicked:

class MyComponent extends Component {
  constructor(props) {
    super(props);
    this.state = { users: [] };
  }
  render() {
    return (
      <div>
        <ul>
          {this.state.users.map(user => (
            <li>{user.name}</li>
          ))}
        </ul>
        <button
          onClick={() => {
            console.log('Hello world!');
            window
              .fetch('/usersList')
              .then(result => result.json())
              .then(data => {
                const users = data
                  .filter(user => user.team === 'search-team')
                  .sort((a, b) => {
                    if (a.age > b.age) {
                      return 1;
                    }
                    if (a.age < b.age) {
                      return -1;
                    }
                    return 0;
                  });
                this.setState({
                  users: users,
                });
              });
          }}
        >
          Load users
        </button>
      </div>
    );
  }
}

This code is so complicated. The business-logic part is mixed with JSX elements.
The simplest way to avoid it is to move function to class properties:

class MyComponent extends Component {
  fetchUsers() {
    // Move business-logic code here
  }
  render() {
    return (
      <div>
        <ul>
          {this.state.users.map(user => (
            <li>{user.name}</li>
          ))}
        </ul>
        <button onClick={() => this.fetchUsers()}>Load users</button>
      </div>
    );
  }
}

We moved business-logic from JSX code to separated field in our class. The business-logic code needs to get access to this, so we made the callback as: onClick={() => this.fetchUsers()}

Besides it, we can declare fetchUsers class field as an arrow function:

class MyComponent extends Component {
  fetchUsers = () => {
    // Move business-logic code here
  };
  render() {
    return (
      <div>
        <ul>
          {this.state.users.map(user => (
            <li>{user.name}</li>
          ))}
        </ul>
        <button onClick={this.fetchUsers}>Load users</button>
      </div>
    );
  }
}

It allows us to declare callback as onClick={this.fetchUsers}

What is the difference between them?

When we declare callback as onClick={this.fetchUsers} every render call will pass the same onClick reference to the button.
At the time, when we use onClick={() => this.fetchUsers()} each render call will init new function () => this.fetchUsers() and will pass it to the button onClick prop. It means, that nextProp.onClick and prop.onClick won't be equal and even if we use a PureComponent instead of button it will be re-rendered.

Which negative effects can we receive during the development?

In the vast majority of cases, we won't catch any visual performance issues, as Virtual DOM doesn't get any changes and nothing is re-rendered physically.
However, if we render big lists of components, we can catch lags on a big amount of data.

Why it's important to understand how functions are passed to the prop?

You can often find on Twitter or StackOverflow such advice:

"If you have issues with performance in React application, try to change inheritance in problem places from Component to PureComponent, or define shouldComponentUpdate to get rid of excess updating cycles".

If we define a component as a PureComponent, it means, that it has already the shouldComponentUpdate function, which implements shallowEqual between its props and nextProps.

If we set up new references as props to PureComponent in updating lifecycle, we'll lose all PureComponent advantages and optimizations.

Let's watch an example.
We implement Input component, that will show a counter representing the number of its updates

class Input extends PureComponent {
  renderedCount = 0;
  render() {
    this.renderedCount++;
    return (
      <div>
        <input onChange={this.props.onChange} />
        <p>Input component was rerendered {this.renderedCount} times</p>
      </div>
    );
  }
}

Now we create two components, which will render the Input component:

class A extends Component {
  state = { value: '' };
  onChange = e => {
    this.setState({ value: e.target.value });
  };
  render() {
    return (
      <div>
        <Input onChange={this.onChange} />
        <p>The value is: {this.state.value} </p>
      </div>
    );
  }
}

Second:

class B extends Component {
  state = { value: '' };
  onChange(e) {
    this.setState({ value: e.target.value });
  }
  render() {
    return (
      <div>
        <Input onChange={e => this.onChange(e)} />
        <p>The value is: {this.state.value} </p>
      </div>
    );
  }
}

You can try the example here: https://codesandbox.io/s/2vwz6kjjkr
This example shows how we can lose all the advantages of PureComponents if we set the new references to the PureComponent every time in the render.

Part 2. Using event handlers in function components

The new React hooks mechanism was announced in the new version of React@16.8 (https://reactjs.org/docs/hooks-intro.html). It allows implementing full-featured function components, with full lifecycle built with hooks. You are able to change almost all class components to functions using this feature. (but it isn't necessary)

Let's rewrite Input Component from classes to functions.

Input should store the information about how many times it was re-rendered. With classes, we are able to use instance field via this keyword. But with functions, we can't declare a variable with this. React provides useRef hook which we can use to store the reference to the HtmlElement in DOM tree. Moreover useRef is handy to store any mutable data like instance fields in classes:

import React, { useRef } from 'react';

export default function Input({ onChange }) {
  const componentRerenderedTimes = useRef(0);
  componentRerenderedTimes.current++;

  return (
    <>
      <input onChange={onChange} />
      <p>Input component was rerendered {componentRerenderedTimes.current} times</p>
    </>
  );
}

We created the component, but it isn't still PureComponent. We can add a library, that gives us a HOC to wrap component with PureComponent, but it's better to use the memo function, which has been already presented in React. It works faster and more effective:

import React, { useRef, memo } from 'react';

export default memo(function Input({ onChange }) {
  const componentRerenderedTimes = useRef(0);
  componentRerenderedTimes.current++;

  return (
    <>
      <input onChange={onChange} />
      <p>Input component was rerendered {componentRerenderedTimes.current} times</p>
    </>
  );
});

Our Input component is ready. Now we'll rewrite A and B components.
We can rewrite the B component easily:

import React, { useState } from 'react';
function B() {
  const [value, setValue] = useState('');

  return (
    <div>
      <Input onChange={e => setValue(e.target.value)} />
      <p>The value is: {value} </p>
    </div>
  );
}

We have used useState hook, which works with the component state. It receives the initial value of the state and returns the array with 2 items: the current state and the function to set the new state. You can call several useState hooks in the component, each of them will be responsible for its own part of the instance state.

How can we cache a callback? We aren't able to move it from component code, as it would be common for all different component instances.
For such kind of issues React has special hooks for caching and memoization. The handiest hook for us is useCallback https://reactjs.org/docs/hooks-reference.html

So, A component is:

import React, { useState, useCallback } from 'react';
function A() {
  const [value, setValue] = useState('');

  const onChange = useCallback(e => setValue(e.target.value), []);

  return (
    <div>
      <Input onChange={onChange} />
      <p>The value is: {value} </p>
    </div>
  );
}

We cached function so that Input component won't be re-rendered every time when its parent re-renders.

How does useCallback work?

This hook returns the memoized version of the function. (that meant the reference won't be changed on every render call).
Beside the function which will be memoized, this hook receives a second argument. In our case, it was an empty array.
The second argument allows passing to the hook the list of dependencies. If at least one of this fields gets changed, the hook will return a new version of the function with the new reference to enforce the correct work of your component.

The difference between inline callback and memoized callback you can see here: https://codesandbox.io/s/0y7wm3pp1w

Why array of dependencies is needed?

Let's suppose, we have to cache a function, which depends on some value via the closure:

import React, { useCallback } from 'react';
import ReactDOM from 'react-dom';

import './styles.css';

function App({ a, text }) {
  const onClick = useCallback(e => alert(a), [
    /*a*/
  ]);

  return <button onClick={onClick}>{text}</button>;
}
const rootElement = document.getElementById('root');
ReactDOM.render(<App text={'Click me'} a={1} />, rootElement);

The component App depends on a prop. If we execute the example, everything will work correctly. However as we add to the end re-render, the behavior of our component will be incorrect:

setTimeout(() => ReactDOM.render(<App text={'Next A'} a={2} />, rootElement), 5000);

When timeout executes, click the button will show 1 instead of 2. It works so because we cached the function from the previous render, which made closure with previous a variable. The important thing here is when the parent gets re-rendered React will make a new props object instead of mutating existing one.
If we uncomment /*a*/ our code will work correctly. When component re-renders the second time, React hook will check if data from deps have been changed and will return the new function (with a new reference).

You can try out this example here: https://codesandbox.io/s/6vo8jny1ln

React has a number of functions, which allow memoizing data: useRef, useCallback and useMemo.
The last one is similar to useCallback, but it is handy to memoize data instead of functions. useRef is good both to cache references to DOM elements and to work as an instance field.

At first glance, useRef hook can be used to cache functions. It's similar to instance field which stores methods. However, it isn't convenient to use for function memoization. If our memoized function uses closures and the value is changed between renders the function will work with the first one (that was cached). It means we have to change references to the memoized function manually or just use useCallback hook.

https://codesandbox.io/s/p70pprpvvx — here is the example with the right useCallback usage and wrong useRef one.

Part 3. Synthetic events

We've already watched how to use event handlers, how to work with closures in callbacks but React also have differences in event objects inside event handlers.

Take a look at the Input component. It works synchronously. However, in some cases, you would like to implement debounce or throttling patterns. Debounce pattern is quite convenient for search fields, you enforce search when the user has stopped inputting symbols.

Let's create a component, which will call setState:

function SearchInput() {
  const [value, setValue] = useState('');

  const timerHandler = useRef();

  return (
    <>
      <input
        defaultValue={value}
        onChange={e => {
          clearTimeout(timerHandler.current);
          timerHandler.current = setTimeout(() => {
            setValue(e.target.value);
          }, 300); // wait, if user is still writing his query
        }}
      />
      <p>Search value is {value}</p>
    </>
  );
}

This code won't work. React proxies events and after synchronous callback React cleanups the event object to reuse it in order to optimization. So our onChange callback receives Synthetic Event, that will be cleaned.

If we want to use e.target.value later, we have to cache it before the asynchronous code section:

function SearchInput() {
  const [value, setValue] = useState('');

  const timerHandler = useRef();

  return (
    <>
      <input
        defaultValue={value}
        onChange={e => {
          clearTimeout(timerHandler.current);
          const pendingValue = e.target.value; // cached!
          timerHandler.current = setTimeout(() => {
            setValue(pendingValue);
          }, 300); // wait, if user is still writing his query
        }}
      />
      <p>Search value is {value}</p>
    </>
  );
}

Example: https://codesandbox.io/s/oj6p8opq0z

If you have to cache the whole event instance, you can call event.persist(). This function removes your Synthetic event instance from React event-pool. But in my own work, I've never faced with such a necessity.

Conclusion:

React event handlers are pretty convenient as they

implement subscription and unsubscription automatically
simplify our code readability

Although there are some points which you should remember:

Callbacks redefinition in props
Synthetic events

Callbacks redefinition usually doesn't make the big influence on visual performance, as DOM isn't changed. But if you faced with performance issues, and now you are changing components to Pure or memo pay attention to callbacks memoization or you'll lose any profit from PureComponents. You can use instance fields for class components or useCallback hook for function components.