DEV Community: Kenneth Lum

The paradigm of React

Kenneth Lum — Mon, 18 Sep 2023 09:02:49 +0000

I think it may be important to know one of the top principles of React, because without it, the code may turn out a bit non-idiomatic React, and it may need refactoring to bring it back to the React Way. This one major principle is: use declarative ways to write your components.

Sometimes, it may need to be imperative, but those are supposed to change a state, so that the state can change into something you declared earlier.

For example, you may say that, when you have an array, you show the list as:

<ul>
  {arr.map((e, i) => <li key={e.id}>{e.title}</li>)}
</ul>

So you are declaring: with the arr, what should the output be.

Now again, if you have filtering of the items, if the user can enter a keyword, then the code becomes:

const filteredArray = arr.filter(e => e.title.includes(keyword));

return (
  <ul>
    {filteredArray.map((e, i) => <li key={e.id}>{e.title}</li>)}
  </ul>
);

You may not need to use useMemo for the filteredArray. However, imagine if you have a case where, if the user types in keyword, and needs to click on the "Filter" button to do the filtering, then you don't want to do the costly filtering for every user keypress. So if your code causes the main component to re-render every time when there is a keypress, then you may want to use the useMemo to do the filtering, depending on what keywordConfirmed is, when the user clicks on the "Filter" button. (There is a way to let a sub-component not cause the main component to re-render on each user keypress, so the filtering won't be done every time, but it is beyond the scope of this post).

There is also this idea that: if the slowest computer and smartphone can handle your task of filtering every time in a super fast way, then, you may not need to use useMemo. Optimize it only when it is necessary. Note that this is different from the LeetCode way, when n can be 5 million or 5 billion. Here, n could be 50 in your use case, or 500, so optimizing in such cases can be viewed as premature optimization. (Donald Knuth: "The real problem is that programmers have spent far too much time worrying about efficiency in the wrong places and at the wrong times; premature optimization is the root of all evil (or at least most of it) in programming.")

Now what we have so far are all declarative: when arr is such, and keyword is such, then the output will be such: meaning it is like a function: what goes in, what goes out, and it is functional, or declarative. If you are familiar with the programming language Lisp, that's how it works.

One note about this: when you consider the states, in general, try to have as few of them as possible. Also, look at what needs to be the state, and what are values that can be derived from the state. For example, in the example above, arr is the state, and filteredArray can be derived from it. So don't make filteredArray a state, but make it a local, derived value inside this functional component.

We also use these states and write the rest of the component using them. For example, we may have

  {arr === null && <div>Loading...</div>}

and it is again, declarative.

Now there are times we need to do imperative operations, such as to fetch the value when the component is first rendered. (it could be this component or a higher up component).

To do that, it'd be

useEffect(() => {
  fetch(url)
    .then(res => res.json())
    .then(data => setArr(data))
    .catch(console.error);
}, []);

So here, we fetch data from the server, and set it to the arr state. And from here, everything becomes declarative again.

The same with event handlers. You'd usually write the handler to change one or more states, so that the declarative code will handle the rest.

The rule is: usually it is either the user doing something, or the network sends back some data, or setTimeout, setInterval triggers some change, and therefore changes the state. From that point on, the declarative mechanism handles the rest.

In other words, it is events: user interactions, timer events, network events, that change the states, and then from there, everything is handled in a declarative way. That is: you don't have to do anything.

This concept is important, because if you use React, and you write it without thinking mostly declarative, and use both declarative and imperative ways, then your React code will not idiomatic and it may be against the overall paradigm that React is using.

Example:
https://codesandbox.io/s/funny-hugle-94j2cj?file=/src/App.js

Reference: https://react.dev/learn/managing-state
Note that there are seven sections for this topic.

Creating a new React app in a few seconds

Kenneth Lum — Thu, 07 Sep 2023 15:32:02 +0000

There is a method to create a new React app quickly, much faster than create-react-app or by Next.js

The method is by Vite. Assuming you are using a recent version of npm (7 or above), the following steps will create a new React app in seconds:

npm create vite@latest myapp -- --template react
code .
cd myapp
npm i
npm run dev -- --open

If you don't use Visual Studio Code or don't have the command line to start it already set up, then you can remove the line code . or replace it with a command line that will start your editor if you want.

You also can create an alias and put it in your .bashrc:

alias vitecreate='npm create vite@latest myapp -- --template react && code . && cd myapp && npm i && npm run dev -- --open'

and then you can:

mkdir MyNewReactProject
cd MyNewReactProject
vitecreate

and start doing development work right away. You can use codesandbox.com too, but if you want a local server running, together with your favorite IDE and being able to do git commits, you can use this Vite method.

If you want to play with the SWC (Speedy Web Compiler) template, you can use react-swc instead of react after the --template flag. For more information about different templates, see https://vitejs.dev/guide

async / await concepts

Kenneth Lum — Tue, 23 May 2023 13:36:12 +0000

To a traditional programmer, async / await can be tricky. Here are some key concepts:

There cannot be any await inside of a function if this function is not declared as an async function.
You can think of it this way: this async function returns to you immediately, and what does it return? It returns a promise that will be resolved or rejected later.
Inside of the async function, the code will run, until it hits an await. Don't think of this await as "waiting", but more like a notifyMeOfTheValueWhenReady or aValueThatWillBeReady. You can even read it as stopHereAndGiveMeTheValueWhenReady.
To be more precise, the promise isn't returned to the caller until the first await is reached. Typically you will have at least one await inside an async function, or else you wouldn't use an async function in the first place. You can see in the examples below to verify the case: inside the async function, the code runs until the first await, then the promise is returned to the caller. This usually does not matter, but it may be good to know.
This await is like a "set it and forget it". It is similar to setting an observer, if you are familiar with the observer pattern. Or you can think of it as setting a callback function. The await is followed by a promise, like await p; You can think of it as a .then(v => { ... }), so the value v is what await p will become in the future.
When the execution of code reaches this await, after the "set it and forget it", nothing is done. The code does not go onto the next line until this "future value", or promise is resolved or rejected.
We can use price = await getStockPrice(); or displayStockPrice(await getStockPrice());. In the first case, that await reads like notifyMeOfTheValueWhenReady. In the second case, the await reads like aValueThatWillBeReady. For both cases, reading it as stopHereAndGiveMeTheValueWhenReady goes well. In the second case, the await cause the async function code to stop there, until a value is obtained, and then displayStockPrice() is called.

Example 1

In the following, try and figure out the order of the lines are displayed.

Note that $(document).ready(function() { ... }); is just jQuery's way of running the code when the DOM is ready in the jsfiddle environment.

https://jsfiddle.net/kwtomj59/

  console.log("Running the program");

  async function foo() {
    console.log("I am running at Point A of the async function");
    return 123;
  }

  foo().then((v) => {
    console.log("finally I get the value from the async function", v);
  });

  console.log("This is after calling the async function");

Example 2

What about the following? Note that when the big loop is running, the UI of that input box is not reacting.

https://jsfiddle.net/odr4sz58/

  console.log("Running the program");

  async function foo() {
    let a = 0;

    for (let i = 0; i < 1000000000; i++) {
      a += Math.random() > 0.5 ? 1 : -1;
    }
    console.log("I am running at Point A of the async function");

    return a;
  }

  foo().then((v) => {
    console.log("finally I get the value from the async function, and it is ", v);
  });

  console.log("This is after calling the async function");

Example 3

Since the console.log is not executed until later, we can use alert to see the immediate message:

https://jsfiddle.net/odr4sz58/1/

It is just the above program with the console.log replaced with alert.

Example 4

https://jsfiddle.net/hpj4tvy3/

  alert("Running the program");

  async function foo() {
    let a = 0;

    const foo = await (new Promise(resolve => setTimeout(() => resolve(123), 0)));

    for (let i = 0; i < 1000000000; i++) {
      a += Math.random() > 0.5 ? 1 : -1;
    }
    alert("I am running at Point A of the async function");

    return [a, foo];
  }

  foo().then((v) => {
    alert(`finally I get the value from the async function, and it is ${JSON.stringify(v)}`);
  });

  alert("This is after calling the async function");

Example 5

Finally, here is an example of the fn(await ...) pattern. What is the order of the messages being displayed?

https://jsfiddle.net/yb0th3cw/

  alert("Running the program");

  async function foo() {
    let a = 0;

    alert(await (new Promise(resolve => setTimeout(() => resolve(123), 0))));

    for (let i = 0; i < 1000000000; i++) {
      a += Math.random() > 0.5 ? 1 : -1;
    }
    alert("I am running at Point A of the async function");

    return a;
  }

  foo().then((v) => {
    alert(`finally I get the value from the async function, and it is ${JSON.stringify(v)}`);
  });

  alert("This is after calling the async function");

Editing and using a command quite some time ago on Bash

