Forem: Trung Hieu Nguyen

How does NodeJS handle thousands of requests while it’s single-thread?

Trung Hieu Nguyen — Sun, 14 Aug 2022 15:14:00 +0000

Hi, it’s been a long time since the last time I wrote a post on my blog page. Those days were tough to me because I have a lot of things to worry about. But now I’m back with a new post. Note that this is just my opinion/point of view about this (of course I got some knowledge from friends, blogs)

1. Why single thread but not multi thread

Many languages use multi thread models like PHP, Java, C# but JS still chooses to stay with single thread event loop model because it has some advantages

First thing to get into account here is that Javascript was born with the purpose of building a scripting language for front-end development. Its aim is to build a fast, easy to use language to fit into front-end development. Dealing with single thread is much more easier than multi threads where you have to face with problems of design architecture (since threads share same resources), deadlocks, race conditions and much more things that can make you crazy.
Secondly, with multithreading model, for each request, you’ll create a new thread to handle it. The problem here is that the number of threads you can create depends on server’s RAM capacity. In single-thread, the thing that you have to worry about is CPU, not RAM. But with the speed of modern CPU which can handle millions of operations per second, for application which does not require many CPU intensive requests, using single thread model is best choice (We’ll talk about the reason why we need to care about the CPU intensive requests in the next sections where we discuss about how NodeJS handle a request), by not spawning new thread for each request, it will reduce the memory and resource usage

2. Understanding the flow of handling a request in NodeJS

a. Some basic definitions

Before diving into the main part of this section, let’s go through some basic definitions so that when we come to the next part, it would be easier to understand the secret behind NodeJS.

NodeJS built on top of V8 Engine and LibUV. In this article, the thing we need to care about is LivUB. It’s written in C, contains the Event Loop, Thread Pool (which provide more threads that can be used by NodeJS) and Event Queue. The number of threads in threads pool in LibUV by default is 4. So basically, NodeJS will have 1 main thread and 4 sub threads (I don’t know if they can be called as “sub-thread”, but just keep in mind that NodeJS does not go around with only 1 thread)

Now, let’s come to one of the biggest argument of all time among Javascript developers (also some other developer community). It is: Is NodeJS single-threaded?

One of the proof given by the people believe that NodeJS is not single-thread is that: NodeJS built on top of V8 Engine and LibUV, LibUV has the thread pool which contains some other threads that NodeJS can use, so basically, NodeJS has more than 1 thread, therefore, it’s not true that NodeJS is single-threaded. In this argument, I’m on the side of people think that NodeJS is Single-Threaded. Let me explain why: Yeah, that’s true that NodeJS can take advantage of using threads provided by LibUV. But keep in mind that, the key word “single-threaded” is about the ability of executing the same piece of code more than 1 at the same time. For example, if you have a loop that log in the console a word, i.e: “Hello world”. In NodeJS, within an instance of NodeJS application, there can’t be 2 loops run at the same time simultaneously, you can test it yourself.

CPU bound, IO bound task

I/O = input/output task such that: reading some rows from database and returns it, counts number of lines in a file,…
CPU: Tasks which your CPU has to do the job. i.e: calculate a operation: 1+1 = 2, image processing.
So just remember that I/O task is something that CPU can’t handle itself but must have the I/O subsystem to do it
CPU task must be executed in the main thread of NodeJS, while I/O task can be executed in threads within the thread pool provided by LibUV. That’s the reason why NodeJS is not suitable for application with CPU intensive tasks. We’ll go into detail in the next few minutes.

Blocking I/O vs Non Blocking I/O:

Blocking I/O: Requests involve with I/O operation will block the thread/process until it’s done
Non blocking I/O: Request involve with I/O operation will be pushed into the queue and executed later (if it’s not ready, if it’s ready, returns it right away)

b. How NodeJS handle a request

Okay, it’s enough for the definition stuffs. Now go to the your main concern when you go here.

Here’s how NodeJS handle a request.

When a request comes, it is firstly pushed into a queue called event queue.

Event loop will pick up the first element in event queue and start to process it. There are 2 cases here:

If the request is only involved with not blocking IO task / CPU task (do some calculation, no need to call other IO subsystem) (in the above example, it’s the job of calculating the bill of the order), event loop will push it to the call stack and NodeJS will execute it right away in the main thread, here comes the first bottleneck of NodeJS, when NodeJS is handling that task in the main thread, event loop won’t pick up any new task from event queue, all other tasks must waits for the processing task to be done which leads to the fact that the response time will be extremely slow. That’s the reason why NodeJS is not suitable for CPU intensive task, CPU task can only be done in the main thread, when the main thread is busy, it can’ t do anything else.
If it’s a non blocking IO task, the event will push that job to another queue, tasks in that queue are waiting task to be done by threads in threads pool provided by LibUV. Please note that by default, LibUV only provides 4 additional threads to process blocking I/O tasks. That means when these 4 threads are busy handling tasks. Every 5th task comes in must wait (in the queue I mentioned above). But keep in mind that the number of threads provided by LibUV can be changed via settings (but as far as I know, 4 is enough to handle most of requests), if the number of requests are too big, that time we should consider about vertical scaling (create another instance of application) instead of increasing the number of LibUV’s threads.
- Some might wonders, how could it be possible that NodeJS application can handle thousands of requests while it only have 5 threads in total. The point here is “callback”. When a thread (A) in thread pool pick up a task, it will interact with other I/O subsystems like a database (for example). And note that, the database also provides some threads (B) itself, so thread A just comes in and say “hey, database, I need to get some data in the database, but I won’t wait for you to find and give it back to me, instead I will leave a “callback” here, call it when you’re done with your job, I will go back to pool and pick up another job”. Once the database’s done its job, it will call the callback function and send the response back to the callback queue, and when the call stack is empty, event loop will pick from callback queue to the call stack to continue to handle the request.

Below is a simple diagram visualize how NodeJS handle a request

Source: https://dattp.github.io/2020-04-10-event-loop-in-nodejs/

Follow-up questions:

You guys might have some doubts about this (like I did), so I will list some questions here, hope that they will (partially) match your concerns.

❓ Okay, I understand what you said in (1). But I don’t get it at all, so what will happens after that, it will send back the response to the call stack and then what?

→ Yeah, right, keep in mind that your function that handles the request is not usually simple, it might involves with many call to database, or any other blocking I/O task. Like this

const handleRequest = async (input: InputDTO) => {
    const dataA = await dbConnection.get(A);
  const dataB = await dbConnection.get(B);
// process the output which combining dataA and dataB or some other stuff associated with those datas.
}

So NodeJS will breaks your handleRequests function into some smaller task. For example, get dataA is 1 task, get dataB is another task, and finally processing the output is another task. each task is separately pushed into the event queue and handle individually, (of course it must be in the order that you write in your code).

A small note in this example is that, whenever you call the “await” keyword in an async function, what comes after the await keyword will be automatically wrapped in a Promise. and NodeJS will stop execute your function at the point it meets await keyword, it will continue to process that function when it receives the response from that Promise.

When dataA is returned from the callback, NodeJS will continue to get the dataB from the database, event loop will pick it (if it’s on top of the call stack) and process it just like how it processed to get the dataA. And it will continue that loop of process until it reaches the end of handle request function.

