DEV Community: TrinhDinhHuy

Prettier and ESLint Automation Cheat Sheet

TrinhDinhHuy — Fri, 18 Jun 2021 03:34:36 +0000

Why

👉 Preventing you from committing bad code. This is the cheapest thing you can do to make sure your code is valid

Setup

Prettier
Eslint
StyleLint
Ability to validate code locally
Automatically run code validation with Husky and lint-staged

🛠 1. Prettier

Make the code styling of the project more consistent
Stop argument about coding styles between developers

🐨 Dependencies

npm install -D prettier

🐨 Configuration

Try the Playground and copy your preferred config by clicking the Copy config JSON button. Then put it in the .prettierrc.json

{
    "arrowParens": "always",
    "bracketSpacing": true,
    "embeddedLanguageFormatting": "auto",
    "htmlWhitespaceSensitivity": "css",
    "insertPragma": false,
    "jsxBracketSameLine": false,
    "jsxSingleQuote": false,
    "printWidth": 80,
    "proseWrap": "preserve",
    "quoteProps": "as-needed",
    "requirePragma": false,
    "semi": false,
    "singleQuote": false,
    "tabWidth": 4,
    "trailingComma": "es5",
    "useTabs": false,
    "vueIndentScriptAndStyle": false
}

🐨 Scripts

Add this to package.json

"scripts": {
    "prettier": "prettier --ignore-path .gitignore \"**/*.+(ts|tsx|js|jsx|json|css|md|mdx|html)\"",
    "format": "npm run prettier -- --write",
    "check-format": "npm run prettier -- --list-different",
}

To exclude files from formatting, create a .prettierignore file in the root of your project or you can use --ignore-path to ignore files listed in the gitignore docs

💰 Check the code here

Check how to enable auto format on save with prettier

⚒️ 2. ESLint

Analyze your code to quickly find problems
Fix Automatically
You can customize ESLint to work exactly the way you need

🐨 Dependencies

npm install -D eslint eslint-config-prettier eslint-plugin-react

🐨 Configuration

Put it in the .eslintrc

{
  "parserOptions": {
    "ecmaVersion": 2021,
    "sourceType": "module",
    "ecmaFeatures": {
      "jsx": true
    }
  },
  "extends": ["eslint:recommended", "eslint-config-prettier", "plugin:react/recommended"],
  "rules": {
    "no-unused-vars": ["error", {}],
  },
  "plugins": [
    "react"
  ],
  "env": {
    "browser": true
  }
}

Check list of Eslint rules here

Note that

We use eslint-config-prettier to turns off all rules that are unnecessary or might conflict with Prettier
Feel free to remove eslint-plugin-react if you don't use React

🐨 Script
Add this to package.json

"scripts": {
    "lint": "eslint --ignore-path .gitignore \"**/*.+(js|jsx)\"",
}

💰 Check the code here

See eslint feedback in your editor:

❓️ QA:

🙋‍♂️ Differences between eslint and prettier?

Use prettier for formatting and linters for catching bugs
Check Prettier vs. Linters

🙋‍♂️ Differences between extends and plugins?

Extends: existing set of predefined rules
Plugins: provides a set of new rules
Check stackoverflow

🛡 3. Validate script

Now Eslint and Prettier are all set. We add a script that runs prettier and lint to validate our code

🐨 Script
Add this to package.json

"scripts": {
    "validate": "npm run check-format & npm run lint"
}

We can run all these scripts in parallel by using npm-run-all

🐨 Dependencies

npm install -D npm-run-all

🐨 Update Script

"scripts": {
    "validate": "npm-run-all --parallel lint check-format"
}

💰 Check the code here

🔭 4. Husky

We don't want to run the validate script npm run validate manually before committing our code.
Husky helps us run a script automatically before committing the code

🐨 Dependencies

npm install -D husky
npm set-script prepare "husky install"
npx husky add .husky/pre-commit "npm run validate"

Basically we say that please automatically run npm run validate before every commit

Try to break the styling of your code then commit the files!

💰 Check the code here

🔬 5. Lint-staged

Running lint and styling check on the whole project is slow, you only want to lint files that will be committed.

🐨 Dependencies

npm install -D lint-staged

🐨 Configuration

Add this to package.json

"lint-staged": {
  "**/*.+(js|jsx)": [
    "eslint"
  ],
  "**/*.+(ts|tsx|js|jsx|json|css|md|mdx|html)": [
    "prettier --write",
    "git add"
  ]
}

🐨 Update Husky pre-commit script

npx husky set .husky/pre-commit "npx lint-staged"

Try to break the styling of your code then commit the files!

💰 Check the code here

🎁 6. Stylelint (Bonus)

It's like Eslint but for your css.

🐨 Dependencies

npm install -D stylelint stylelint-config-standard stylelint-config-prettier

🐨 Configuration

Add this to .stylelintrc.json

{
  "extends": [
    "stylelint-config-standard",
    "stylelint-config-prettier"
  ]
}

We use stylelint-config-prettier to turns off all rules that are unnecessary or might conflict with Prettier

🐨 Script

"scripts": {
  "lint:css": "stylelint --ignore-path .gitignore --fix \"**/*.css\""
},

🐨 Update lint-staged

"lint-staged": {
  // other configs ...
  "**/*.css": [
    "stylelint --fix"
  ],
}

💰 Check the code here

Working with SCSS? Check here
Working with Styled-component? Check here

Resources

🍀 Check the final code
🍀 I learned this setup from Kent's static-testing-tools repo. I added Stylelint and also migrated Husky to v6.
🍀 Working with TypeScript? Check here

Improve knowledge sharing in your organization- Part II: Internal blog

TrinhDinhHuy — Sun, 13 Jun 2021 14:47:42 +0000

Please check part I here if you haven't and share with me how you promote knowledge sharing in your organization

I notice that we always take notes as we learn. Gradually we start to build our second brain, a reference sheet that we can go back and refer to when we need it. However, we usually keep them in private.

We have, let say, 30 or more than 100 people in our organization
What if each of us publishes only 10% of our notes. 🔥 It's cooool

🐨 I am talking about building an internal blog for an organization.

One way to lower the bar is not to call it a blog. (tip from Stephan when we discussed this topic on a Discord channel) 😊

I also notice that people are afraid of the term Blog (too serious). So I will call it a Note system. We write down some notes every day, just try to put them in one place and share it with others.

Benefits

1. All knowledge in one place

Note system is an excellent way to store knowledge that can be searched and referred to for new employees and all people. So, for example, if someone asks a question on Slack that we already had an answer, we can refer them to the right post. No need to do the same homework again.

People can also actively search for materials that they want to learn. It is easy to learn across competencies too. For example, as a developer, I can see what people are doing in the SEO or Design team.

We don't need to worry about who should maintain the materials like we do if we use a Wiki page or Google docs since people own their posts and will maintain their posts by themselves.

2. Create a sharing culture

As I mentioned before, we all take notes for ourselves all the time. We already had the materials. Therefore, publishing part of our notes is not so difficult to do (compared to giving a talk in front of many people).

Since this is for internal, we can write in an informal style or just share our notes we already had. Feel free to express different ideas.

If we see others share their knowledge, we naturally want to contribute too.

We can easily share some notes while others can improve or build upon them.

3. Sharing is the best way of learning

You can learn in public. Sharing is a good way of receive feedbacks. I tested this idea before. About a month ago, I presented "10 tips to improve readability in JavaScript" to a small group of devs. After that, I quickly converted my talk into a small blog.

I received tons of feedback as people expressed their ideas in the comment section. Some colleagues sent me Slack messages and suggested how I can improve the post. One created a PR to fix some mistakes that I made.

Suddenly I feel surrounded by love, and it gives me a sense of being part of the team. It motivates me to contribute more.

Besides that, you can also solidify what you learn.

4. We can see what others are doing

By observing other's posts, we can know what topic they are interested in. Therefore, it connects people with the same interest. We can learn lessons that people had in different projects.

The marketing team could also ask people to combine their posts into a blog to share them publicly. It shows our clients that we know our stuff.

Q&A.

1. Everyone knows everything I know.

Everything I know has already been taught a dozen times over?
What if someone already noted what I want to share?

👉 "No matter how experienced or inexperienced you feel, you have something to share with someone".

👉 "We each have our unique approaches that can reach different people in different ways." Your experience is just unique. Keep sharing.

Have you ever seen a McDonalds next to a Burger King?

2. What can I share?

We work on different stacks. How can I share something that other want?

👉 Whenever you learn a new thing or solve a problem, you have good things to share. If you struggled with something, there is a good chance that others may work with it too. Share what you've struggled with

👉 Just share sth you learn/know. In this way, you have something for yourself to refer back to when you need it. If it is relevant to someone, it's a bonus.

👉 Whatever your thing is, make the thing you wish you had found when you were learning

👉 Everyone can see your interest at least

3. It takes time to write a blog

👉 My mistake. I shouldn't call it a blog. It's just a small note that you might already take every day.

🔥 Solidifying what you learn
🔥 Blog about what you've struggled with
🔥 Programming Your Brain: The Art of Learning in Three Steps
🔥 Blogging as a Developer
🔥 Why Blogging is Awesome

Time for discussion

🙏 Do you have an internal blog in your organization?

🙏 What do you think about internal blog?

Please leave your comments below

Improve knowledge sharing in your organization - Part I: Motivation

TrinhDinhHuy — Sun, 13 Jun 2021 14:46:51 +0000

I mainly worked at consultancy companies throughout my career. We have to work with many projects using various tech stacks.