Kenneth Lum — Thu, 23 Feb 2023 11:41:21 +0000

In Bash or Zsh, we can in general use the up arrow to get back the command line some 20 or 25 lines ago, edit the command, press Enter and execute it.

However, pressing the up arrow key 20 or 25 times can be tedious, and we need to look closely when we get that exact line, which can be tiring on the eyes.

One quicker way is this:

Use h or history to look at the list of past commands. When needed, use history -300 to look at 300 lines of history
Use !127 to execute the command line 127 as shown above "as is" with no editing, but to edit it, then:
Use !127:p to just print that command line without executing it, and put it into history
Then, use the up arrow once and you can get that command, and edit it as you wish (using left, right arrow, CTRL-A to go to the beginning, or CTRL-R to search backward, etc, depending on your settings)

Understanding what a Blob is

Kenneth Lum — Sat, 08 May 2021 22:44:03 +0000

There is a little bit of mystery of what a Blob is.

A Blob is a "B L OB" or "Binary Large Object". It is as if it is a file.

It is defined in the File API of the JS specs. It has

a series of immutable bytes
a size
an MIME type, such as 'image/jpeg', 'text/plain', 'text/csv', 'application/pdf', or 'application/json' (some more examples)

For example, if from the database or from protobuf, we can get an array of bytes, which is the byte dump of an image file, we can compose it back to a "file" which is like my-awesome-file.jpg.

In JavaScript Definitive Guide, 7th ed, p. 522, it is said that the file may actually be saved on user's local hard drive, and the JavaScript can still access the Blob.

We can look at an example:

https://jsfiddle.net/KennethLum/9L51my3b/

const arr = [
  // ...
];

const arrUint8 = new Uint8Array(arr);

const blob = new Blob([arrUint8], {
  type: 'image/jpeg',
});

const url = URL.createObjectURL(blob);

document.querySelector('#my-image').src = url;

arr is a regular JavaScript array, and its content is not listed above but is in the JSFiddle example.

It is first converted to a "typed array", which is an array similar to the low level memory block when a C program is written. (think malloc).

It is then converted to a "blob", and it is as if it is a file. Then how can we access this file? One way is to get a URL for it, and that's what the line

url = URL.createObjectURL(blob);

is for. The URL may appear like

blob:https://fiddle.jshell.net/6631b3ce-ba72-41f1-bfb0-e498862a573d

and it is like, this URL is the address of a file.

Then in the above example, we just set the image element's src to point to that URL, and we can see the image.

Letting the user automatically download the file

There is one more trick to automatically let the user download this file, which is the use the <a> tag. We set the href and the download attribute of the tag, and then use JavaScript to click on it:

const imgElement = document.querySelector('#my-image');
const anchorElement = document.querySelector("#the-link");
imgElement.src = url;
anchorElement.href = url;
anchorElement.download = "my-awesome-image.jpg";

imgElement.addEventListener("load", () => {
  anchorElement.click();
});

Example: https://jsfiddle.net/KennethLum/t89xguf6/

And the file can be automatically downloaded for the user. This can be useful, when some image is made (as a Blob or from Canvas), and then it is provided to the user as a download. For example, we could make a shipping label, or a discount coupon with the user's name on it, or it can be a .csv file with a stock's historical data in it, and then provide to the user as an image or as a PDF or .csv file.

In fact, the <a> element does not even need to be present on the page. It can be dynamically created:

Example: https://jsfiddle.net/KennethLum/gx6zu9ap/

imgElement.addEventListener('load', () => {
  const anchorElement = document.createElement('a');
  anchorElement.href = url;
  anchorElement.download = 'my-awesome-image.jpg';

  anchorElement.click();
});

Automatically re-render the page when we save the file in the code editor

Kenneth Lum — Mon, 05 Apr 2021 14:08:03 +0000

TLDR: use live-server and we don't have to keep refreshing the webpage but the page would refresh itself when we change our code in the webpage.

I used to use Ruby or Python to spin up a local web server, for example, when rendering a webpage as local HTML file cannot support data fetch, but requires a web server.

And then, we always have to save the file, and go to the web browser, and refresh the page.

But there is a server that can automatically re-renders the webpage. The advantage is that we can stay in the code editor, and save the file, and the browser next to the code editor will re-render the page. If we have a big monitor, we can move the browser at the top left corner of the screen, and the editor at the center of the screen, and see the full page of re-rendered result on the browser.

The server is called live-server. We first have to install node, and then we can do