❓ What is the priority in case call stack is empty and we have task from event queue and callback queue are ready at the same time.

In my opinion, I think it will take the task from callback queue first, since that task from callback queue has something to do with a previous request, it’s better to send response to previous request instead of processing the new one if both of them are ready. But it’s just my assumption. Maybe NodeJS does not follow that rule.

❓ I think that callback queue contains some smaller type of queue, doesn’t it

You’re right, when I say callback queue, I just want to talk about the high level of processing task routine in NodeJS. Indeed, we have more than 1 callback queue. They are: 1) NextTick queue 2) Micro task queue 3) Timers Queue 4) IO callback queue (Requests, File ops, db ops) 5) IO Poll queue 6) Check Phase queue or SetImmediate queue 7) close handlers queue. Event loop will continuously check these callback queues in the order and if any task in that queue is done, it will move that back to call stack to continue process (of course in case the call stack is empty).

3. Summary

Okay, above is all the thing that I want to share with you guys today. Note that all of them are based on my understanding and some articles I read on the internet, they might not be true 100% (or maybe completely wrong. If there is something wrong with this article. Please feel free to drop a comment and I will go to discuss more with you guys. Thank you and bye bye

References:

https://viblo.asia/p/ben-trong-nodejs-2-thu-vien-libuv-RQqKLRMOl7z

https://dattp.github.io/2020-04-10-event-loop-in-nodejs/

https://www.digitalocean.com/community/tutorials/node-js-architecture-single-threaded-event-loop

Some thoughts about Virtual DOM

Trung Hieu Nguyen — Sat, 26 Mar 2022 16:22:11 +0000

I’ve been working with React for a while, and one of the most confusing things about React is “Virtual DOM”. Its concept and how React uses it are simple. But the reason behind the scene why React uses Virtual DOM and the arguments about the performance of Virtual DOM compared to Real DOM are endless. After some research about it, I have my opinions about these things. So today, I want to talk a little bit about it.

1. What’s Virtual DOM?

The VirtualDOM is just an in-memory copy of the actual DOM tree. It represents the element of the DOM tree in an object-like form.

2. Why does React use Virtual DOM?

To answer this question, we need to understand how React works. Each time one component is re-rendered, React rebuilds the entire UI of your web/app. If React used the Real DOM, each time we have a change in our app, React will update the entire DOM tree, not just the part which has been changed. Updating the DOM is fast, but it’s still an expensive process because, after that, the browser needs to do the layout, painting, and composition operations to render our app, all of them are expensive processes and they are really really slow. So if we update the entire DOM tree, the browser will need to re-render our app from the beginning and that process is extremely slow. Imagine when you develop and have to wait for a long time to see the changes we made, it’s nightmare. So to fit in with how React works, the React team decided to use Virtual DOM, Virtual DOM is just an object that represents the DOM tree, rebuilding Virtual DOM is much cheaper and it doesn't trigger the browser rendering process.

In the conclusion, React uses Virtual DOM because of how it works (rebuilding the entire UI on each change of component), not because Virtual DOM is faster than Real DOM.

3. Why is React faster than Angular. Is that because of Virtual DOM?

Let’s go back to what React does when we make a change on the component of our app.

First, React will build a brand new Virtual DOM then compares it with the old Virtual DOM from the previous render, React finds the update by comparing these 2 Virtual DOM objects and finally reflects the changes in the Real DOM.

So eventually, React still need to update Real DOM to reflect the changes on the browser. Instead of updating on Real DOM directly, React adds checking the differences between 2 Virtual DOM objects, does it make the complexity of updating more complex? In the previous section, we know that React uses Virtual DOM because of the way it works. So why React is still faster than Angular while it adds an additional step before updating the Real DOM? There are 2 main reasons:

The first reason is that finding the changes on Real DOM is slower than finding changes on Virtual DOM. Virtual DOM is an object so traveling and comparison are faster.
The second reason is React can batch the updates (we all know that the components normally re-renders when their states changed, and React doesn’t update the state immediately but it groups all the updating request and only executes the update when necessary) so the app is only re-rendered when necessary, by doing that, React can reduce the number of re-rendering as much as possible.

4. Summary

React uses Virtual DOM because it helps React solve the performance problem with re-rendering the entire UI
React is faster than Angular mostly by the way it groups the update of our application. Of course, using Virtual DOM is also a factor that makes React faster than Angular.

But I want to notice you guys again that: the goal of React is not performance but the way we can build the UI easier as well as reduce the bugs on development.

If you have any questions please drop a comment. Or if I made any mistake, feel free to point it out, thank you!

Some mistakes with async and promise in Javascript

Trung Hieu Nguyen — Fri, 18 Mar 2022 13:13:39 +0000

Hi, today I'm gonna talk about Javascript Promises, Async-await, and some mistakes which I made when working with them.

I will come back to update this post whenever I find out any new mistake.

1. Never fully trust your console.*(..)

Hmm, it might be not really related to our topic today, but actually, it is. This might rarely happen (actually for the past 2 years, I've just encountered it several times).

console.* is not standardized and there is no specification or rules which show how console.* methods works. So we can't know for sure the behavior of console.*. Their results can be changed from time to time, the result of the example I'm going to show might not be the same as the result you see on your browser at the time you read this blog. We never know.

Let's see a very simple example:

const a = {
    value: 10,
};
console.log(`a`, a);
a.value = 20;

What you guys might expect to see is:

{value: 10}

and it actually is, but I want to point out that, SOMETIME, it will log like this:

{value: 20}

It's hard for me to reproduce a case to show you guys but it really can happen, maybe when you run a very large project and rapidly make changes to code then the console.* will have some strange behavior that you never know.

If you run into the above scenario, the best option you can do is that use a debugger instead or stick with JSON.stringify to take a "snapshot" of your variable (I'm talking about object type)

2. Resolve/Reject is not equivalent to "return"

One mistake that I made during development is that I assumed resolve/reject is the "return" keyword of a Promise. Technically, it's true, but one thing to notice is that even if you called resolve/reject, your Promise will not stop at that point but will exec till the end of the Promise.

Let's see this example:

const a = new Promise((resolve) => {
    resolve(1);
    console.log("still go here");
});

a.then((res) => {
    console.log(res);
});

// Result
still go here
1

And

const a = new Promise((resolve, reject) => {
    reject(2);
    console.log("still go here");
});

a.then((res) => {
    console.log(res);
}).catch((err) => {
    console.log(err);
});
// Result
still go here
2

Even though you called resolve/reject before the console.log, it's still printed out on screen which means Promise still go to that line and execute code after resolve/reject has been called.

It's not the same as functions which if you call "return', the function will stop at that point (I'm not talking about conditional return).

I want to share this with you guys because in the past, because of assuming resolve/reject as "return", I made a bug that took me 2 days to fix!

3. The first will be chosen

In your promise, you can call resolve/reject multiple times, but only the first one will be accepted and be the output of your Promise. Of course, I'm talking about the normal flow, if it's conditional flow, it will be a different story.

const a = new Promise((resolve) => {
    resolve(1);
    resolve(2);
});

a.then(console.log);

// Output: 
1

const a = new Promise((resolve, reject) => {
    reject(2);
    reject(1);
});

a.catch(console.log);
**// Output
2**

The same thing happens with the parameters you pass to resolve/reject, you can call resolve/reject with multiple parameters, but only the first one will be chosen to be the value of resolve/reject, all subsequent parameters beyond the first one will be silent ignore.

const a = new Promise((resolve, reject) => {
    resolve(1, 2, 3);
});

a.then(console.log);

// Ouput
1

If you want to return more than 1 value, you have no choice but put them into object or array.

const a = new Promise((resolve, reject) => {
    resolve([1, 2, 3]);
});

a.then(console.log);

// Ouput
[1,2,3]

4. Unnecessary await return.

Okay, let me make it more clear.

Consider below example

const promise = () =>
    new Promise((resolve, reject) => {
        setTimeout(() => {
            resolve("done");
        }, 1500);
    });

const makeRequest = async () => {
    return await promise();
};

const test = async () => {
    const result = await makeRequest();
    console.log(result);
};

test();

// result
// after 1.5s, print out "done"

Notice about the return await promise() . I think not only me but many other beginners sometimes write such code like that. It's not wrong, but to me, it's kind of useless. Since make request might make some asynchronous request to the server and return another promise. if we don't have to process anything with the data but return it immediately, we don't have to await the response before return

This code also works the same as the above:

const promise = () =>
    new Promise((resolve, reject) => {
        setTimeout(() => {
            resolve("done");
        }, 1500);
    });

const makeRequest = async () => {
    return promise();
};

const test = async () => {
    const result = await makeRequest();
    console.log(result);
};

test();

// Result
// after 1.5s, print out "done"

Okay, that's it for today. See you guys next time. Bye bye

Some thoughts about React Context

Trung Hieu Nguyen — Fri, 18 Mar 2022 13:09:41 +0000

Today I’m going to talk about Context API, one of the most important concepts, API that you need to know when working with React. Okay, let’s get started.

Note that on this blog, I. won’t go into details like “how to set up React Context, how to use React Context” but I just want to share my thoughts about it.

1. Why do we need Context API?

If you’re working with React, you’ll probably have to deal with a very very annoying thing called props drilling. It’s the case when you need to pass some props through some components which don’t really need that props just because its children (or just one) need those props.

Basically, Context API will give you a chance to create some “global stores”, where you can store some props, data which can be shared with multiple components.

2. Compare with Redux

Wait, is that what Redux (or any other state management libraries) is trying to solve, if it’s built-in React, why do we need those state management libraries?

Of course, if it’s only about dealing with props drilling, those libraries wouldn’t have become popular as they are now.

I only have experience with Redux (and a little play-around time with Recoil) so I’ll focus on comparing Redux and Context API only.

a. Features

With context, there’s nothing more than just a store where you put some global variables in order to be used in multiple components.
But with Redux, it’s a different story, not only provide a global store but it also serves us other features such as tracking your states through your app (by using Redux extension - it’s very powerful and a must-have extension if you work with Redux, with it, your debugging process will be a lot easier)
- Another thing worth talking about is that it helps us split logic and actions out of your components (actually with the born of custom hooks, in my opinion, it’s not a “plus-point” anymore)
- Use middlewares like state logging
- Moreover, it solves one of the disadvantages of Context API called “Context Hell” (we’ll go deeper into it in the next few minutes).
- And a lot more stuff, since the “ecosystem” (I don’t know if I can call it like that) is very large with a lot of libraries like redux-thunk, redux-saga, redux-persist,... They change the way of dealing with a lot of problems in React app (but of course, to me, it will make your app bigger and bigger)...

b. Setup

Because Context API only has one (main) usage, the setup process is very simple, you just need 3 things: Initialize the context, a context provider, and context consumer. Because Context API is a built-in feature in React, you don’t need to install any other libs.
With redux, one of the biggest reasons I hate when working with Redux is about the setup process, there’s a lot of stuff to be done and each time you have some new action, you have to add to a lot of files (of course you can put all of them in one file and it’s fine, but in the real-life projects and in order to make your app scalable, it’s recommended to split to multi files like app.actions.js, app.reducer.js, app.selector.js,...) But it’s not the end, if you want to interact with other servers and want to fully use Redux, you have to choose to install redux-thunk or redux-saga which makes the logic and the number of lines of code you have to write larger and larger). It’s a nightmare to me.

3. Disadvantage

a. Multi stores

As I mentioned above in Feature section, one of the disadvantages of Context API is that a Consumer can only consume one provider, that said, if you want to use data of different “store” (context), you have to wrap them together like this:

<ThemeContext.Provider value={theme}>
   <UserContext.Provider value={signedInUser}>
          <Layout />
       </UserContext.Provider>
</ThemeContext.Provider>

But what’s not good here?

Firstly, it’s harder to debug because you have many “global stores”. It’s in contrast to one of the principles in Redux “single source of truth”. The more stores you have, the more careful you have to be.
Secondly, Another thing worth mentioning here is about performance, by wrapping contexts like onion in the example above if any value of outer context changes which might trigger a re-render of all components it’s wrapping. Of course, most of the time, that’s the behavior we expect our app to be but there are some cases re-rendering inner components which don’t care about changed values doesn’t really make sense and can be a performance issue.

b. Feature limitation

As I mentioned before in the feature section, React Context is nothing but a global store, so React Context is usually used in small projects. When it comes to larger projects, Redux (or other state management libs) is the way to go because of its rich features. Of course, we can still use React Context along with other state management libs. But in my opinion, why do we need another “global store” while we already set up one. Right?

4. Final thought

Despite feature limitations, I’m still in love with React Context. Especially when there are some other libs that can store the data as the global state (i.e Apollo Graphql, React-query,...) as well as the born of custom hooks.

That’s it for today. See you next time. Bye-bye

Build a facebook story creator using ReactJS and FabricJS

Trung Hieu Nguyen — Sun, 10 Oct 2021 14:07:39 +0000

Back then those days, I'm on my way to building a very large project myself, it's a social media app. And there is a very interesting feature that I want my app to have, yeah, it's the story feature where people can share things that will be automatically hidden after 24 hours. I decided to build a simpler version of it and today I want to share with you guys the experience of building a Facebook story creator.

Live demo: https://trunghieu99tt.github.io/Facebook-story-mini/

1. Scope

First, let's define our scope. The story feature in the Facebook app on mobile is a very huge feature which a lot of smaller features in it, but the story feature on the Facebook website is not.

On the website, we only have 2 options. 1 is text story and 2 is image story with texts. In this blog, I will go for the story feature on the Facebook website which is much more simpler I think.

Okay, let's go a little bit further and see what we have to do

Text story: a paragraph in the middle and a changeable background
Image story: one image per story and we also can add text blocks

It seems to be simple, right? at least with the text story feature. Okay, let's move to the next part

2. Tools, libraries

I use ReactJS to develop this feature, with text story it's enough, but with image story, we need to find a library that helps us deal with add/remove text blocks, change direction, size,... and I came up with Fabric Fabric provides interactive object model on top of the canvas element, that's exactly what we want to do here. I think you'd better go to the Fabric website and read about it before continue reading.

3. Start coding

You can use whatever boilerplate you want, to me, I will stick with Create React App. I will assume that you guys have basic knowledge of React and know how to create and run a React App. Another small note is that in this project, I will use Typescript but I think people don't know about Typescript, it's not a big deal because it's just a small project.

In this project, we will need to add 2 more packages: fabric and fabricjs-react (actually we don't need this package, but to make things easier, it's okay to use).

Run this command:

yarn add fabric fabricjs-react
#or
npm install fabric fabricjs-react

Okay, now we're good to go.

Before going to the next step, let's define our folder structure, we know that we have 2 main types of components: 1 is story form to create text or image story, 2 is viewer components where we show the data from the server after creating and save text/image story. I'll create a folder structure like this:

constants folder will hold all the constant values we use in this app.

3.1. Text story

About text story, it's the easier one, we just have a div and text in the center of that div. we can also change the background of that div.

In StoryForm, create a folder called Text, in that folder, create 3 files: index.ts (our entry file), textStory.module.css, and TextStory.tsx.

In TextStory.tsx:

import { ChangeEvent, useState } from "react";

import { BACKGROUND_LIST } from "../../../constants";

import classes from "./textStory.module.css";

const TextStory = () => {
    const [text, setText] = useState("");
    const [background, setBackground] = useState("#000");

    const onChangeText = (e: ChangeEvent<HTMLTextAreaElement>) => {
        const text = e.target.value;
        setText(text);
    };

    const saveToServer = () => {
        const data = {
            type: "text",
            background,
            text,
        };
        localStorage.setItem("data", JSON.stringify(data));
    };

    return (
        <div className={classes.root}>
            <aside className={classes.aside}>
                <textarea
                    className={classes.textarea}
                    onChange={onChangeText}
                    rows={7}
                />
                <p>Change color</p>
                <ul className={classes.backgroundList}>
                    {BACKGROUND_LIST.map((color) => {
                        return (
                            <li
                                onClick={() => setBackground(color)}
                                style={{
                                    background: color,
                                    cursor: "pointer",
                                    outline: `${
                                        color === background
                                            ? "2px solid blue"
                                            : ""
                                    } `,
                                }}
                            ></li>
                        );
                    })}
                </ul>
                <button onClick={saveToServer}>Save</button>
            </aside>
            <div
                className={classes.main}
                style={{
                    background: background,
                }}
            >
                <p className={classes.text}>{text}</p>
            </div>
        </div>
    );
};

export default TextStory;

Above is the full code for that component. We have a state to store our text and a state to store the background color. About the saveToServer function, you can ignore it, we will go back to it later on this blog. With background color list, in this project, we will hardcode it (but you can change it to a color picker or whatever you want to make it better)

Create an index.ts file in the constants folder and put this to it:

export const BACKGROUND_LIST = [
    'linear-gradient(138deg, rgba(168,74,217,1) 0%, rgba(202,88,186,1) 55%, rgba(229,83,128,1) 100%)',
    'linear-gradient(138deg, rgba(55,31,68,1) 0%, rgba(115,88,202,1) 55%, rgba(97,0,30,1) 100%)',
    'linear-gradient(138deg, rgba(31,68,64,1) 0%, rgba(202,88,155,1) 55%, rgba(90,97,0,1) 100%)',
    'linear-gradient(138deg, rgba(14,33,240,1) 0%, rgba(88,202,197,1) 55%, rgba(11,97,38,1) 100%)',
    'radial-gradient(circle, rgba(238,174,202,1) 0%, rgba(148,187,233,1) 100%)',
    'linear-gradient(138deg, rgba(14,33,240,1) 0%, rgba(88,202,197,1) 55%, rgba(11,97,38,1) 100%)',
    'radial-gradient(circle, rgba(198,76,129,1) 12%, rgba(218,177,209,1) 27%, rgba(148,187,233,1) 100%',
    'linear-gradient(180deg, rgba(62,66,105,1) 0%, rgba(233,225,107,1) 55%, rgba(11,97,38,1) 100%)',
    'radial-gradient(circle, rgba(117,67,81,1) 2%, rgba(107,233,164,1) 37%, rgba(97,11,11,1) 100%)',
    '#2d88ff',
    '#ececec',
    '#6344ed',
    '#8bd9ff',
    'linear-gradient(315deg, rgba(255,184,0,1) 0%, rgba(237,68,77,0.7175245098039216) 61%, rgba(232,68,237,1) 78%)',
];

About the style file, it's a little bit long so I won't post it here. But I'll drop a link at the end of this blog so you can check it out later.

In the index.ts file, we just write a single line.

export { default } from './TextStory';

This is our final result of text story form:

The default color of text will be white (I set it using CSS, but you make a list of available colors and let the user choose the color if you want).

3.2. Image story

Okay, this is the main part of this blog and it will be a tougher one.

Because we have to do these things:

Display image (in this project we will read it from the URL, but you can change it to upload from your machine)
Add texts: We can add multi-text blocks and with each block, we can change the text in there, drag, rotate, resize it.

It's time for the fabric to come into play.

In story form, create a folder called Image. Then in that folder, create a file called ImageStory.tsx.

let's write some code in there

import React, { ChangeEvent, useState } from "react";
import { FabricJSCanvas, useFabricJSEditor } from "fabricjs-react";

import classes from "./imageStory.module.css";

const ImageStory = () => {
    const { editor, onReady } = useFabricJSEditor()
    return (
        <div className={classes.root}>
            <div className={classes.main}>
                <FabricJSCanvas className={classes.canvas} onReady={onReady} />
            </div>
        </div>
    );
};

export default ImageStory;

Now add a form to hold our image URL and a submit function for that form.

import React, { ChangeEvent, useState } from "react";
import { fabric } from "fabric";
import { FabricJSCanvas, useFabricJSEditor } from "fabricjs-react";

import classes from "./imageStory.module.css";

const ImageStory = () => {
    const [image, setImage] = useState<string | null>(null);
    const [isSubmitted, setIsSubmitted] = useState<boolean>(false);

    const { editor, onReady } = useFabricJSEditor();

    const submitImage = () => {
        if (image && image.startsWith("http")) {
            fabric.Image.fromURL(image, function (img) {
                const canvasWidth = editor?.canvas.getWidth();
                const canvasHeight = editor?.canvas.getHeight();
                editor?.canvas.setWidth(500);
                editor?.canvas.setHeight(500);
                editor?.canvas.add(img);
                const obj = editor?.canvas.getObjects();
                obj?.forEach((o) => {
                    if (o.type === "image") {
                        o.scaleToHeight(canvasWidth || 100);
                        o.scaleToHeight(canvasHeight || 100);
                    }
                });

                editor?.canvas.centerObject(img);
                setIsSubmitted(true);
            });
        }
    };

        const onChange = (e: ChangeEvent<HTMLInputElement>) => {
            const { value } = e.target;
            setImage(value);
        };

    return (
        <div className={classes.root}>
            <div className={classes.main}>
                {!isSubmitted && (
                    <div className={classes.imageForm}>
                        <input type="text" onChange={onChange} />
                        <button onClick={submitImage}>Submit</button>
                    </div>
                )}
                <FabricJSCanvas className={classes.canvas} onReady={onReady} />
            </div>
        </div>
    );
};

export default ImageStory;

We have a state that stores our image URL

Because I want to show form only when we didn't submit the image, so I added isSubmitted state to deal with that. We only show image form if isSubbmitted = false.

Okay, let's take a look at the onSubmit function:

const submitImage = () => {
        if (image && image.startsWith("http")) {
            fabric.Image.fromURL(image, function (img) {
                                // Note that img now will be an fabric object

                                // get width and height of canvas container
                const canvasWidth = editor?.canvas.getWidth();
                const canvasHeight = editor?.canvas.getHeight();

                                // add image object 
                editor?.canvas.add(img);

                                // get all fabric objects in editor
                const obj = editor?.canvas.getObjects();

                                // This will not optimal way, but currently
                                // we only have one image, so It should be fine
                obj?.forEach((o) => {
                    if (o.type === "image") {
                                                // resize image to fit with editor width and height
                        o.scaleToHeight(canvasWidth || 100);
                        o.scaleToHeight(canvasHeight || 100);
                    }
                });

                editor?.canvas.centerObject(img);
                setIsSubmitted(true);
            });
        }
    };

fabric supports read image from URL, it will return a fabric object then. in callback function, we add that object to current editor. One thing to keep in mind that the image now will keep its initial size so it might not fit with our editor area, we need to resize it to fit with editor area. My current solution is to get all objects in editor then resize it if it's image. Since we only have one image per story, this solution will work fine.

Now if you run your app and paste a valid image URL to form and hit submit, we will see it shows the image in the editor area. and you can interact with that image (drag, resize, rotate...). Good job. 😄

We finished our first goal, now let's move to the second one.

the fabric also supports text block, so adding text to our editor is easy.

Change our ImageStory component:

import React, { ChangeEvent, useState } from "react";
import { fabric } from "fabric";
import { FabricJSCanvas, useFabricJSEditor } from "fabricjs-react";

import classes from "./imageStory.module.css";

const ImageStory = () => {
    const [image, setImage] = useState<string | null>(null);
    const [isSubmitted, setIsSubmitted] = useState<boolean>(false);

    const { editor, onReady } = useFabricJSEditor();

    const onAddText = () => {
        try {
            editor?.canvas.add(
                new fabric.Textbox("Type something...", {
                    fill: "red",
                    fontSize: 20,
                    fontFamily: "Arial",
                    fontWeight: "bold",
                    textAlign: "center",
                    name: "my-text",
                })
            );
            editor?.canvas.renderAll();
        } catch (error) {
            console.log(error);
        }
    };

    const onChange = (e: ChangeEvent<HTMLInputElement>) => {
        const { value } = e.target;
        setImage(value);
    };

    const submitImage = () => {
        if (image && image.startsWith("http")) {
            fabric.Image.fromURL(image, function (img) {
                const canvasWidth = editor?.canvas.getWidth();
                const canvasHeight = editor?.canvas.getHeight();
                editor?.canvas.add(img);
                const obj = editor?.canvas.getObjects();
                obj?.forEach((o) => {
                    if (o.type === "image") {
                        o.scaleToHeight(canvasWidth || 100);
                        o.scaleToHeight(canvasHeight || 100);
                    }
                });

                editor?.canvas.centerObject(img);
                setIsSubmitted(true);
            });
        }
    };

    return (
        <div className={classes.root}>
            {isSubmitted && (
                <aside className={classes.aside}>
                    <button onClick={onAddText}>Add Text</button>
                    <button onClick={saveToServer}>Save</button>
                </aside>
            )}

            <div className={classes.main}>
                {!isSubmitted && (
                    <div className={classes.imageForm}>
                        <input type="text" onChange={onChange} />
                        <button onClick={submitImage}>Submit</button>
                    </div>
                )}
                <FabricJSCanvas className={classes.canvas} onReady={onReady} />
            </div>
        </div>
    );
};

export default ImageStory;

Let's take a look at onAddText function. We create a new fabric Textbox object by calling new fabric.Textbox().

 editor?.canvas.add(
                new fabric.Textbox("Type something...", {
                    fill: "red",
                    fontSize: 20,
                    fontFamily: "Arial",
                    fontWeight: "bold",
                    textAlign: "center",
                    name: "my-text",
                })
            );
 editor?.canvas.renderAll();

Let me explain the params we passed: The first argument will be the initial text and the second one will be an object that contains configuration for text in that textbox. In the above code, I'll create a text that contains a red bold text which has font-size is 20 and font-family is Arial, the text will be aligned center in the textbox. After creating the textbox, we will add it to our editor using editor.canvas.add(..), and finally, we re-render the editor to get the latest state.
This is our final result:

Okay, up until now, we're done with adding the image and text. What's about deleting? With fabric, it's like a piece of cake, fabric has a removal method where we just need to pass objects we want to remove and fabric will handle it for us. But how do we get the object to pass to remove method?

Remember how we delete things, we will select it first, right? So fabric has a method called "getActiveObjects", by using that method, we can get all selected objects. Hah, problem solved, we just need to get all active objects, then loop through them and call remove method.

Like this:

const deleteSelected = () => {
        editor?.canvas.getActiveObjects().forEach((object) => {
            editor?.canvas.remove(object);
        });
    };

Okay, so we're done with all the basic features. Now let's move to the next step.

3.3. Save and show data

We can add, move things so far, but our app is not just interaction things, we need to store it in our database and show data from the database right? So how could we do that with fabricjs?

In this small project, I will use local storage as our database to make it easier. About the form of data, I think text is the best way. We just need to create an object then use JSON.stringify with that object.

With the text story feature, we don't have many things to do. The information we need to store is text content and background color.

const saveToServer = () => {
        const data = {
            background,
            text,
        };
        localStorage.setItem("data", JSON.stringify(data));
    };

Add this function to Text Story Form component and add a button which onClick event is saveToServer and we're done with it.

Now move to image story, again, thanks to fabric, we has a method called toJSON() which converts objects data in our editor to JSON, now we just need to call JSON.stringify with converted objects data and save it to local storage

const saveToServer = () => {
        const objects = editor?.canvas.toJSON();
        if (objects) {
            localStorage.setItem("data", JSON.stringify(objects));
        }
    };

To show data, first, we get data from local storage and JSON.parse that data

const showResultFromServer = () => {
        const json = localStorage.getItem("data");
        if (json) {
            const objects = JSON.parse(json);
              // store it to component state. 
        }
    };

With text story, after parsing data, we now have text content and background color. Using it to show data is easy, right? Our only concern is how to show image story because it was controlled by fabric. Luckily, fabric has a method called "loadFromJSON", we only need to pass JSON data we got from toJSON method and fabric will handle the rest for us.

For example, we can do this:

editor.canvas.loadFromJSON(
                data,
                () = {}
            );

loadFromJSON has 2 params, the first is JSON data and the second is a callback function, the callback function will be called when JSON is parsed and corresponding objects (in this case, they're image objects and texts objects) are initialized. We don't need the callback function so let it be an empty function for now.

Okay, so we're all done with it.

The full source code can be found here:

https://github.com/trunghieu99tt/Facebook-story-mini

In this tutorial, I'm learning and writing this blog at the same time, so there might be better ways to use fabricjs or better ways of handling things I mentioned in this blog. :D If you have any suggestions, please feel free to drop a comment and I'll check it out. Thank you very much.

Simple way to wait for an executing function to finish before executing another function in Javascript

Trung Hieu Nguyen — Sat, 25 Sep 2021 12:45:05 +0000

Actually, I'm not really sure about the title of this blog because currently, I can't come up with any better title to describe what I want to share with you guys today. I don't know if it's called something else, if anyone knows, please point it out, I very much appreciate it.

Okay, so first let's start with our use case:

We have 2 functions, let's call them A and B. We call them at the same time, but we want B to wait for A to finish first.

I have a really simple function like this:

(async () => {
    const sub = {
        name: "sub",
        subscribed: false,
    };

    // 1.subscribe function
    const subscribe = () => {
        setTimeout(() => {
            sub.subscribed = true;
        }, [9.5 * 1000]); // execute after 9.5 seconds
    };

    // 2. a function only happen after subscribed
    const afterSubscribed = () => {
        if (sub.subscribed) {
            console.log("subscribed");
        } else {
            console.log("Not subscribed");
        }
    };

    subscribe();
    afterSubscribed();
})();

And the output of this function would be:

// immediately
Not subscribed
// Continue to run 9.5 seconds then stop

The result I want is that this function somehow prints out "Subscribed".

Let's try to solve it.

The first try we can do is that we can create an interval in the afterSubscribed function like this, note that we will add a timer to see when we get right log:

// 2. a function only happen after subscribed
    const afterSubscribed = async () => {
        const start = Date.now();
        const interval = setInterval(() => {
            if (sub.subscribed) {
                console.log("subscribed");
                const end = Date.now();
                const duration = Math.floor(end - start);
                console.log(`on: ${duration}`);
                clearInterval(interval);
            } else {
                console.log("Not subscribed");
            }
        }, [1000]);
    };

Now we will retrieve the result we want:

// This is the log of this function
Not subscribed
Not subscribed
Not subscribed
Not subscribed
Not subscribed
Not subscribed
Not subscribed
Not subscribed
Not subscribed
subscribed
on: 10011

Yeah, it prints out the result we want, it's quite good. The issue of this approach is that we only check for the state of the sub every 1 second. So in case, our subscribe function finishes after 9.1, 9.2... seconds, we still have to wait until the 10th second. But it's still acceptable as long as we don't need afterSubscribed to continue to execute right after subscribe finished.

To resolve the issue of the #1 try, we can change our functions like this:

(async () => {
    const sub = {
        name: "sub",
        subscribed: false,
        doneSubscribed: false,
        processSubscribe: false,
    };

    // 1.subscribe function
    const subscribe = () => {
        sub.processSubscribe = new Promise(
            (resolve) => (sub.doneSubscribed = resolve)
        );

        setTimeout(() => {
            sub.subscribed = true;
            sub.doneSubscribed();
        }, [9.5 * 1000]); // execute after 9.5 seconds
    };

    // 2. a function only happen after subscribed
    const afterSubscribed = async () => {
        const start = Date.now();
        await sub.processSubscribe;
        if (sub.subscribed) {
            console.log("subscribed");
        } else {
            console.log("Not subscribed");
        }
        const end = Date.now();
        const duration = Math.floor(end - start);
        console.log(`on: ${duration}`);
    };
    subscribe();
    afterSubscribed();
})();

And this is what we get:

// Wait for 9.5 second then..
subscribed
on: 9507

Okay, so no more "Not subscribed" and right after subscribe finished its works

Let me explain how it works.

We add 2 more attributes to sub :

doneSubscribed: false,
processSubscribe: false,

And in subscribe function, we assign sub.processSubscribe to a promise where resolve function is assigned to sub.doneSubscribe. In setTimeout, we call sub.doneSubscribe function (since we assigned it to the resolve function of sub.processSubscribe promise, it's a function now). The trick here is that we assign the resolve function of sub.processSubscribe to sub.doneSubscribe, we all know that the promise resolves when its resolve/reject function is called. By awaiting for sub.processSubscribe we also wait for setTimeout to finish as well as subscribe function.

Of course, there might be some other way to solve this problem, but I think this one is one of the shortest and best ways to solve it.

So in general, this problem can be described as "wait for an executing function to finish before executing another function".

If you guys have any other ways to solve it. Feel free to share with me. Or If I did any mistake, please point it out, I really appreciate it. Thank for reading

Awesome CSS Tricks (Part 1)

Trung Hieu Nguyen — Mon, 16 Aug 2021 11:52:42 +0000

1. Background for text

Tired of traditional colors like red, yellow, green...? and want to try something new? This trick is for you, besides colors, you can use images, videos, and linear-gradient, radial-gradient,... to "paint" your text.

An example:

Look so cool, right? It would be more stunning if you have some effect with the background image of the text (like move around,...).

The snippet for the above code is:

background: url(...);
-webkit-background-clip: text;
color: transparent;

But the downside of this trick's that it's not well supported by all browsers:

https://caniuse.com/?search=-webkit-background-clip

So be careful when using it if you want your website to work perfectly in all browsers.

2. Round border

I think most of you guys have ever made a button/link that has round borders like this:

A very simple way to retrieve this is using border-radius then set that attribute to a number in pixel. But a thing that newbies usually struggle with is what number is enough? Remember back these days when I was a newbie, I always opened the devtools and then set a random number, then change it back and forth until I got the exact result I wanted. If you spend time considering border-radius attribute you will figure out that after a specific value in pixels if you keep increasing the value of border-radius then the roundness of the border will remain the same. So this is when our idea comes into play. 🤤 You just need to set border-radius to a very large value then we will archive the round borders no matter the width, height, padding, margin of our button. My favorite value is 999px. It's very easy to remember and in my opinion, it's a nice number.

3. Dividing columns for text content

Instead of normal content, with CSS you can show text content in columns (like when you read the magazine or newspaper for saving area purposes) like this:

You can use this code snippet:

-webkit-column-count: 3 // the number of columns
column-count: 3
-webkit-column-gap: 40px; // the gap between column
column-gap: 40px;

Change the column-count and column-gap to whatever number you want to fit with your requirement.

4. Parallax scrolling

Parallax scrolling is a stunning effect that nowadays, more and more designers and front-end developers like to put in their websites, portfolios.

According to w3school, Parallax scrolling is a website trend where the background content (i.e. an image) is moved at a different speed than the foreground content while scrolling. Click on the links below to see the difference between a website with and without parallax scrolling.

This is an example of this technique: Link

In the beginning, I thought we had to use Javascript to retrieve that effect. Surprisingly, with CSS, it's just like a piece of cake. Create a section with a background image, in CSS of that section, add this line:

background-attachment: fixed

For example:

.parallax{
    background-image: url(...); // your background image
    ... // some attribute to make your background looks good
    background-attachment: fixed; // this is where the magic happens
}

W3School have a tryIt example, if you're interested in it, let's give it a shot: Link

5. Object-fit

Sometimes, you have to show a list of items, a list of images,... but the width and height of the images might not be the same which breaks your layout. At that time, if changing the size of images is not available, I think the best solution is to set a specific height or width (maybe both of them) to the images? But since when you set sizes of the image that way, you might break the image ratio aspect which leads to some problems i.e the image will be stretched or squished (in an uncontrolled way). Like this:

This is the original example (400x300)

If we set the size of that picture to 200x300, it would be like this:

Awful, we have a completely new picture, so it's time for object-fit comes into play. The CSS object-fit is used to specify how an img or video should be resized or fit its container.

Here is where the object-fit property comes in. The object-fit property can take one of the following values:

fill - This is the default. The image is resized to fill the given dimension. If necessary, the image will be stretched or squished to fit
contain - The image keeps its aspect ratio, but is resized to fit within the given dimension
cover - The image keeps its aspect ratio and fills the given dimension. The image will be clipped to fit
none - The image is not resized
scale-down - the image is scaled down to the smallest version of none or contain

In most cases, I usually use cover and contain.

If we use object-fit: cover; we will have a picture like this:

The image will remain its aspect ratio but will be clipped. It's not really good in some case, but it's a trade off.

You can read for more examples and detail here: Link

6. Limit text length to x lines

To limit the length of text, we can use Javascript, but at that time, we can only control the number of characters not the number of lines. What if I want text should be shown in 4 lines than if the text is longer than that, we will show something else (maybe ... or something). Yeah, if we want, we also can do that using Javascript, but it would be more complex than just limit the number of characters.

We can retrieve that using CSS only, sounds great, right?

The snippet code for doing that job is:

display: -webkit-box;
-webkit-box-orient: vertical;
-webkit-line-clamp: $line;
overflow: hidden;
text-overflow: ellipsis;

Replace $line with the number of lines you want the text to be displayed.

Check out the example: Link

text-overflow property defines how the remaining text will be displayed, if text length exceeds the number of lines we want in the above code snippet, it will be cut off and displayed as "...". For more details, you can go here

The box-orient property sets whether an element lays out its contents horizontally or vertically. For more details, you can go here

⚠️ The bad news is that the attributes I mentioned in this trick aren't supported by all versions of all browsers. So once again, be careful when you use it. Even though the downside, I think it's still a powerful trick you might want to take a look at and, maybe you will want to use it sometimes.

You don't know useEffect

Trung Hieu Nguyen — Sun, 15 Aug 2021 07:29:35 +0000

useEffect is one of the most common React Hooks which every ReactJS developer should know. But using useEffect the right way is not easy as you might think. Today, I will go through some notes which I think many newbies go wrong when using useEffect and solution to get rid of those issues.

1. Quick overview

I think we should start with some basics about useEffect. We all know that useEffect is a React Hook which is used to handle side effects function (for who doesn't know what's a side effect function - it's just a function that interacts with the outside world. I.e: Log something to screen, create a file, save data to database, change DOM....).

If you know about React lifecycle, useEffect will do the job of componentDidMount, componentDidUpdate and componentWillUnmount. Yes, 3 methods in 1 hook. Therefore, the use cases of useEffect will be use cases of those above methods:

Calling API
Do something when state/props change
Cleaning stuffs on unmount / before next render
And much more than that....

Syntax: The syntax of useEffect is very simple:

useEffect(someFunc, [deps_array]);

The first argument will be a side effect function.

The second argument will be an array of dependencies which determine whether that useEffect would run or not.

2. Dive deep into useEffect.

a. Forms of useEffect

First, we'll talk about 3 forms of useEffect. I don't know if it's right to call "form", but at least it makes sense to me (hope it will make sense to you guys too!)

The form of useEffect is determined by the second argument: array of dependencies.

Firstly, the deps_arrray is optional, you aren't forced to pass the second argument. In case if only pass the first argument, we have the first form of useEffect

useEffect(func);

In this case, the function passed to useEffect will run on every render of the component. It's used when you need to do something on every render of the component. But you should be careful when use this form of useEffect if you don't want to mess up with infinity render or memory leak. You should avoid using this form of useEffect as much as possible

For example

const App = () => {
    useEffect(() => {
        console.log("This effect is called on every render");
    });

    // return..
}

Everytime your component is re-rendered, you will see that log.

If you pass an empty array as second argument of useEffect, you will have the second form of it.

useEffect(func, []);

It's opposite with the first form, the function passed to useEffect will run only one time (after the first render).

For example:

const App = () => {
    useEffect(() => {
        console.log("Effect has been called");
    }, []);

    // return...
}

Except for the first render, you won't see the log "Effect has been called" anymore.

The third form of useEffect is when you pass array with some variable in the array of dependencies

useEffect(func, [variableA, varibleB,...]);

This time, func will be run every time there's a change with any element in array of dependencies.

For example:

const App = () => {
    const [counter, setCounter] = useState(0);
    useEffect(() => {
        // This will run every time counter changed
        console.log('counter: ', counter);
    }, [counter]);

    // return
}

⚠️ There's a thing you need to notice: Even if you pass an array of dependencies or not, and you just intend to run the function in the third form of useEffect when one of the dependencies changes, the useEffect will always run on the first time component is mounted.

For example:

const App = () => {
  const [a, setA] = useState(0);
  const [b, setB] = useState(1);

  useEffect(() => {
    console.log("run only once");
  }, []);

  useEffect(() => {
    console.log("Change a");
  }, [a]);

  useEffect(() => {
    console.log("Change b");
  }, [b]);

  return (
       ...
  );
}

On the first render, you'll see three logs:

run only once
change a
change b

So even though a and b aren't changed at all, those useEffect associated with those variables still run on the first render. This will be a big deal if you have multi useEffect that triggers some side effect that are heavy (i.e: API call). For example, you have to render a list with pagination and search query

import { useEffect, useState } from "react";
import "./styles.css";

const App = () => {
  const [query, setQuery] = useState(0);
  const [page, setPage] = useState(1);

  useEffect(() => {
    console.log("call api first time");
  }, []);

  useEffect(() => {
    console.log("Call api when query changes");
  }, [query]);

  useEffect(() => {
    console.log("Call api when page changes");
  }, [page]);

  return (
   ...
  );
};

export default App;

For the first time your component is mounted, you will see three logs:

call api first time
call api when query changes
call api when page changes

Let's imagine if you listen to changes of many other fields and on each of useEffect for those fields, you trigger API calls (or any other side effect function), so for the first time your app is rendered, a lot of unnecessary API calls will be triggered which can affect the performance of your app and cause some bugs that you might not expect (in case you don't really need to fire all API call or side effects function of all useEffect)

To get rid of that issue, there're some ways, but I will introduce to you guys the common way - which's my favorite one to deal with that problem. You can create a variable to check if component is mounted or not.

const App = () => {
  const [query, setQuery] = useState(0);
  const [page, setPage] = useState(1);
  const isMounted = useRef(false);

  useEffect(() => {
    if (isMounted.current) {
      console.log("Call api when query changes");
    }
  }, [query]);

  useEffect(() => {
    if (isMounted.current) {
      console.log("Call api when page changes");
    }
  }, [page]);

  useEffect(() => {
    console.log("call api first time");
    isMounted.current = true;
  }, []);

  return (
    ...
  );
};

This is the result on first mount

call api first time

Also notice about the order of useEffect, I didn't put them in that order for nothing. In order to make that solution works, you must put the variable that holds value for the first render/mount (or whatever you want to call it) in last useEffect. React goes through useEffects in order

b. Dependencies

In the previous section, I mentioned the list of dependencies passed to useEffect, by doing that, you can "listen" to any change of each element in the dependency list.

The problem here is that : most of the time you will work with object and function, if you pass variable with object/function type to dependency list, sometimes your program might work not as you expected. Let's consider the below example:

import { memo, useState } from "react";
const List = memo((list) => {
  useEffect(() => {
    console.log("list changed");
  }, [list]);

  return <ul>{list?.length > 0 && list.map((e) => <li>{e}</li>)}</ul>;
});

const App = () => {
  const [a, setA] = useState(0);

  const someFunc = () => console.log("This is a random function");

  useEffect(() => {
    console.log("Use effect of someFunc's called");
  }, [someFunc]);

  const fakeList = () => ["number 1", "number 2"];

  return (
    <div className="App">
      <h1>Variable a: {a} </h1>
      <button onClick={() => setA((v) => v + 1)}>Increase a</button>
      <button onClick={someFunc}>call someFunc()</button>
      <List list={fakeList} />
    </div>
  );
};

No, try click button "Increase a",

We will get this (not in the first render)

list changed
Use effect of someFunc's called

Each time we click "Increase a" the useEffect listen to changes of someFunc and list are triggered, even though we didn't touch or change someFunc, fakeList (Notice that I wrapped List component with memo to prevent it from re-rendering if props - list changed). It's because when comparing objects/functions, React will compare their references. So when click the button Increate a → App component will be re-rendered (due to change of state) → someFunc and fakeList are renewed , so on each render, someFunc and fakeList will have new references, therefore, React will mark that someFunc and fakeList are changed and run useEffect associated with them. You should care about this thing to prevent unnecessary re-render and unnecessary useEffect trigger

As I mentioned before, React will compare objects/functions by their references. There are 2 common cases that you should count when working with dependencies of type object/function:

Case 1: Objects/functions are the same, but the references are different (the case in our example).
Case 2: Objects have different values, but their references are the same (this case happens when you partially update the object but don't trigger a re-new action).

Each of the above 2 cases will affect our useEffect which leads to unexpected behavior.

There're many solutions to avoid those cases, I'll introduce to you guys the approach that I usually use.

For the first case: Memoization.

Yes, to do that, we will come up with 2 new hooks (maybe you guys heard about it before: useCallback and useMemo).

For quick ref, you guys can see the differences of these hooks here: The difference between useCallback and useMemo or read for detail on the official site: useCallback and useMemo

Change our code a little bit

import { memo, useCallback, useEffect, useMemo, useState } from "react";

const List = memo((list) => {
  useEffect(() => {
    console.log("list changed");
  }, [list]);

  return <ul>{list?.length > 0 && list.map((e) => <li>{e}</li>)}</ul>;
});

const App = () => {
  const [a, setA] = useState(0);

  const someFunc = useCallback(
    () => console.log("This is a random function"),
    []
  );

  useEffect(() => {
    console.log("Use effect of someFunc's called");
  }, [someFunc]);

  const fakeList = useMemo(() => ["number 1", "number 2"], []);

  return (
    <div className="App">
      <h1>Variable a: {a} </h1>
      <button onClick={() => setA((v) => v + 1)}>Increase a</button>
      <button onClick={someFunc}>call someFunc()</button>
      <List list={fakeList} />
    </div>
  );
};

export default App;

I wrapped someFunc with useCallback (actually, if you use someFunc as one of the dependencies of useEffect and don't wrap it by useCallback, in case your IDE/text editor is integrated with ESLint, you would get a warning like this: The 'someFunc' function makes the dependencies of useEffect Hook (at line 19) change on every render. To fix this, wrap the definition of 'someFunc' in its useCallback() Hook) and also wrap our fakeList with useMemo. Because of studying purpose, we will let the list of dependencies of useCallback and useMemo are blank for now, but in real-life projects, when using these hooks, you should be careful about their dependency list.

Now if we run our program and click the Increase a button. We won't see the log come from useEffect of someFunc and list anymore (except for the first render).

⚠️ Every line in your code comes with a cost!. useCallback and useMemo will consume the memory of your program (since it needs to store the value somewhere) so you should be careful when using these hooks, only use them when it's really necessary.

For the second case, I will not give example because the way to get rid of that problem is to simply listen to the attribute not the object.

But the best practice with the dependency list of useEffect is that you should always deal with primitive type as long as you can to avoid unexpected result.

Source code for this section can be found here: https://codesandbox.io/s/hopeful-cherry-md0db?file=/src/App.js:356-388

c. Clean up function

In overview section, I said that useEffect can do the job of componenWillUnmount life cycle. it's return function in useEffect

useEffect(() => {
    // do something
    return () => {
        // do cleanup stu
    }
}, []);

The return function will execute "clean up" stuff before next time function in that useEffect is called.

Therefore, in the above example, it's equivalent to execute some code in componentWillUnmount since the form of useEffect in the above example is #2 which only runs once after the first render of the component.

I know it's kind of abstract. So we will go through some examples, hope you guys will get it after these examples.

const List = () => {
  useEffect(() => {
    console.log("first render list");

    return () => console.log("unmount list");
  }, []);

  return <h1>This is a list</h1>;
};

const App = () => {
  const [isListVisible, setIsListVisible] = useState(true);

  useEffect(() => {
    return () => console.log("clean up on change isListVisible");
  }, [isListVisible]);

  return (
    <div className="App">
      <button onClick={() => setIsListVisible((v) => !v)}>Toggle List</button>
      {isListVisible && <List />}
    </div>
  );
};

Each time you click "Toggle List" you'll see two logs: One from useEffect of form #2 from List and one is from useEffect of #3 listens for change of isListVisible.

So why clean up is necessary. So let's consider below example:

Let's change above example a little bit:

const List = () => {
  useEffect(() => {
    setInterval(() => console.log("interval from list"), 1000);
    return () => console.log("unmount list");
  }, []);

  return <h1>This is a list</h1>;
};

const App = () => {
  const [isListVisible, setIsListVisible] = useState(true);

  useEffect(() => {
    return () => console.log("clean up on change isListVisible");
  }, [isListVisible]);

  return (
    <div className="App">
      <button onClick={() => setIsListVisible((v) => !v)}>Toggle List</button>
      {isListVisible && <List />}
    </div>
  );
};

I added a setInterval to List, it will log every 1 sec. But the point here is: even though List is unmounted, the interval will still running.

So even though the component is unmounted, some side effects we put to that component's still running. In our example, it's just an interval, but in real life, what if it's a bunch of API calls, a bunch of other side effect stuff, imagine that they still run even if their components are unmounted, it's could be a black hole that affects our app performance.

In our example, to resolve the issue, we could simply add clearInterval to our clean up function:

const List = () => {
  useEffect(() => {
    const listInterval = setInterval(
      () => console.log("interval from list"),
      1000
    );
    return () => {
      console.log("unmount list");
      clearInterval(listInterval);
    };
  }, []);

  return <h1>This is a list</h1>;
};

I know that if you're newbie, sometimes you'll not notice about clean up stuffs, but they're really necessary and you should spend time considering about them.

Code for this section can be found here: https://codesandbox.io/s/flamboyant-andras-xo86e?file=/src/App.js:69-357

3.Summary

Okay, so I've gone through some deep information about useEffect. Besides the notes that I mentioned, there're much more cases you should notice when using useEffect to make your app work the best way it could. So keep learning and if you have any questions or corrections, please drop a comment and I will check it out. Thank you. Bye bye. 😈