The way you call them seems the same:

useEffect(() => {
  // side effects
  return () => /* cleanup */
}, [dependency, array]);

useLayoutEffect(() => {
  // side effects
  return () => /* cleanup */
}, [dependency, array]);

However, they are not the same. Let's see what makes them different and when to use each one. (tl; dr: most of the time you want to use useEffect)

The Difference Between useEffect and useLayoutEffect It's all about the timing of execution.

useEffect is executed asynchronously and after a rendering is painted on the screen.

So it looks like this:

You trigger a rendering somehow (change the state or the parent component is rendered again). React renders your component (calls your component). The screen is visually updated. ONLY THEN useEffect is executed.

useLayoutEffect, on the other hand, is executed synchronously after a rendering but before the screen update. This means:

You trigger a rendering somehow (change the state or the parent component is rendered again). React renders your component (calls your component). useLayoutEffect is executed, and React waits for it to finish. The screen is visually updated.

99% of the Time, useEffect In most cases, your effect is synchronizing some state or object with something that doesn't need to happen IMMEDIATELY or doesn't visually affect the page.

For example, if you are fetching data from a server, it won't result in an immediate change.

Or if you are setting up an event handler.

Or if you are resetting some state when a modal dialog appears or disappears.

Most of the time, useEffect is the right way to go.

When to use useLayoutEffect What is the right time to use useLayoutEffect? You'll know when you see it. Literally ;)

If your component flickers when the state is updated—meaning, it is first rendered in a partially ready state and then rendered again in its final state—that's a good clue that it's time to switch to useLayoutEffect.

Here's an example (artificial) so you can understand what I mean.

When you click on the page ([A]), the state immediately changes (value is reset to 0), which re-renders the component, and then the effect is executed—which sets the value to some random number and is rendered again.

The result is that two renderings happen in quick succession.

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

const BlinkyRender = () => {
  const [value, setValue] = useState(0);

  useLayoutEffect(() => {
    if (value === 0) {
      setValue(10 + Math.random() * 200);
    }
  }, [value]);

  console.log('render', value);

  return (
    <div onClick={() => setValue(0)}>
      value: {value}
    </div>
  );
};

ReactDOM.render(
  <BlinkyRender />,
  document.querySelector('#root')
);

[A]: In general, putting onClick handlers on divs is bad for accessibility (use buttons!), this is a disposable demo. I just wanted to mention it!

Try both versions:

Version with useLayoutEffect

import React, { useState, useLayoutEffect } from "react";
import ReactDOM from "react-dom";
import "./styles.css";

const BlinkyRender = () => {
  const [value, setValue] = useState(0);

  useLayoutEffect(() => {
    if (value === 0) {
      setValue(10 + Math.random() * 200);
    }
  }, [value]);

  console.log("render", value);

  return (
    <div onClick={() => setValue(0)}>value: {value}</div>
  );
};

ReactDOM.render(
  <BlinkyRender />,
  document.querySelector("#root")
);

Version with useEffect — Visual flicker

import React, { useState, useEffect } from "react";
import ReactDOM from "react-dom";
import "./styles.css";

const BlinkyRender = () => {
  const [value, setValue] = useState(0);

  useEffect(() => {
    if (value === 0) {
      setValue(10 + Math.random() * 200);
    }
  }, [value]);

  console.log("render", value);

  return (
    <div onClick={() => setValue(0)}>value: {value}</div>
  );
};

ReactDOM.render(
  <BlinkyRender />,
  document.querySelector("#root")
);

Notice how the useLayoutEffect version visually updates only once, even though the component has been rendered twice. The useEffect version, on the other hand, visually renders twice, where you can briefly see the value as 0.

Should I Use useEffect or useLayoutEffect? Most of the time, useEffect is the right choice. If your code is causing rendering flickers, switch to useLayoutEffect and see if that helps.