Sooner or later, everyone would notice the benefits of knowledge sharing between people in the same organization. If the organization is relatively small, it's easy to keep track of what others did. However, if the organization starts to grow big, we soon face some challenges in knowledge sharing.

Note that this is just my very opinionated opinion. Please leave your comments below to let me know the problems you face regarding knowledge sharing and how you would solve them.

In this post, I would like to discuss challenges we may have and possible solutions 🐨 to improve knowledge sharing in a big organization.

I love challenges. Let's take a look. 😋

1. 🏋️‍♂️ We don't have a good overview of what people have.

As a new person who joins a company, I would like to know

how many people know XYZ
who is interested in the same topic as I am

Well. I guess I can start to ask around, and eventually, I will have all the answers. But what if people change their interests?

🧑‍💻 Should I start to ask around again?

Only after a pretty long time, I figure out that one of my colleagues has extensive experience on one particular topic. I wish I could learn it in the first place.

🐨 We could tackle this issue by creating a profile for everyone. Then, we can freely express what we are good at and what we want to learn. People can view each other's profile.

👾 But if we don't have a convenient way to search for a profile or we still don't have a big picture of what people are good at. Technically, we have already ruined the idea of interest sharing.

2. 🏋️‍♂️ We research the same things over and over again.

Shopify vs Woocommerce. Which platform should I use?
What's the best URL structure for SEO?
Where can I start to learn about this topic?
What is cool about this project?

Be proactive on what I want to learn. I can actively search for a course that I wish to. But since we have worked on many projects, we might already have tons of materials/lessons learned. As working in the same organization, we might have to deal with the same problems.

🧑‍💻 I see people do the same homework over and over again when we start a new project.

Sometimes it's not that easy. We can't just google it. It could be a waste of time if the answers are already there.

But, hey, it's summer. Just "copy" your friends' homework, then enjoy the sun. We all want to stand on the shoulders of giants.

🐨 Let's create documentation for every project.

From my point of view, every project should at least has documentation. In this way, we can swiftly onboard new people to a project. In addition, we can put all the cool tricks that we did and show them to the world.

👾 We can do more. Check the next challenge.

3.🏋️‍♂️ It's hard to search for and maintain materials.

I have to admit that sometimes I feel documentation is fantastic if we want to share information between people in the same project. But, on the other hand, it could be not so good to share it with people outside the project.

Let's say that React testing is quite common in many projects, and I want to know how people set it up. After asking around, people point me to an XYZ project documentation.

🧑‍💻 I have to go through lengthy docs and understand the project to just search for what I need. If the project is complicated, it's hard to just grasp what I really want.

I don't quite care about a particular project. I just want to learn about React testing. Docs are sometimes too formal, less fun to learn.

🐨 Let's put all common and essential materials on the Wiki page or Google docs.

So React testing is quite common, huh. We can create a small project to demonstrate this particular technique (optional) and write a post about it. Then, if there are valuable materials out there, we can put all references to the post too. In this way, people in other projects can still enjoy the material.