npm i -g live-server

and then we can just cd to our folder, and invoke

live-server

I usually like to not have any index.html file, so that http://127.0.0.1:8080 gives me a list of files I can choose in the current directory.

The way this is done is that live-server add some JavaScript at the end of our file, so that when we save any file or update any file in the folder, then the page would refresh itself.

To tell what the web server is, right inside of a webpage

Kenneth Lum — Fri, 02 Apr 2021 09:10:32 +0000

Sometimes if we start a local webserver, or if we use other online pages, we would like to find out what webserver it is, and it is possible to do it right inside of the webpage. We can fetch something, and look at the response header by res.headers.get("Server"):

fetch("foo.txt").then((res) => {
  document.querySelector(
    "#server-note"
  ).innerHTML = `The server is ${JSON.stringify(res.headers.get("Server"))}`;
});

Demo: https://jsfiddle.net/KennethKinLum/80td3s4f/

The server for

Webserver	in the header
Node.js's `live-server`	nothing `(null)`
Ruby's `ruby -run -e httpd . -p 8080`	`WEBrick/1.4.2 (Ruby/2.6.3/2019-04-16)`
Python 2's `python -m SimpleHTTPServer 8080`	`SimpleHTTP/0.6 Python/2.7.16`
Python 3's `python3 -m http.server 8080`	`SimpleHTTP/0.6 Python/3.8.2`
JSFiddle	`nginx`
Codesandbox	`cloudflare`
macOS Big Sur's webserver	`Apache/2.4.46 (Unix)`

It is possible to tell the user-agent as well, using navigator.userAgent.

Building a simple slideshow component in React using Hooks

Kenneth Lum — Wed, 31 Mar 2021 07:53:45 +0000

I was trying to build a simple slideshow component using React Hooks. Initially, I was thinking of how to use calculations to position a picture properly on the page or inside of the component region.

It turns out it is a lot simpler, if we use containers or containers that cover the whole viewport to contain a picture, and move the container accordingly.

The reason is, if we calculate where to place the image, and what size to use, it can be a lot of calculations. If we use a container and set the max-width and max-height, and we center the picture in the container, such as by using the container as a flex box, then we don't have to do all the calculations and it is automatically handled by CSS.

In the example here, I am trying to use the viewport, and to better use it using CSS, note that we can use the unit of vw and vh, which is viewport width and viewport height.

I "dock" the containers at the left of the screen (hidden):

  function theLeftShift(i) {
    if (currentImageIndex === i) return 0;
    else if (i > currentImageIndex) return "100vw";
    else return "-100vw";
  }

and

      <ul>
        {Array.from({ length: nImages }, (e, i) => i + 1).map((e, i) => (
          <li style={{ left: theLeftShift(i) }}>
            <img src={`./pic${e}.jpg`} />
          </li>
        ))}
      </ul>

We don't really need to move the containers further and further left, and can just dock it to the immediate left. That way, we don't need to create a region that is wider than it is needed.

The demo: https://codesandbox.io/s/simple-slideshow-z2089?file=/src/App.js

The full page demo: https://z2089.csb.app/

Using React in JSFiddle, Coderpad, or just an HTML page

Kenneth Lum — Fri, 26 Mar 2021 10:13:02 +0000

Sometimes we may need to use React in Coderpad when we interview candidates or get interviewed.

There is actually a way to do that easily in Coderpad:

Just change the language to HTML
Choose the Packages next to that, and choose React

Then we can write code such as

<script
  src="https://unpkg.com/react@17/umd/react.development.js"
  crossorigin
></script>
<script
  src="https://unpkg.com/react-dom@17/umd/react-dom.development.js"
  crossorigin
></script>

<script src="https://unpkg.com/babel-standalone@6/babel.min.js"></script>

<div id="root"></div>

<script type="text/babel">
  function App() {
    const [count, setCount] = React.useState(0);

    function handleClick() {
      setCount((c) => c + 1);
    }

    return (
      <div>
        count: {count} <button onClick={handleClick}>Click</button>
      </div>
    );
  }

  ReactDOM.render(<App />, document.getElementById("root"));
</script>

Demo in Coderpad (if it can allow public access): https://app.coderpad.io/G7E9DQQT

Demo in JSFiddle: https://jsfiddle.net/d9m68rft/

Or demo in Codesandbox: https://codesandbox.io/s/brave-leaf-6dmbu?file=/index.html