Since useLayoutEffect is synchronous (blocks rendering), and the app won't visually update until the effect finishes executing... this can cause performance issues if you have slow code in your effect. Along with the fact that most effects don't need the world to pause while they happen.

In this post, we'll present a way to avoid excessive useState usage in a React component by grouping related states into an object and managing them with a single useState.

The first step is to create an initial object that contains all the related states. For example, if you have states for "name" and "age," you can create an initial object like this:

const initialState = {
  name: '',
  age: ''
}

Next, use useState to manage the entire object. For example:

const [state, setState] = useState(initialState);

When you need to update a specific state, use setState to update the entire object. For example:

const handleNameChange = (event) => {
  setState({
    ...state,
    name: event.target.value
  });
}

To access individual states, you can destructure them from the entire object. For example:

const { name, age } = state;

Conclusion

This way, you can avoid excessive useState usage and keep your code more organized and manageable. By grouping related states into an object and managing them with a single useState, you can maintain clear and simple code without sacrificing flexibility and scalability.

I have done it, and I know that many programmers have had the experience of explaining a programming problem to someone else, possibly even to someone who knows nothing about this universe, and magically finding the solution during the explanation of the problem.

But how is this possible? By describing what the code should do and observing what it does, any differences between these processes become clearer and more noticeable. In general, explaining or teaching about a particular subject forces you to understand the case from different perspectives, aiding in the understanding of the problem.

But does it have to be a rubber duck? No, of course not. It can be anything. The duck is used as a representative figure in the book. Personally, I explain most of my code problems to a coworker or my little toy duck, Patolino, who sits at my desk.

The tip is: you can use a rubber duck or any other discreet object you can talk to (yes, programming is like that, folks, you have to be a bit crazy).

The Explanation

It does work, and there is a whole psychological study behind how all of this works. The summary is that when we speak out loud, our brain can process the details better, and as a result, our attention to details or errors becomes sharper, allowing us to find problems more quickly.

The figure of a rubber duck, which we assume knows nothing about programming or any particular subject, requires us to explain in more detail what we are thinking when writing that block of code. By doing this, we are forced, while explaining the problem, to pay more attention to what we were previously doing alone.

Well, that's all! Thank you for reading, and here's the link to the book The Pragmatic Programmer.

But did you know that there's more to the console than just a log? In this post, I bring you two additional functionalities to print to the console in JS.

.log()

The console.log() method is the simplest and most well-known, which generates a message to your browser's console. The message can be a single string or one or more JavaScript objects.

const x = 'Test'
console.log(x)

In this example, 'Test' will be returned in the console, pretty simple, right?

We can also include multiple values in the console. Add a string at the beginning to identify what you're logging.

const x = 'Test'
console.log("value", x)

But what if we have multiple values to show?

const x = 'Test'
const y = 'Super test'
const z = 'Mega test'

Would we use console.log 3 times? No! We can include all of them in one and still add a string to identify each of them.

const x = 'Test'
const y = 'Super test'
const z = 'Mega test'
console.log('x:', x, 'y:', y, 'z:', z)

But that's a lot of work. To make it easier, simply wrap the variables inside curly braces to transform the log into an object.

const x = 'Test'
const y = 'Super test'
const z = 'Mega test'
console.log({x, y, z})

Log Variations

There are other variations to improve visibility in the browser console.

console.log('Simple console log')
console.info('Information console')
console.debug('Debug console')
console.warn('Warning console')
console.error('Error console')

Each of these has a different interaction with the browser, making debugging easier. You can add styles to the logs, for example, where a warning will appear in yellow and an error in red.

The styles may vary depending on your browser.

.assert()

We can also add conditionals to the browser console. By using assert(), we can print the log according to the boolean value of the information.

const works = false
console.assert(works, 'This is the reason')

If the first argument of assert is false, the message will be printed in the console. But if it returns true, it won't appear.

.count()

Yes, it's possible to create a counter within the console.

for (i = 0; i < 10; i++) {
  console.count()
}