👾 But I still cannot find those materials (it's hard to search in Google docs)

👾 Who is responsible for maintaining those materials? If the material is out of date, should I be the one who can update it?

👾 I don't know if I have permission to contribute to our standard materials

👾 I have other ideas and different points of view and want to share

By putting materials under company's Google Docs, I feel that it's something standard and official. I am not sure if I have the right to edit it.

As working at a consultancy company, I am not a huge fan of "standard" material (things might be different for product companies). Standard material might "force" people to use the same particular boilerplates or techniques. Thus, it prevents people from their creativity.

4. 🏋️‍♂️ It's hard to learn across different competencies.

We might have various competencies such as Dev, SEO, Design in our organization. For example, I am a developer, but what if I want to learn more about design. What is a good way?

Other places we might share our knowledge

Of course, there is no perfect solution, so we may need to combine all solutions that work best for us.

1. Slack/Discord

These channels are fantastic if I want to discuss a topic or ask for help quickly. We have many good discussions on Slack.

👾 From my experience, anything discussed on Slack is eventually lost.

The topic may not be relevant to me when we discussed it. But later, when I need it, I can not find the thread. Slack is not meant to be used for storing long-form content

2. Talk/Workshop

I always enjoy workshops. I feel it like watching a good movie when I can learn something new.

👾 "It could be a barrier for people who are frightening to present in front of a group."

3. Pair programming

"Having two people work on a piece of the code helps the team spread knowledge on technology and domain on a daily basis and prevents silos of knowledge."

🎁 Read more at On Pair Programming

A possible solution that may fill the gap

I notice that we always take notes as we learn. Gradually we start to build our second brain, a reference sheet that we can go back and refer to when we need it. However, we usually keep them in private.

Here are the notes that I've taken over time.

🐨 We have, let say, 30 or more than 100 people in our organization
🐨 What if each of us publishes only 10% of our notes.
🔥 It's cooool

🐨 I am talking about building an internal blog for an organization. It could fill the gap that we are missing in all the solutions described above.

👉 Check out Part II: Internal blog for organization.

Time for discussion

Please leave your comments below to let me know the problems you face regarding knowledge sharing and how you would solve them.

10 tips to improve readability in Javascript

TrinhDinhHuy — Fri, 21 May 2021 09:27:37 +0000

1. Log level and semantic methods

📚 Console docs

console.log("hello world")
console.warn("this is a warning")
console.error("this is an error")
console.info("this is info")
console.debug("this is debug")
console.trace("show trace")

👉 If you try the console.warn, you will get the trace which means that it is easier to debug the code

Let's try other console functions yourself :)

⚠️ Original code

console.log("Error: API key should not be empty")

👉 Refactor

console.error("Error: API key should not be empty")

2. Avoid negative names for boolean variables

😕 It is hard to read double negatives

isStarted 🤜 🤛 isNotStarted

⚠️ Original code

const isInvalidApiKey = apiKey === null

if (isInvalidApiKey) {}

👉 Refactor

const isValidApiKey = apiKey != null

if (!isValidApiKey) {}

3. Avoid flag params

😕 You don't know what the flag params are used for util you have to read the function declaration

⚠️ Original code

renderResult(true)

function renderResult(isAuthenticated) {
    if (isAuthenticated) {
       return <p>App</p>
    } else {
        return <p>Please login</p>
    }

}

🐨 Use object params

renderResult({isAuthenticated: true})

function renderResult({isAuthenticated}) {
    if (isAuthenticated) {
        return <p>App</p>
    } else {
        return <p>Please login</p>
    }

}

🐨 Use 2 functions

function renderAuthenticatedApp() {
    return <p>App</p>
}

function renderUnAuthenticatedApp() {
    return <p>Please login</p>
}

isAuthenticated ? renderAuthenticatedApp() : renderUnAuthenticatedApp()

4. Use guard clauses

😕 Nesting hell

🐨 Make our code fail fast
🐨 Natural flow

if (statusCode === 200) {
    // success
} else {
    if (statusCode === 500) {
        // Internal Server Error
    } else if (statusCode === 400) {
        // Not Found
    } else {
        // Other error
    }
}

if (statusCode === 500) {
    // Internal Server Error
}

if (statusCode === 400) {
    // Not Found
}

if (statusCode !== 200) {
    // Other error
}

// success

5. Make code self-explanatory

🐨 Easy to understand
🐨 Reusable
🐨 A long descriptive name is better than a long comment

// verify that user has added a credit card
function verify(user) {}

function verifyThatUserHasAddedCreditCard(user) {}

⚠️ Original code

 if (country !== 'finland' &&
    country !== 'germany' &&
    country !== 'vietnam' &&
    country !== 'russia' &&
    type !== '💣'
) {
    return Promise.reject('Not available')
}

👉 Refactor

const isInAvailableCountries = (
    country === 'finland' ||
    country === 'germany' ||
    country === 'vietnam' ||
    country === 'russia'
)

const hasBoom = type === '💣'

if (!isInAvailableCountries || hasBoom) {
    return Promise.reject('Not available')
}

🎁 Create a better condition

const availableCountries = ['finland', 'germany', 'vietnam', 'russia']
const isInAvailableCountries = availableCountries.includes(country)

const hasBoom = type === '💣'

if (!isInAvailableCountries || hasBoom) {
    return Promise.reject('Not available')
}

6. Make impossible states impossible

🐨 Easy to understand

🐨 Prevent lots of bugs

📚 Stop using isLoading booleans

isLoading: true
isError: false

isLoading: false
isError: true

// imposible states
isLoading: true
isError: true

const LOADING_STATE = 'LOADING_STATE'
const ERROR_STATE = 'ERROR_STATE'

const state = LOADING_STATE

⚠️ Original code

const [isLoading, setIsLoading] = React.useState(false)
const [error, setError] = React.useState(null)
const [coffee, setCoffee] = React.useState(null)

function handleButtonClick() {
    setIsLoading(true)
    setError(null)
    setCoffee(null)

    getCoffee('cappuccino', 'small', 'finland', true).then(coffee => {
        setIsLoading(false)
        setError(null)
        setCoffee(coffee)
    }).catch(error => {
        setIsLoading(false)
        setError(error)
    })
}

👉 Refactor

const state = {
    idle: 'idle',
    loading: 'loading',
    error: 'error',
    success: 'success',
}

const [error, setError] = React.useState(null)
const [coffee, setCoffee] = React.useState(null)
const [status, setStatus] = React.useState(state.idle) 

function handleButtonClick() {
    setStatus(state.loading)

    getCoffee('cappuccino', 'small', 'finland', true).then(coffee => {
        setStatus(state.success)
        setCoffee(coffee)
    }).catch(error => {
        setStatus(state.error)
        setError(error)
    })
}

7. Use objects for long argument lists

🐨 Params order won't matter

🐨 Easy to pass optional param

function getBox(type, size, price, color) {}

getBox('carry', undefined, 10, 'red')

function getBox(options) {
    const {type, size, price, color} = options
}

getBox({
    type: 'carry',
    price: 10,
    color: 'red'
})

⚠️ Original code

export function getCoffee(type, size, country, hasIce) {

getCoffee('cappuccino', 'small', 'finland', true)
}

👉 Refactor

function getCoffee(options) {
    const {type, size, country, hasIce} = options
}

getCoffee({
    type: 'cappuccino',
    size: 'small',
    country: 'finland',
    hasIce: true
})

8. Use Object.assign for defaults

function getBox(options) {

    options.type = options.type || 'carry'
    options.size = options.size || 'small'
    options.price = options.price || 10
    options.color = options.color || 'red'

    const {type, size, price, color} = options
}

function getBox(customOptions) {

    const defaults = {
        type: 'carry',
        size: 'small',
        price: 10,
        color: 'red',
    }

    const options = Object.assign(defaults, customOptions)

    const {type, size, price, color} = options
}

⚠️ Original code

export function getCoffee(type, size, country, hasIce) {

    type = type || 'cappuccino'
    size = size || 'small'
    country = country || 'finland'
    hasIce = hasIce || false
}

👉 Refactor

function getCoffee(customOptions) {
    const defaultOptions = {
        type: 'cappuccino',
        size: 'small',
        country: 'finland',
        hasIce: false
    }

    const options = Object.assign(defaultOptions, customOptions)
}

function getCoffee(options = {}) {
    const {
        type = 'cappuccino',
        size = 'small',
        country = 'finland',
        hasIce = false
    } = options
}

function getCoffee({
    type = 'cappuccino', 
    size = 'small',
    country = 'finland',
    hasIce = false
} = {}) {
}

9. Replacing switch statements with Object literals

Honestly, I love switch as well and I don't actually know when to use switch statement vs object literals. My feeling just tells me which one to go.

Check out these 2 blogs and decide which one is better for you

📚 Replacing switch statements with Object literals
📚 Switch is ok

const handleSaveCalculation = ({key}) => {
    switch (key) {
        case 'save-copy': {
            saveCopy()
            break
        }
        case 'override': {
            override()
            break
        }
        default:
            throw Error('Unknown action')
    }
}

handleSaveCalculation({key: 'save-copy'})

const handleSaveCalculation = ({key}) => {
    const actions = {
        'save-copy': saveCopy,
        'override': override,
        'default': () => throw Error('Unknown action')
    }

    const action = key in actions ? actions[key] : actions['default']
    return action();
}

handleSaveCalculation({key: 'save-copy'})

⚠️ Original code

let drink
switch(type) {
    case 'cappuccino':
        drink = 'Cappuccino';
        break;
    case 'flatWhite':
        drink = 'Flat White';
        break;
    case 'espresso':
        drink = 'Espresso';
        break;
    default:
        drink = 'Unknown drink';
}

👉 Refactor

const menu = {
    'cappuccino': 'Cappuccino',
    'flatWhite': 'Flat White',
    'espresso': 'Espresso',
    'default': 'Unknown drink'
}

const drink = menu[type] || menu['default']

10. Avoid Hasty Abstractions

😕 I don't know how to create a good abstraction but I've created many bad ones

🐨 prefer duplication over the wrong abstraction

🐨 Nothing is free. The code trades the ability to change requirements for reduced duplication, and it is not a good trade - Dan Abramov

📚 AHA Programming

📚 Goodbye, Clean Code

⚠️ My React Boilerplate

The code below is used to fetch an order and I am using Redux for the state management. What a boilerplate!!! Let's make an abstraction which I will regret later

Fetch an order

// Action Type
const FETCH_ORDERS_START = "FETCH_ORDERS_START";
const FETCH_ORDERS_SUCCESS = "FETCH_ORDERS_SUCCESS";
const FETCH_ORDERS_FAILED = "FETCH_ORDERS_FAILED";

// Action
export const fetchOrder = (token) => {
    return dispatch => {
        dispatch(fetchOrdersStart);
        axios.get('/orders.json?auth=' + token).then(res => {
            dispatch(fetchOrdersSuccess(res));
        }).catch(err => {
            dispatch(fetchOrdersFailed(err));
        });
    };

}

export const fetchOrdersSuccess = (orders) => {
    return {
        type: FETCH_ORDERS_SUCCESS,
        orders: orders,
    };
};

export const fetchOrdersFailed = (error) => {
    return {
        type: FETCH_ORDERS_FAILED,
        error: error,
    };
};

export const fetchOrdersStart = () => {
    return {
        type: FETCH_ORDERS_START,
    };
};

👉️ Abstraction

I dare you understand the abstraction code without clicking the link. And even go to that link, you have to read all the code to understand that abstraction.

If you want to take a deep look into this, checkout AHA Programming and Goodbye, Clean Code

// Action
const moduleName = 'order'
const path = '/order'

const {moduleActionTypes, moduleActions} = useModuleActions(moduleName, path)

function fetchOrder() {
    moduleActionTypes.getModel()    
}

function updateOrder(data) {
    moduleActionTypes.updateModel(data)
}

Resource

Github

What you may not know about the Error Boundary

TrinhDinhHuy — Fri, 23 Oct 2020 19:20:52 +0000

Prerequisite: Basic knowledge about React

I believe that you might know about Error Boundaries BUT do you know how to recover a component from an error? 😌 Do you know how to survive through the pandemic?

You might think our app is doing just fine UNTIL...

...it's 2020, let's talk about how Error Boundaries can protect our children components🦠

I decided to write this blog since I haven't seen many projects I worked with utilized the Error Boundary 👻 Even my friend who I really trust does not use it 😭

💪 Let's get started!

1. What's wrong?

What will happen when we run the below code?

import React from 'react'

const App = () => {

    return (<p>It's just a flu. No need ${vaccine.toUpperCase()}</p>) 🤧
}

You got it right. The icon 🤧 breaks the code and even after removing the icon, we will see the blank screen instead of the text. Open the console, we could see the error vaccine is not defined. We'd better show sth nicer to the user when the app crashes 😌

In a real-world project, it is not always obvious as the example above. It could be that the API doesn't return some important data that could easily break our application or we forget to pass some props to the component. Everything works fine until the pandemic hits us. 😷

2. Try - catch

import React from 'react'

const App = () => {
    try {
        return (<p>It's just a flu. No need ${vaccine.toUpperCase()}</p>)
    } catch {
        return (<p>Quarantine<p/>)
    }   
}

Perfect, it works 🙃 Now React renders the text Quarantine instead of a blank screen. It tells the user that something is wrong. But imagine that you have to wrap the try-catch block with every component ... it would be a nightmare

git commit -am "fix: wrap component within try-catch"

🎅 When you go to sleep, Santa comes and refactors the code

import React from 'react'

const Flu = () => (<p>It's just a flu. No need ${vaccine.toUpperCase()}</p>)

const App = () => {
    try {
        return (<Flu/>)
    } catch {
        return (<p>Quarantine<p/>)
    }   
}

It breaks again 🥴 Blank screen again 👀 Your try-catch block doesn't work anymore.

🤔 Why?

You can learn more about that Dark magic here

What if Santa has coronavirus and visits everybody at night?

Error Boundary

⭐ What is this?

Error Boundary is a React special component to catch any JavaScript errors anywhere in their child component tree. Basically, it is like a try-catch block but for the component. It must be a class component which must define either static getDerivedStateFromError() or componentDidCatch()

According to the React docs, we use static getDerivedStateFromError() to render a fallback UI after an error has been thrown. Use componentDidCatch() to log error information.

class ErrorBoundary extends React.Component {
  state = {error: null}

  static getDerivedStateFromError(error) {
    // Update state so the next render will show the fallback UI.
    return { error };
  }

  componentDidCatch(error, errorInfo) {
    // You can also log the error to an error reporting service
    console.log('logErrorToService: ', errorInfo);
  }

  render() {
    const {error} = this.state
    if (error) {
        return (<p>Quarantine 🤒</p>)
    }

    return this.props.children; 
  }
}

Look at these lines, if there is an error then we return the fallback component, else return the children.

  render() {
    const {error} = this.state
    if (error) {
        return (<p>Quarantine 🤒<p/>)
    }

    return this.props.children; 
  }

To use ErrorBoundary, we have to wrap our component within it

import React from 'react'

const Flu = () => (<p>It's just a flu. No need ${vaccine.toUpperCase()}</p>)

const App = () => {
   return (<Flu/>)
}

<ErrorBoundary>
  <App />
</ErrorBoundary>

Nice, now we see the text Quarantine which is our fallback component again instead of the blank screen. You can wrap top-level route components within ErrorBoundary (lock down the whole city 🦠) or whatever component that you want.It works just like a try-catch block 😇

import React from 'react'

const Flu = () => (<p>It's just a flu. No need ${vaccine.toUpperCase()}</p>)

const App = () => {
   return (
    <div>
        <h1>Got you<h1>
        <ErrorBoundary><Flu/></ErrorBoundary>
    </div>
    )
}

⭐ Get better

However, we don't always want Quarantine when we get the error. Let's pass the Fallback component to the Error Boundary instead.

class ErrorBoundary extends React.Component {

  .....

  render() {
    const {error} = this.state
    if (error) {
        return (<this.props.FallbackComponent error={error}/>)
    }

    return this.props.children; 
  }
}

Now, whoever uses our ErrorBoundary component can decide what they would display as the fallback. Notice that we can pass the error props to the Fallback component.


const ErrorFallback = ({error}) => (<p>Quarantine</p>)

<ErrorBoundary FallbackComponent={ErrorFallback}>
  <App />
</ErrorBoundary>

⭐ Recovery

Now we will take a look at how we can recover a component from an error.

Our use-case is a small Counter application. Every time we click on the button, the counter will increase by one. When the count value is equal to 3, the error will be thrown 💣 Pay attention to the Counter component

const Counter = ({count}) => {

   React.useEffect(() => {
      if (count === 3) {
         throw Error("Crash")
      }
   })

   return <p>{count}</p>
}

const ErrorFallback = () => (<p>Something went wrong</p>)

const App = () => {
   const [count, setCount] = React.useState(0)

   function onClick() {
      setCount(count => count + 1)
   }

   return (
      <div>
         <button onClick={onClick}>click</button>
         <ErrorBoundary FallbackComponent={ErrorFallback}>
            <Counter count={count} />
         </ErrorBoundary>
      </div>
   )
}

What will happen if we click the button 4 times?

🤥 A: The Counter will show number 4

☠️ B: The app will crash

🤞 C: The Counter will show "Something went wrong"

.
.
.
🚨 SPOILER ALERT
.
.
.

The correct answer is C

Because we wrap the Counter component within ErrorBoundary, the app will not crash when the error is thrown. Instead, you would see the fallback UI Something went wrong when you click the button 3 times. After that, it would still show the fallback UI even when you keep clicking the button. This means that our component is DEAD

This would be not ideal in some cases. For example, the app should only show an error when the user searches for the missing data (let's pretend the app would crash when the server returns empty). But then, if the user changes the query, the app should work as normal instead of showing an error. In our case, the app should still work when we click the button.

This could be done simply by adding the unique key prop to the ErrorBoundary. When the key changes, the ErrorBoundary will be unmounted and remounted. In our application, we would like to reset the ErrorBoundary and rerender the Counter when the count value changes.

const App = () => {
   const [count, setCount] = React.useState(0)

   function onClick() {
      setCount(count => count + 1)
   }

   return (
      <div>
         <button onClick={onClick}>click</button>
         <ErrorBoundary key={count} FallbackComponent={ErrorFallback}>
            <Counter count={count} />
         </ErrorBoundary>
      </div>
   )
}

3. A vaccine with react-error-boundary:

Let's install the react-error-boundary

npm install react-error-boundary

Then we can import the ErrorBoundary without having to write the component ourselves. Moreover, this version also has some cool features.

const ErrorFallback = ({error, resetErrorBoundary}) => (
   <div>
   <p>Something went wrong</p>
   <button onClick={resetErrorBoundary}>Try again</button>
</div>
)

const App = () => {
   const [count, setCount] = React.useState(0)

   function onClick() {
      setCount(count => count + 1)
   }

    function throwError() {
       setCount(3) // count = 3 will cause error
    }

    function handleReset() {
       setCount(0)
    }

   return (
      <div>
         <button onClick={onClick}>click</button>
         <button onClick={onClick}>throw error</button>
         <ErrorBoundary FallbackComponent={ErrorFallback} onRest={handleReset}>
            <DisplayCount count={count} />
         </ErrorBoundary>
      </div>
   )
}

Pay attention to our ErrorFallback component, you can see that The ErrorBoundary passes the resetErrorBoundary callback to the Fallback component. With this function, we can explicitly reset the state of ErrorBoundary by clicking on the Try again button.

We also pass an extra onRest prop to the ErrorBoundary component which will be triggered when the ErrorBoundary is reset. In this way, we can reset the count value to 0 when the user clicks on the try again button.

However, do you notice we are missing the behavior that the ErrorBoundary resets itself when the count value changes? Let's bring that feature back bypassing the resetKeys props to the component. That prop is exactly like our previous key props but it can receive an array instead of a single value.

const App = () => {

    .....

   return (
      <div>
         <button onClick={onClick}>click</button>
         <button onClick={onClick}>throw error</button>
         <ErrorBoundary FallbackComponent={ErrorFallback} onRest={handleReset} resetKeys={[count]>
            <DisplayCount count={count} />
         </ErrorBoundary>
      </div>
   )
}

🚨 Error Boundary also works best with React suspense for Data Fetching which is just the experimental feature. I might update this blog in the future 😇

4. Conclusion:

😷 It's not mandatory but we can consider using ErrorBoundary to protect our app by catching an unexpected error

Here are some good resources for you:

🙏 💪 Thanks for reading!

I would love to hear your ideas and feedback. Feel free to comment below!

✍️ Written by

Huy Trinh 🔥 🎩 ♥️ ♠️ ♦️ ♣️ 🤓

Software developer | Magic lover

Say Hello 👋 on

✅ Github

✅ LinkedIn

✅ Medium

Immer - Javascript Immutability the happy way

TrinhDinhHuy — Fri, 10 Jan 2020 10:16:41 +0000

Prerequisite: Basic knowledge about React and Immutability in Javascript

In this post, I am going to talk about Immer, a library that makes immutability in Javascript way easier and simpler.

I assume that you already know why we need immutability. If you don't, no worries, check this blog first 😍

🍹 Spoiler alert

If you want to make a mixed drink, pour wine and sodas into a glass, not the sodas into the bottle of wine. We call it Immutable Bottle of Wine

I let you decide why we should do that

💪 Let's get started!

1. Immutability in Javascript

Back to the first time I learned React, I only know one way to make the state immutable and I bet you are familiar with it too

Yes, you are absolutely right. Let's talk about ...

⭐ Spread operator

Our task today is to make a mixed drink for the New Year.

Discount 50% for anyone reading this blog

Our Happy Menu

🍷 The infamous mutable bottle of wine

One day, our new bartender got drunk, so he poured the sodas into the bottle of wine. Therefore, that bottle of wine was spoiled badly ⚠️

Next day, he used that wine bottle to mix other drinks to serve the guests. Of course, other drinkers did not realize that it is no longer the original drink but they could spot after tasting it 🐛🐛

const bottleOfWine = ['wine']

function mixWineAndSoda(bottleOfWine) {

  bottleOfWine.push('soda') // Opps, he spoiled the bottle of wine with sodas
}

mixWineAndSoda(bottleOfWine)

console.log(bottleOfWine) // ['wine', 'soda']

We modified the bottleOfWine array by accident when we put it into the mixWineAndSoda function. Imagine that we use this bottleOfWine in many functions and keep modifying it. It's really hard to debug and keep track of which function adding what to the bottleOfWine and what if we want to use our original array 🙃

🍹 The famous immutable bottle of wine

This drink is only for experienced coders who want to learn the correct way to mix wine and sodas

const bottleOfWine = ['wine']

function mixWineAndSoda(bottleOfWine) {

  // pour wine from bottle into a glass
  const wineGlass = {...bottleOfWine}

  // add soda
  wineGlass.push('soda')

  return wineGlass
}

const mixedDrink = mixWineAndSoda(bottleOfWine)

console.log(bottleOfWine) // ['wine']
console.log(mixedDrink) // ['wine', 'soda']

By making a copy of bottleOfWine then modify it, we prevent ourselves from imutating our original array

🤫 Spread operator is really cool. However, it could be painful when it comes to really nested object

Let's do a small task: Change the address of our bar from Paris to New York without mutate the barInfo object

const barInfo = {
  address: {
    country: {
      city: 'Paris'
    }
  }
}

🤫 Honestly, I struggled to do this task. Thanks to Netflix and The Witcher for helping me

🎶 Toss a coin to your Witcher. A friend of humanity

const updatedBarInfo = {
  ...barInfo,
  address: {
    ...barInfo.address,
    country: {
      ...barInfo.address.city,
      city: 'New York'
    }
  }
}

console.log(barInfo.address.country.city) // Paris
console.log(updatedBarInfo.address.country.city) // New York

⭐ ImmutableJS

There are other ways to achieve immutability including Object.assign or ImmutableJS. However, I find it complicated to use ImmutableJS as we have to learn and understand the whole new API to use it.

Let's take a quick look 🙄

import {fromJS} from 'immutable'

const barInfo = fromJS({
    address: {
        country: {
            city: 'Paris',
        },
    },
})

const updatedBarInfo = barInfo.updateIn (
    ['address', 'country', 'city'],
    value => 'New York',
)

console.log(barInfo) //Map {size: 1, _root: ArrayMapNode, ...}
console.log(barInfo.toJS().address.country.city) // Paris

console.log(updatedBarInfo) //Map {size: 1, _root: ArrayMapNode, ...}
console.log(updatedBarInfo.toJS().address.country.city) // New York

As you can see, we have to wrap the barInfo object within fromJs function to make it immutable. We then use updateIn to modify the city value. Note that barInfo is no longer a normal Javascript object, it becomes Immutable.Map. To turn it back to normal Javascript object, we have to use toJS().

And that's just a small part of ImmutableJS API

We have to learn the whole new API to use ImmutableJS effectively 👽

2. Immer in Javascript

All you need to remember is that Immer has a produce function that allows us to create a draft. By modifying the draft, we avoid mutating the original object.

produce(currentState, producer: (draftState) => void): nextState

💪 Let's take a look at our example

First, we wrap our object or array within the produce function then we can modify the draft without the fear of mutating the original object/array.

import produce from 'immer'

const bottleOfWine = ['wine']

function mixWineAndSoda(bottleOfWine) {

  const wineGlass = produce(bottleOfWine, draft => { // draft is our glass
    draft.push('soda') // add soda
  })

  return wineGlass
}

const mixedDrink = mixWineAndSoda(bottleOfWine)

console.log(bottleOfWine) // ['wine']
console.log(mixedDrink) // ['wine', 'soda']

Immer shows its magic when it comes to nested object since we can modify the draft as the way we do with normal javascript object or array

import produce from 'immer'

const barInfo = {
  address: {
    country: {
      city: 'Paris'
    }
  }
}

const updatedBarInfo = produce(barInfo, draft => {
    draft.address.country.city = 'New York' 🔥
})

console.log(barInfo.address.country.city) // Paris
console.log(updatedBarInfo.address.country.city) // New York

📢 Happy new year to everyone

3. Immer in React:

In React applications, we normally want to make sure our state is immutable.

Let's see how Immer works in React application

🔥 Immer with Producer in Redux State

In this example of Redux State, we want to update the value of label from Cocktail to Martini without mutating our original state. We can achieve that using Spread operator

const initialState = {
    data: {label: 'Cocktail'},
    isLoading: false
}

const reducer = (state = initialState, action) => {
    switch(action.type) {
        case CHANGE_LABEL:
            return {
                ...state,
                data {
                    ...state.data,
                    label: 'Martini'
                }
            }
    }
}

💪 Let's use Immer to simplify our reducer

produce(currentState, producer: (draftState) => void): nextState

import produce from 'immer'

const initialState = {
    data: {label: 'Cocktail'},
    isLoading: false
}

const reducer = (state = initialState, action) => {
    return produce(state, draft => {
        switch(action.type) {
            case CHANGE_LABEL:
                draft.data.label = 'Martini'
                break       
        }
    })
}

We use produce function to wrap our original state and then modify the draft. The produce function automatically returns a new state for us if we updated the draft.

🔥 Immer with Curried Producer in Redux State

We can even make it simpler by using Curried Producer 💪

If you work with functional programming, you will be familiar with the Currying concept. I will not cover the functional programming concepts here and if you don't work with functional programming, you can just accept the Curried Producer as a new syntax.

⚠️ With Curried Producer, the state is omitted and the initialState is passed as a second argument of produce

💪 Normal Producer

import produce from 'immer'

const reducer = (state = initialState, action) => {
    return produce(state, draft => {
        switch(action.type) {
            case CHANGE_LABEL:
                draft.data.label = 'Martini'
                break       
        }
    })
}

💪 Curried Producer

import produce from 'immer'

const reducer = produce(draft, action) => {
   switch(action.type) {
    case CHANGE_LABEL:
        draft.data.label = 'Martini'
        break       
   },
   initialState
}

You may ask what if you want to get the original state within the produce since the state is omitted. original comes into rescue 😎

import produce, {original} from 'immer'

const reducer = produce(draft, action) => {
   switch(action.type) {
    case CHANGE_LABEL:
        original(draft.data) // In case you really want to get data from the original state
        draft.data.label = 'Martini'
        break       
   },
   initialState
}

🔥 Immer in Component State

I will go through really quick without much explanation since it is the same as we've discussed above. However, I want to introduce you the use-immer library

In our example, we use React.useState hook for state management and we can update the state via updateBottleOfWine function

💪 Normal producer

import React from 'react
import produce from 'immer'

const App = () => {
    const [bottleOfWine, setBottleOfWine] =  React.useState(['wine'])

    function updateBottleOfWine() {
        setBottleOfWine(state => produce(state, draft => {
            draft.push('sodas')
        })
    }
}

💪 Simplify with Curried Producer

Pay attention to updateBottleOfWine function to see how we omit the state

import React from 'react
import produce from 'immer'

const App = () => {
    const [bottleOfWine, setBottleOfWine] =  React.useState(['wine'])

    function updateBottleOfWine() {
        setBottleOfWine(produce(draft => { //👈
            draft.push('sodas')
        })
    }
}

💪 Simplify with use-immer

We use useImmer instead of React.useState then we can just update the state directly without worrying about mutating the original state.

import React from 'react
import {useImmer} from 'use-immer'

const App = () => {
    const [bottleOfWine, setBottleOfWine] = useImmer(['wine']) // 👈

    function updateBottleOfWine() {
        setBottleOfWine(draft => {
            draft.push('sodas')
        })
    }
}

4. Conclusion:

Immer is a Javascript library that makes immutability way simple. By using Immer, we can find it easy to modify nested objects without the fear of mutating it. It is very straightforward to use Immer as we can modify object or array as the way we used to, without having to adopt the whole new API. 👏👏👏

Here are some good resources for you:

🙏 💪 Thanks for reading!

I would love to hear your ideas and feedback. Feel free to comment below!

✍️ Written by

Huy Trinh 🔥 🎩 ♥️ ♠️ ♦️ ♣️ 🤓

Software developer | Magic lover

Say Hello 👋 on

✅ Github

✅ LinkedIn

✅ Medium

Introduction to React.memo, useMemo and useCallback

TrinhDinhHuy — Wed, 06 Nov 2019 18:38:57 +0000

Prerequisite: Basic knowledge about React

Cover photo by Danika Perkinson on Unsplash

When I start to write this blog, I ask myself whether I should only talk about the differences between useMemo and useCallback because they are React Hooks while React.memo is not. Eventually, I decided to include React.memo as well since on the one hand the word memo in both terminologies might sound a bit confusing for people. On the other hand, it's all about React optimization 😁

1. What is React.memo

If you are familiar with React.PureComponent then React.memo is quite straightforward as it is exactly similar to React.PureComponent. We use React.PureComponent with class component while React.memo works with functional components 👌

Let's take a look at our example to see how it works. Codesandbox

Note: All the examples below are used only to express the main ideas. In reality, we don't need optimization in such simple cases

const App = () => {
    const [count1, setCount1] = React.useState(0)
    const [count2, setCount2] = React.useState(0)

    const increaseCounter1 = () => {
        setCount1(count1 => count1 + 1)
    }

    return (
        <>
            <button onClick={increaseCounter1}>Increase counter 1</button>
            <Counter value={count1}>Counter 1</Counter>
            <Counter value={count2}>Coutner 2</Counter>
        </>
    )
}

const Counter = ({value, children}) => {
    console.log('Render: ', children)

    return (
        <div>
            {children}: {value}
        </div>
    )
}

export default Counter

Every time the user clicks on the button, the state of count1 changes causing the App to rerender both counters which is known as unnecessary re-render. However, we expect only the counter1 to be rerendered since nothing has changed with the counter2. In reality, both counters get rerendered.

How can we address this issue? 🤔 Well, React.memo is our answer. All we need to do is to wrap our Counter component within React.memo

const Counter = ({value, children}) => {
    console.log('Render: ', children)

    return (
        <div>
            {children}: {value}
        </div>
    )
}

export default React.memo(Counter)

By default, React.memo will compare all props passed to the component by referential equality. If these props are unchanged, React.memo will reuse the last rendered result, therefore, it prevents the component from being rerendered. In our example, React.memo will check if there are any changes with the value and children props since the last render. Since our button only changes the value of the counter1, React.memo will prevent the counter2 from being rerendered. 😎💪

We can also override the default comparison of React.memo by providing a custom comparison function as the second argument.

From React.memo documentation

const Counter = () => {

   const areEqual = (prevProps, nextProps) => {
     /*
     return true if passing nextProps to render would return
     the same result as passing prevProps to render,
     otherwise return false
     */
   } 
}

export default React.memo(Counter, areEqual)

2. useMemo and useCallback

I will start with the documentation

useMemo returns a memoized value

React.useMemo(() => {
  fooFunction()
}, [dependencies])

useCallback returns a memoized callback

React.useCallback(() => {
  fooFunction()
}, [dependencies])

💪 Let's break it down together

Both React.useMemo and React.useCallback receives a function as its first argument and a dependencies array as the second one. The hook will return a new value only when one of the dependencies value changes (referential equality). The main difference is that React.useMemo will call the fooFunction and return its result while React.useCallback will return the fooFunction without calling it.

😫 Example please codesandbox

const App = () => {
    const fooFunction = () => {
        return 'Foo is just Food without D'
    }

    const useMemoResult = React.useMemo(fooFunction, [])
    const useCallbackResult = React.useCallback(fooFunction, [])

    console.log('useMemoResult: ', useMemoResult)
    console.log('useCallbackResult: ', useCallbackResult)

    return <p>Foo is just food without D</p>
}

If you run the code and take a look at your console, not refrigerator, you can see the following output

React.useMemo runs the fooFunction which returns a string Foo is just Food without D while React.useCallback just returns a fooFunction without calling it

🤩 Got it. But how does it work in React?

🍀 useMemo

Normally we could use React.useMemo when we compute expensive value that we don't want to compute it again and again when the component is rerendered

const Me = ({girlFriendWords}) => {

    // Provided that girlFriendWords is a string

    const myReply = decideWhatToSay (girlFriendWords)

    return <p>{myReply}</p>
}

Imagine that it takes full of my energy to calculate myReply value and what if I have to do it again and again (recalculate) when my girl friend says something (rerender) 🤐

🔥 React.useMemo comes to rescue

const Me = ({girlFriendWords}) => {

    // Provided that girlFriendWords is a string

    const myReply = React.useMemo(() => decideWhatToSay (girlFriendWords), [girlFriendWords])

    return <p>{myReply}</p>
}

Thanks to React.useMemo, I couldn't have finished this blog without you 💑

React.useMemo takes [girlFriendWords] as its dependencies array which means that it will only run decideWhatToSay function when girlFriendWords value changes. I don't have to think twice to reply when my girlfriend says the same thing. Optimization here 🎉🍀💐

🍀 useCallback

Enough relationship story, let's get back to our Counter example. Let's tweak the example a little bit, our counter now also receives onClick function as a prop. Could you guess whether our Counter2 component will be rerendered when count1 value change

const App = () => {
    const [count1, setCount1] = React.useState(0)
    const [count2, setCount2] = React.useState(0)

    const increaseCounter1 = () => {
        setCount1(count1 => count1 + 1)
    }

    const increaseCounter2 = () => {
            setCount1(count2 => count1 + 1)
    }

    return (
        <>
            <Counter value={count1} onClick={increaseCounter1}>Counter 1</Counter>
            <Counter value={count2} onClick={increaseCounter2}>Coutner 2</Counter>
        </>
    )
}

const Counter = ({value, children, onClick}) => {
    console.log('Render: ', children)

    return (
        <Button onClick={}>
            {children}: {value}
        </div>
    )
}

export default React.memo(Counter)

The answer is YES 😮.

Even when we use React.memo, the counter2 component is still rerendered when only the count1 changes because React.memo uses reference equality to prevent unnecessary renders. However, when App is rerendered, the increaseCounter2 is recreated, therefore, the onClick props passed into the Counter component is different every time which causes the component to be rerendered. The easy way to avoid this issue is to prevent the increaseCounter2 function from being recreated when the App is rerendered.

We make use of React.useCallback to do this

const App = () => {
    const [count1, setCount1] = React.useState(0)
    const [count2, setCount2] = React.useState(0)

    const increaseCounter1 = React.useCallback(() => {
        setCount1(count1 => count1 + 1)
    }, [])

    const increaseCounter2 = React.useCallback(() => {
            setCount2(count2 => count1 + 1)
    }, [])

    return (
        <>
            <Counter value={count1} onClick={increaseCounter1}>Counter 1</Counter>
            <Counter value={count2} onClick={increaseCounter2}>Coutner 2</Counter>
        </>
    )
}

Take a look at the dependencies array, it's empty because I want to create these functions only once. In this way, the onClick props passed to the Counter component is always the same

3. Conclusion:

🚀 We should not optimize unnecessary rerenders without measuring the cost first. Optimization always comes with a cost
🚀 React.memo is similar to React.PureComponent except the fact that it is used for functional component while React.PureComponent is used only in class component
🚀 React.useMemo returns a memoized value while React.useCallback return a memoized callback

Here are some good resources for you:

🙏 💪 Thanks for reading!

I would love to hear your ideas and feedback. Feel free to comment below!

✍️ Written by

Huy Trinh 🔥 🎩 ♥️ ♠️ ♦️ ♣️ 🤓

Software developer | Magic lover

Say Hello 👋 on

✅ Github

✅ LinkedIn

✅ Medium

Introduction to useRef Hook

TrinhDinhHuy — Mon, 09 Sep 2019 15:51:05 +0000

Prerequisite: Basic knowledge about React and Refs and the dom in React

This post is going to talk about what is useRef hook and when we can use it.

The first time I learned Hooks, I have so many questions that I need to look for the answers. One of those questions is how I can compare the current state/props with the previous one or handle deep object comparison in useEffect Hook. I would only figure it out when I learned about useRef Hook then every pieces fall into place.

💪 Let's get started!

1. What is useRef hook?

Refs provide a way to access DOM nodes or React elements created in the render method.

Our example is about managing the focus of an input when the user clicks on the button. To do that, we will use the createRef API

• createRef API

import {createRef} from 'react' 

const FocusInput = () => {
   const inputEl = createRef()

   const focusInput = () => {
      inputEl.current.focus()
   }

   return (
      <>
         <input ref={inputEl} type="text" />
         <button onClick={focusInput}>Focus input</button>
      </div>
   )
}

We can achieve exactly the same result with useRef hook

• useRef Hook

const FocusInput = () => {
   const inputEl = React.useRef()

   const focusInput = () => {
      inputEl.current.focus()
   }

   return (
      <>
         <input ref={inputEl} type="text" />
         <button onClick={focusInput}>Focus input</button>
      </>
   )
}

🤔 Wait! What's the difference?

I asked the same question when I first read about useRef. Why do we need to use useRef hook when we can use createRef API to manage the focus of an input? Does the React team just want to make the code look consistent by creating a doppelganger when they introduced Hooks in React 16.8?

Well, the difference is that createRef will return a new ref on every render while useRef will return the same ref each time.

useRef returns a mutable ref object whose .current property is initialized to the passed argument (initialValue). The returned object will persist for the full lifetime of the component.

const Test = () => {
    const [renderIndex, setRenderIndex] = React.useState(1)
   const refFromUseRef = React.useRef()
   const refFromCreateRef = createRef()

   if (!refFromUseRef.current) {
      refFromUseRef.current = renderIndex
   }

   if (!refFromCreateRef.current) {
      refFromCreateRef.current = renderIndex
   }

   return (
      <>
         <p>Current render index: {renderIndex}</p>
         <p>
            <b>refFromUseRef</b> value: {refFromUseRef.current}
         </p>
         <p>
            <b>refFromCreateRef</b> value:{refFromCreateRef.current}
         </p>

         <button onClick={() => setRenderIndex(prev => prev + 1)}>
            Cause re-render
         </button>
      </>
   )
}

As you can see, refFromUseRef persists its value even when the component rerenders while refFromCreateRef does not

You can find this comparation of useRef and createRef in Ryan Cogswell's answer on stackoverflow

👏 Interesting! useRef can hold a value in its .current property and it can persist after the component rerenders. Therefore, useRef is useful more than just managing the component ref

2. Beyond the Ref attribute

Apart from ref attribute, we can use useRef hook to make a custom comparison instead of using the default shallow comparison in useEffect hook. Take a look at our example 😇

const Profile = () => {
   const [user, setUser] = React.useState({name: 'Alex', weight: 40})

   React.useEffect(() => {
      console.log('You need to do exercise!')
   }, [user])

   const gainWeight = () => {
      const newWeight = Math.random() >= 0.5 ? user.weight : user.weight + 1
      setUser(user => ({...user, weight: newWeight}))
   }

   return (
      <>
         <p>Current weight: {user.weight}</p>
         <button onClick={gainWeight}>Eat burger</button>
      </>
   )
}

export default Profile

Provided that the user's name will always unchanged. Our expectation is that the effect will output the warning text only when user has gained weight. However, if you test the code above, you can see that our effect run every time the user clicks on the button, even when the weight property stays the same. That is because useEffect Hook use shallow comparison by default while our userState is an object. 🐛🐛🐛

🔧 To fix this bug, we need to write our own comparison instead of using the default one.

👉 Step 1: use lodash isEqual method for deep comparision

const Profile = () => {
   const [user, setUser] = React.useState({name: 'Alex', weight: 40})

   React.useEffect(() => {
       if (!_.isEqual(previousUser, user) {
           console.log('You need to do exercise!')
       }
   })

    ...
}

export default Profile

We have just removed the dependency array in our effect and use the lodash isEqual method instead to make a deep comparison. Unfortunately, we run into a new issue because of the missing previousUser value. If we do the same thing with a class component in ComponentDidUpdate lifecycle, we can easily have the previous state value.

🔥 useRef comes to rescue

👉 Step 2: useRef for saving the previous state

const Profile = () => {
   const [user, setUser] = React.useState({name: 'Alex', weight: 20})

   React.useEffect(() => {
       const previousUser = previousUserRef.current
       if (!_.isEqual(previousUser, user) {
           console.log('You need to do exercise!')
       }
   })

   const previousUserRef = React.useRef()
   React.useEffect(() => {
      previousUserRef.current = user
   })

    ...
}

export default Profile

To keep track of the previousUser value, we save it to the .current property of useRef hook because it can survive even when the component rerenders. To do that another effect will be used to update the previousUserRef.current value after every renders. Finally, we can extract the previousUser value from previousUserRef.current, then we deep compare the previous value with the new one to make sure our effect only run when those values are different

👉 Step 3: extract effects to the custom Hooks

If you want to reuse the code, we can make a new custom hook. I just extract the code above to a function called usePrevious

const usePrevious = (value) => {
    const previousUserRef = React.useRef()
   React.useEffect(() => {
      previousUserRef.current = value
   }, [value])

   return previousUserRef.current
}

And to make it more generic, I will rename previousUserRef to ref

const usePrevious = (value) => {
    const ref = React.useRef()

    React.useEffect(() => {
      ref.current = value
    }, [value])

    return ref.current
}

Let's apply our custom usePrevious hook to the code

const Profile = () => {
    const initialValue = {name: 'Alex', weight: 20}
   const [user, setUser] = React.useState(initialValue)

    const previousUser = usePrevious(user)

   React.useEffect(() => {
       if (!_.isEqual(previousUser, user) {
           console.log('You need to do exercise!')
       }
   })

   const gainWeight = () => {
      const newWeight = Math.random() >= 0.5 ? user.weight : user.weight + 1
      setUser(user => ({...user, weight: newWeight}))
   }

   return (
      <>
         <p>Current weight: {user.weight}</p>
         <button onClick={gainWeight}>Eat burger</button>
      </>
   )
}

export default Profile

💪 How cool is that! You can also extract the deep comparison logic to a new custom Hook too. Check use-deep-compare-effect by Kent C. Dodds

3. Conclusion:

🚀 useRef Hook is more than just to manage DOM ref and it is definitely not createRef doppelganger. useRef can persist a value for a full lifetime of the component. However, note that the component will not rerender when the current value of useRef changes, if you want that effect, use useState hook instead 👏👏👏

Here are some good resources for you:

🙏 💪 Thanks for reading!

I would love to hear your ideas and feedback. Feel free to comment below!

✍️ Written by

Huy Trinh 🔥 🎩 ♥️ ♠️ ♦️ ♣️ 🤓

Software developer | Magic lover

Say Hello 👋 on

✅ Github

✅ LinkedIn

✅ Medium

Why React hooks (Part II: Reusable code)

TrinhDinhHuy — Mon, 02 Sep 2019 06:47:38 +0000

Prerequisite: Basic knowledge about React

This article is intended to give you an understanding of how React Hooks helps us to share common logic between components and what differences between using Hooks and other methods.

Take a look if you have not read the Part I

You spent 2 hours writing a beautiful functionality in your component and then just a minute later, your Boss wants the same thing ... but in another component. What should you do now?

😅 Easy, I will do some copy + paste stuff

As a React developer, you will at some point run into the situation where you have to share some common logic between components. Higher-order components (HOCs) are well known in the React community for solving that kind of issue. However, I found HOCs a little bit complicated for beginners to get the idea while Hooks makes it way much easier and cleaner.

💪 Let's get started!

‍Our task today is to help Carey to teach her naughty twins, Zack and Cody , she will shout at them if they do something bad many times

• Zack.jsx

class Zack extends React.Component {

    state = {
        numberOfBadActions: 0
    }

    componentDidUpdate(prevProps, prevState) {
       if (
        prevState.numberOfBadActions !== this.state.numberOfBadActions && 
        this.state.numberOfBadActions === 3
       ) {
        console.log('Use your head!')
        this.setState({numberOfBadActions: 0})
       }
    }

    doBadAction = () => {
        this.setState(state => ({numberOfBadActions: state.numberOfBadActions + 1}))
    }

    render() {
        return (
            <div>
                <p>Number of bad actions: {this.state.numberOfBadActions}</p>
                <button onClick={this.doBadAction}>Do bad action</button>
            </div>
        )
    }
}

export default Zack

Look at Cody, I have to shout at him, too! 😫

0. Copy + paste

I've just copied Zack.jsx and rename the file to Cody.jsx and also change the component name to Cody

• Cody.jsx

class Cody extends React.Component {

    state = {
        numberOfBadActions: 0
    }

    componentDidUpdate(prevProps, prevState) {
       if (
        prevState.numberOfBadActions !== this.state.numberOfBadActions && 
        this.state.numberOfBadActions === 3
       ) {
        console.log('Use your head!')
        this.setState({numberOfBadActions: 0})
       }
    }

    doBadAction = () => {
        this.setState(state => ({numberOfBadActions: state.numberOfBadActions + 1}))
    }

    render() {
        return (
            <div>
                <p>Number of bad actions: {this.state.numberOfBadActions}</p>
                <button onClick={this.doBadAction}>Do bad action</button>
            </div>
        )
    }
}

export default Cody

I feel like patting myself on the back for solving this in just 1 second 😎

It looks good for now until later Carey decides to change the method of teaching her sons. In that case, we end up updating 2 components at the same time and could you imagine what if she has to do the same thing with her sons' friends, too. That's tricky because we have to copy and paste the code everywhere and the hard part is that we have to update all these components if something related to that logic needs to be changed 😖

1. Higher-Order Component

A higher-order component is a function that takes a component and returns a new component

In our case, all you need to do is to take all the teaching-related things outside the React component and move it into a HOC

export const withMom = (WrappedComponent) => {
    return class WithMom extends React.Component {
         state = {
             numberOfBadActions: 0
         }

         componentDidUpdate(prevProps, prevState) {
            if (
              prevState.numberOfBadActions !== this.state.numberOfBadActions && 
              this.state.numberOfBadActions === 3
            ) {
              console.log('Use your head!')
              this.setState({numberOfBadActions: 0})
            }
         }

         doBadAction = () => {
            this.setState(state => ({numberOfBadActions: state.numberOfBadActions + 1}))
         }

         render() {
            return (
                <WrappedComponent 
                    numberOfBadActions={this.state.numberOfBadActions} 
                    doBadAction={this.doBadAction}
                    {...this.props}/>
                )   
         }   
    }
}

withMom HOC is a function that accepts one argument as Component and returns a new and enhanced Component with all logics related to teaching. Now you can use withMom HOC to wrap components like below 👇:

• Zack.jsx

class Zack extends React.Component {
    render() {
        return (
            <div>
                <p>Number of bad actions: {this.props.numberOfBadActions}</p>
                <button onClick={this.props.doBadAction}>Do bad action</button>
            </div>
        )
    }
}

export default withMom(Zack)

• Cody.jsx

class Cody extends React.Component {
    render() {
        return (
            <div>
                <p>Number of bad actions: {this.props.numberOfBadActions}</p>
                <button onClick={this.props.doBadAction}>Do bad action</button>
            </div>
        )
    }
}

export default withMom(Cody)

HOC helps you to organize your code in a much better way. In our case, Zack and Cody components do not care about the teaching logic anymore because now the withMom HOC encapsulates that logic and passes it down to the wrapped component. And the amazing part is that if Carey wants to change her method, all we need to do is to tweak the code in only 1 place - withMom HOC.

😓 Unfortunately, there is a major downside to using HOCs. Imagine that you have more than one HOC to consume then you start to face up with the problem of controlling all the passing down props and Wrapper Hell issue

export default withGrandPa( 
    withDad(
        withMom(
            Cody
        )
    )
)

Then our DOM looks like this

<WithGrandPa>
    <WithDad>
        <WithMom>
            <Cody/>
        </WithMom>
    </WithDad>
</WithGrandPa>

Normal people: Wrapper Hell

Me as an intellectual: My Asian family clean architecture 👪

2. React Hooks

🔥 It would be a long story here, stay with me and I will walk you through step by step.

If you have not read the Part I of this series, I recommend you read it first then come back otherwise you may get lost

• Step 1: Convert the Zack component to a function component

const Zack = () =>  {

    const [numberOfBadActions, setNumberOfBadActions] = React.useState(0)

    React.useEffect(() => {
        if (numberOfBadActions === 3) {
            console.log('Use your head!')
            setNumberOfBadActions(0)
        }
    }, [numberOfBadActions])

    const doBadAction = () => {
        setNumberOfBadActions(numberOfBadActions => numberOfBadActions + 1)
    }

    return (
      <div>
        <p>Number of bad actions: {numberOfBadActions}</p>
        <button onClick={doBadAction}>Do bad action</button>
      </div>               
    )
}

export default Zack

• Step 2: Write custom Hook

A custom Hook is a JavaScript function whose name starts with ”use” and that may call other Hooks.


const useYourHead = (initialNumberOfBadActions) => {
    const [numberOfBadActions, setNumberOfBadActions] = React.useState(initialNumberOfBadActions)

    React.useEffect(() => {
        if (numberOfBadActions === 3) {
            console.log('Use your head!')
            setNumberOfBadActions(0)
        }
    }, [numberOfBadActions])

    const doBadAction = () => {
        setNumberOfBadActions(numberOfBadActions => numberOfBadActions + 1)
    }

    return [numberOfBadActions, doBadAction]
}

When we need to share logic between 2 functions, we extract the logic to a third function. The same thing is applied when we want to share logic between React components because they are functions and Hook is also a function.

I've just extracted all the code that we want to share to a custom Hook named useYourHead. We need to think about what arguments this function should accept and what it should return as custom Hook is just a normal function. In our case, useYourHead accepts the initial number of bad actions and return numberOfBadActions as well as doBadAction

• Step 3: Use our custom Hook

const Zack = () =>  {

    const [numberOfBadActions, doBadAction] = useYourHead(0)

    return (
        <div>
            <p>Number of bad actions: {numberOfBadActions}</p>
            <button onClick={doBadAction}>Do bad action</button>
        </div>                 
    )
}

export default Zack

const Cody = () =>  {

    const [numberOfBadActions, doBadAction] = useYourHead(0)

    return (
        <div>
            <p>Number of bad actions: {numberOfBadActions}</p>
            <button onClick={doBadAction}>Do bad action</button>
        </div>                 
    )
}

export default Cody

3. Conclusion:

🚀 Hooks help us to inject reusable logic to React components without creating HOCs. As you can see, we don't have to deal with the issue of Wrapper Hell or the problem of passing down props through many component layers. 👏👏👏

Here are some good resources for you:

🙏 💪 Thanks for reading!

Please leave your comments below to let me know what do you think about this article

✍️ Written by

Huy Trinh 🔥 🎩 ♥️ ♠️ ♦️ ♣️ 🤓

Software developer | Magic lover

Say Hello 👋 on

✅ Github

✅ LinkedIn

✅ Medium

Why React Hooks (Part I: Complicated lifecycles)

TrinhDinhHuy — Sun, 25 Aug 2019 14:26:34 +0000

Prerequisite: Basic knowledge about React

In this post, we are going to talk about one in million reasons why we should all start to learn and use Hooks even though fishing is not our hobby 🐟 🎣.

Hey Siri, set timer for 5 minutes 😋

If you have never tried Hooks or heard of it before, stay with me for 5 mins and you can immediately recognize the first important benefit of Hooks 🥇.

I have started to use React hooks for about a month and it is a real game-changer. One clear benefit of Hooks is that it helps us remove redundant complicated React lifecycles.

Didn’t you see the no-fishing sign, son?

Me: I’m not fishing, sir. ....

😎 Let's how it works in action

Our task today is simply to subscribe the user to a radio channel 📻.

1. Class component

For this simple task, we will use the componentDidMount lifecycle

class Radio extends React.Component {
    state = {channelId: 1}

    componentDidMount() {
        subscribeToRadio(this.state.channelId)
    }

    ...
}

One channel is kind of boring 🙃

Let's allow users to jump to their favorite channels by clicking the button. For this, we need to unsubscribe from the previous channel before subscribing to the new one, componentDidUpdate should be the right place to do this

class Radio extends React.Component {

    ...

    componentDidUpdate(prevProps, prevState) {
        if (prevState.channelId !== this.state.channelId) {

            unsubscribeRadio(prevState.channelId)

            subscribeToRadio(this.state.channelId)
        }
    }

    changeChannel = () => {
        const id = randomId()
        this.state({channelId: id})
    }

    render() {

        return (
                <div>
                    <p>Current channel: ${channelId}</p>
                    <button onClick={this.changeChannel}>Change channel</button>
                </div>
            )
    }
}

Last but not least, we have to unsubscribe to the channel when the user stops listening. We will do this in componentWillUnmount

class Radio extends React.Component {

    ...

    componentWillUnmount() {
        unsubscribeRadio(this.state.channelId)
    }
}

So, for this dead simple radio subscribing task, we still need 3 lifecycles in total:

componentDidMount
componentDidUpdate
componentWillUpdate

If you add more and more features, I assume it has some side-effects, to your app, these features would be grouped by lifecycle methods instead of by side-effect. You will end up stacking up logics all across these lifecycle methods.

🤨 🧐 😕

Imagining when you have a bug 🐛, you need to go through 3 different places to find and fix it. You have to play Three-bug Monte game to
find that bug and I bet you all know how difficult it is to win that kind of game 🤦‍

2. Function component with Hooks

🔥 Hooks come to rescue

Hooks are a new addition in React 16.8. They let you use state and other React features without writing a class.

Let's see how Hook does to achieve the same result. To use Hooks, we need to convert the class component above to a functional component. We can create a super simple component in the following way:

const Radio = () => {
    const [channelId, setChannelId] = React.useState(1)

    React.useEffect(() => {
        subscribeToRadio(channelId)

        return () => unsubscribeRadio(channelId) 
    }, [channelId])

    const changeChannel = () => {
           const id = randomId()
           setChannelId(id)
    }

    return (
        <div>
            <p>Current channel: ${channelId}</p>
            <button onClick={changeChannel}>Change channel</button>
        </div>
    )

}

😲 Wow, It's magic. How do you do that?

React.useState and React.useEffect are React Hooks that helps you achieve the same results as you did with lifecycles. Even though you might not totally clear on those above Hooks, I bet the function names might give you some hints, and you can still immediately feel that Hooks make the code much cleaner and simpler.

As you can see, all the logics are concentrated in 1 Hook instead of 3 places like before. It is easier to debug. If you want to remove the feature, all you need is to delete the related effect.

💪 Let's break it down, together.

• useState

useState is a Hook that helps us manage local state in function component.

const Radio = () => {
    const [channelId, setChannelId] = React.useState(1)

    const changeChannel = () => {
        const id = randomId()
        setChannelId(id)
    }

    ...
}

The useState Hook accepts initial state as its argument. In the code above, 1 is the initial value for channelId.

This Hook returns an array which contains 2 variables where the first one is the current state and the second one is a function that allows us to update state. We are using array destructuring [channelId, setChannelId] and you can name them whatever you want

• useEffect

React.useEffect lets us perform side effects in function component

const Radio = () => {

    const [channelId, setChannelId] = React.useState(1)

    React.useEffect(() => {
        subscribeToRadio(channelId)
    }) 

    ...   
}

In this effect, we perform the radio channel subscription. By default, our effect will run after every component's rendering and updating.

However, that's actually not what we want, if we only need to perform this effect only once after the first render (componentDidMount), we need to pass an empty array as a second optional argument of useEffect Hook. An empty array means that this effect depends on nothing, so it will only run on the mount (and unmount if you return a clean-up function)

const Radio = () => {

    const [channelId, setChannelId] = React.useState(1)

    React.useEffect(() => {
        subscribeToRadio(channelId)
    }, []) 

    ...   
}

Additionally, we also need to perform the effect after every time the channelId state changes (when the user clicks the button). We will tell the effect to do that by passing channelId to the array. Remember what you put here in the array is what the effect will depend on. The good news is, you can put multiple variables to this array!!

const Radio = () => {

    const [channelId, setChannelId] = React.useState(1)

    React.useEffect(() => {
        subscribeToRadio(channelId)
    }, [channelId]) 

    ...   
}

The effect will determine when channelId changes by comparing the current channelId value with the previous channelId value (using shallow comparison ===).

If those values are unchanged, React would skip the effect 😙. It's the same when we use componentDidUpdate lifecycle to compare
this.state.channelId and prev.state.channelId

Note: It uses SHALLOW equality instead of deep comparison

Lastly, we will unsubscribe to 📻 when user changes the channel

const Radio = () => {

    const [channelId, setChannelId] = React.useState(1)

    React.useEffect(() => {
        subscribeToRadio(channelId)

        return () => unsubscribeRadio(channelId) 

    }, [channelId]) 

    ...   
}

The effect returns a function known as the clean-up function.

When using class component, we have to split this logic to 2 components componentDidUpdate and componentWillUnmount

Our effect will not only run when first render but also every update (when channelId changes), therefore, the clean-up function will be called
each time before the next render

3. Conclusion:

One benefit of Hooks is that it makes your React app 90% cleaner by removing the complicated lifecycles.

It helps us keep things together, group our app features by side-effect rather than spread them into different lifecycle methods

Feel the need for learning Hooks now, here are some good resources for you:

🙏 💪 Thanks for reading! Brace yourself, part II is coming

Please leave your comments below to let me know what do you think about React Hooks

✍️ Written by

Huy Trinh 🔥 🎩 ♥️ ♠️ ♦️ ♣️ 🤓

Software developer | Magic lover

Say Hello 👋 on

✅ Github

✅ LinkedIn

✅ Medium

My summer projects with React and NodeJs

TrinhDinhHuy — Mon, 12 Aug 2019 04:58:39 +0000

Here are React and Nodejs projects that I built with my friend during the summertime. It's all very exciting as well as a great learning experience.

I learned a lot while working on these projects

Check it out!

React with Redux-observable + Styled-component:

https://github.com/vinhlee95/awesome-react-typescript-boilerplate/tree/feature/reduxObservable

React with Redux-thunk + Sass:

https://github.com/vinhlee95/awesome-react-typescript-boilerplate/tree/develop

Nodejs:

https://github.com/HuyAms/awesome-node-boilerplate

DEV Community: TrinhDinhHuy

Prettier and ESLint Automation Cheat Sheet

Why

Setup

🛠 1. Prettier

⚒️ 2. ESLint

❓️ QA:

🛡 3. Validate script

🔭 4. Husky

🔬 5. Lint-staged

🎁 6. Stylelint (Bonus)

Resources

Improve knowledge sharing in your organization- Part II: Internal blog

Benefits

1. All knowledge in one place

2. Create a sharing culture

3. Sharing is the best way of learning

4. We can see what others are doing

Q&A.

1. Everyone knows everything I know.

2. What can I share?

3. It takes time to write a blog

Related posts

Time for discussion

Improve knowledge sharing in your organization - Part I: Motivation

1. 🏋️‍♂️ We don't have a good overview of what people have.

2. 🏋️‍♂️ We research the same things over and over again.

3.🏋️‍♂️ It's hard to search for and maintain materials.

4. 🏋️‍♂️ It's hard to learn across different competencies.

Other places we might share our knowledge

1. Slack/Discord

2. Talk/Workshop

3. Pair programming

A possible solution that may fill the gap

Time for discussion

10 tips to improve readability in Javascript

1. Log level and semantic methods

2. Avoid negative names for boolean variables

3. Avoid flag params

4. Use guard clauses

5. Make code self-explanatory

6. Make impossible states impossible

7. Use objects for long argument lists

8. Use Object.assign for defaults

9. Replacing switch statements with Object literals

10. Avoid Hasty Abstractions

Resource

What you may not know about the Error Boundary

1. What's wrong?

2. Try - catch

Error Boundary

⭐ What is this?

⭐ Get better

⭐ Recovery

3. A vaccine with react-error-boundary:

4. Conclusion:

🙏 💪 Thanks for reading!

✍️ Written by

Immer - Javascript Immutability the happy way

1. Immutability in Javascript

⭐ Spread operator

⭐ ImmutableJS

2. Immer in Javascript

3. Immer in React:

🔥 Immer with Producer in Redux State

🔥 Immer with Curried Producer in Redux State

🔥 Immer in Component State

4. Conclusion:

🙏 💪 Thanks for reading!

✍️ Written by

Introduction to React.memo, useMemo and useCallback

Prerequisite: Basic knowledge about React

1. What is React.memo

2. useMemo and useCallback

🍀 useMemo

🍀 useCallback

3. Conclusion:

🙏 💪 Thanks for reading!

✍️ Written by

Introduction to useRef Hook