One issue is that as of right now, Coderpad or JSFiddle cannot auto format our code with the JSX, and sometimes the code is a bit messy due to indentation. Codesandbox can reformat everything on File -> Save, but some companies disallow moving the code to else where and pasting in back to Coderpad, to discourage cheating, probably.

Coderpad current uses React 16.13.1 and it is good enough for React Hooks. To be able to use React Hooks, we must use React 16.8 or above.
The scripts in the above code is suggested by the React documentation itself: https://reactjs.org/docs/add-react-to-a-website.html

We can also see the different versions of React files that can be included, in: https://cdnjs.com/libraries/react

JSFiddle has a React choice, but it requires a little bit of configuartion. The best website to use React is https://codesandbox.io I found.

Codersandbox is a bit tricky to share with another person. One time I had to constantly save the file, and ask the other person to constantly refresh her page. I often had to ask, "do you see the updates?"

It can in fact be quite easy:

On the left side of the window, click on the bottom icon, which is "Share"

And then, copy that "live" link and share with the other person:

It is somewhat a pity that some companies do not allow using Codesandbox because they have more control using Coderpad with replaying the interview. But I suppose one way is to be so good in it, that the interviewer is totally impressed and can vow that you said and typed everything yourself, and vow to say that you are one of the best candidates he has met so far and recommend a strong hire.

Caching a function instead of something "expensive" using useCallback() in React

Kenneth Lum — Sat, 20 Mar 2021 03:01:23 +0000

We have seen that we can cache something that is "expensive", using useMemo(), in https://dev.to/kennethlum/seeing-usememo-speed-up-our-webpage-3h91

Now a function can be quite simple, but why would we want to cache it to? It can be when we pass into a child component or use it else where, and we want to keep it the same value, so that there is no unnecessary re-rendering.

We can see, in