Each iteration of the loop will print a counter in the console. In this case, you will see the default: 1 up to default: 10. If you execute the loop again, it will continue from where it left off, starting from 11 up to 20.

To reset the counter, you can use the console.countReset() after the loop.

.Time()

In addition to counting, we can also time the execution using the console.time(). However, it alone can't do much. To demonstrate, let's create a small interval that simulates rendering using setTimeout(). Within this time limit, we'll use console.timeEnd() to get the final execution time.

console.time()
setTimeout(() => {
  console.timeEnd()
}, 2000)

By executing this code snippet, you can see that the console will display the time it took to execute the setTimeout().

We can also display the elapsed time using timeLog to label a timer.

console.time()
setTimeout(() => {
  console.timeLog()
}, 2000)

.Table()

Want to see your log as a table? It's possible with .table(). This is one of the uses to improve the visualization of certain objects.

let devices = [
  {
    name: 'iPhone',
    brand: 'Apple'
  },
  {
    name: 'Galaxy',
    brand: 'Samsung'
  },
  {
    name: 'Pixel',
    brand: 'Google'
  },
  {
    name: 'Poco',
    brand: 'Huawei'
  }
]
console.table(devices);

.clear()

Have trouble finding a log due to the multiple renders you're doing on the page? Are you constantly refreshing and getting lost in the browser console?

Simple, add console.clear() at the beginning of your code, and every time you render, you'll have a fresh console.

Just don't add it at the end of your code 🤪🤪🤪

Well, that's all! Thank you for reading, and of course, there are many other logs you can use.

Explore the documentation: https://developer.mozilla.org/enUS/docs/Web/API/Console

If you need inspiration for the project, I use the dribble to search for design references but don't worry too much about searching, I'll leave some templates for each API!

✋🏻 Don't forget to credit the designer, ok.

PokeAPI

Have you ever thought about creating a Pokedex? knowing all existing Pokemon? Then it's time to explore this magnificent API that provides all the necessary information to create a huge pokedex and make Ash jealous.

API 👉🏻 https://pokeapi.co/

Let's go to the references to test your skills, Pokedex is cool to do for mobile, to have the same experience as our colleague Ash.

Mobile:

• https://dribbble.com/shots/6540871-Pokedex-App

• https://dribbble.com/shots/16833947-Mobile-Pokedex-App-Design-Exploration

• https://dribbble.com/shots/4862523-Pokedex-iOS-app-Squirtle

Web:

• https://dribbble.com/shots/15128634-Pokemon-Pokedex-Website-Redesign-Concept

• https://www.pokemon.com/us/pokedex/

MovieDB

This one is classic! Who doesn't want to build a Netflix? But only with information, this API is COMPLETE, with tons of information about movies and series, with this API you will be able to search for movies in theaters, check the cast, ratings and WOW, it gives you a small authentication and user session control! I'm sure this is one of the best APIs to practice.

API 👉🏻 https://developers.themoviedb.org/3/

The reference I don't even need to say, is Netflix! but with the special touch of no movie, only information 🫠

Two amazing references to practice your dev skills:

• https://dribbble.com/shots/15558638-Movie-Dashboard-Design-Dark-Mode

• https://dribbble.com/shots/17230478-MOVEA-Movie-dashboard-design

Marvel

Ultron released the code of the multiverse and now we can navigate through all the characters of this enormous API. For the nerds out there, I'm sure it will be an adventure to develop a guide with all the Marvel characters.

The Marvel API is commented on in each return field, making it even easier to understand.

API 👉🏻 https://developer.marvel.com/

Outsmart Tony Stark and build a powerful application with this reference 👊🏻

• https://dribbble.com/shots/17032308-Comic-Books-Library

That's it, folks, with these 3 examples you will already acquire a lot of knowledge on how to work with an API and for sure it will help you in future projects!

But don't limit yourself to just these APIs listed above, there are several public APIs for you to access and create your applications and tune up your portfolio.

Hope I helped! See you next time 👋🏻