export default function App() {
  const myFooter = useMemo(() => <Footer n={30000} />, []);
  const [count, setCount] = useState(0);

  function handleClick() {
    setCount(count + 1);
  }

The function handleClick is a new function every time App() is called.

We can use useMemo() to cache it too, just like how we cache <Footer />

The code:

Wrong behavior demo: https://codesandbox.io/s/relaxed-newton-5sqmy?file=/src/App.js

  const handleClick = useMemo(
    () => () => {
      setCount(count + 1);
    },
    []
  );

It can only increment the count to 1, but not more. Why is that? The reason is that we cached the function, which is a closure with the scope chain with count equal to 0. Every time, the function sees count as 0, and therefore the setCount(count + 1) is always setCount(0 + 1).

To fix that behavior, we can use:

  const handleClick = useMemo(
    () => () => {
      setCount(c => c + 1);
    },
    []
  );

Demo: https://codesandbox.io/s/nameless-fast-d0fv1?file=/src/App.js

Note that we don't need to use useMemo(), but can use useCallback(). It is essentially the same thing:

  const handleClick = useCallback(() => {
    setCount((c) => c + 1);
  }, []);

Demo: https://codesandbox.io/s/busy-archimedes-vse8f?file=/src/App.js

Note that we don't need to give a function that return a value, but can provide that function we want to cache directly.

Likewise, if we have

  const handleClick = useCallback(() => {
    setCount(count + 1);
  }, []);

It is not going to work: https://codesandbox.io/s/distracted-cloud-o93gw?file=/src/App.js

To see that handleClick is the same value (a reference to the same function), we can use a useRef() to double check it. We can skip this part if useRef() is not familiar to you yet:

  const checkingIt = useRef(null);

  const handleClick = useCallback(() => {
    setCount((c) => c + 1);
  }, []);

  console.log(checkingIt.current === handleClick);
  checkingIt.current = handleClick;

Demo: https://codesandbox.io/s/unruffled-sunset-81vwx?file=/src/App.js

We can see that the first time, the console.log() would print out false, but once we set it, the next time App() is called, it has the same value as the previous time, and would print out true.

If we change it to a new function every time, then it would print out false every time.

Demo: https://codesandbox.io/s/affectionate-dewdney-556mn?file=/src/App.js

Seeing useMemo() speeds up our webpage

Kenneth Lum — Fri, 19 Mar 2021 05:48:01 +0000

In some situations, we may not need to re-render a component every time.

For example, if a component depends on a number n, and our n doesn't change. Or, if the page footer is quite complicated, and we make it so that our page does not re-render it every time because it is the same every time, we can use useMemo().

As an example, we are simulating a page footer here, and to add to its "work", we calculate 69! (69 factorial). The value was the maximum number that can be displayed on a simple calculator.

Demo: https://codesandbox.io/s/vigilant-newton-5ocvf?file=/src/App.js

We can try clicking on the button to add the count on the page. The UI is quite responsive.

To experiment, let's increase the factorial to 30000! (30,000 factorial), and here is a demo:
https://codesandbox.io/s/priceless-platform-ifigu?file=/src/App.js

We can see that every time we click on the button, the update on the page is really slow. That's because the Footer component (or any costly component) is being re-rendered every time our count is updated.

(sidenote: it also feels much longer than the 0.36 seconds (as tested on a MacBook Air). This partly may be due to the Footer component has a really wide width to accommodate the number, so the browser has to spend a lot of resource to render it. If we merely prints out the binary length of the number, it is quite faster: https://codesandbox.io/s/divine-https-i6chz?file=/src/App.js But to keep it as slow as possible, we will print out the whole number again in the example below.)

So we can use useMemo() to memoize the component (memoizing what Footer returns).

const myFooter = useMemo(() => <Footer n={30000} />, []);

Demo: https://codesandbox.io/s/brave-noyce-zby1w?file=/src/App.js

Here, we are saying this component doesn't not depend on anything, so we provide an empty array at the end of useMemo(). If for any reason we depend on some value to render this component, we'd add it to this array. This is similar to how useEffect() works for its dependency array.

So here, when we click on the button, the page updates close to instantly, without going through the steps of getting the result from the Footer rendering.

Reference: https://reactjs.org/docs/hooks-reference.html#usememo (Official docs)

P.S. It is Sept 2023 right now, and I am using a MacBook Air M2. The original "slow" app is taking only 0.09 seconds to re-render, so the unresponsiveness cannot be felt as easily. To change that, I have changed it to 60000! (60,000 factorial), and also display only the length of it, so that we are not testing the webpage needing a super wide area to display the number. The example is at:

https://codesandbox.io/s/priceless-platform-ifigu?file=/src/App.js

and the version using useMemo:
https://codesandbox.io/s/cranky-kare-fgp48m?file=/src/App.js

The two general patterns of useEffect() in React Hooks

Kenneth Lum — Wed, 17 Mar 2021 04:29:51 +0000

When we use useEffect(), there are two common patterns. Let's start with the easier one:

useEffect(() => {
  // do the set up

  return () => { 
    // do the take down
  };
}, []);

Here, we are providing an empty dependency array at the end, so the provided function will only execute once. It is for "set up" and "take down".

Where it says // do the set up, it is to do the set up, such as fetching data, or getting some data from localStorage, or set up any setInterval() or setTimeout(). This is similar to componentDidMount back in the days of class components.

Then that function returns another function, and this function is to "take down" or "clean up". It is where // do the take down is up above. This is similar to componentWillUnmount in the class components.

So it is quite clear: one set up, one clean up.

The pattern above is to run once. The other pattern is to "run often".

It can be

useEffect(() => {
  // do the set up

  return () => { 
    // do the take down
  };
});

useEffect(() => {
  // do the set up

  return () => { 
    // do the take down
  };
}, [friendID]);

Note that the first form does not have the dependency array at all. This way, it is to run every time. Typically, it is to "take down" once, and to "set up" once, having a "small loop" between our grand "set up" and "take down". It is similar to what we do for componentDidUpdate.

The code below that is to run every time when friendID changes, and it is for example, to "take down" the subscription of whether the friend is online or not, and then subscribe to another friend's online status to see whether the friend is online or not. So we can view it as a tiny take down, and a tiny set up.

So that's basically it, two actions for componentDidMount and componentWillUnmount, and then the "tiny actions" or a tiny loop, each time for a componentDidUpdate.

And if we have to do something for the "grand" set up and take down, and then a "tiny loop", and the actions are quite different for them, then we can use two useEffect():

useEffect(() => {
  // do the set up

  return () => { 
    // do the take down
  };
}, []);

useEffect(() => {
  // do the set up

  return () => { 
    // do the take down
  };
}, [friendID]);

so the first useEffect() is to run once, for the grand set up and take down, and the second one is for the "tiny loop".

Reference:

https://reactjs.org/docs/hooks-effect.html (Official docs)
https://reactjs.org/docs/hooks-overview.html
https://wattenberger.com/blog/react-hooks by Amelia Wattenberger
https://overreacted.io/a-complete-guide-to-useeffect/ by Dan Abramov