Forem: Shivam Jha

A neat little trick to avoid useEffect in React

Shivam Jha — Mon, 17 Jul 2023 09:16:47 +0000

Problem

I came across a peculiar problem once. For the sake of this article, let's go with this contrived example:

I have a component MyDumbComponent.tsx and it receives an id with initial state value and uses that state to fetch some data.
That state can also be manipulated inside same component:

import { useEffect, useState } from 'react'
import todos from '../data/todos.json'

type Unpacked<T> = T extends (infer U)[] ? U : T

export default function MyDumbComponent({ initialId }: { initialId: number }) {
  const [id, setId] = useState(initialId)
  const [todoData, setTodoData] = useState<Unpacked<typeof todos> | null>(null)

  useEffect(() => {
    const allTodos = todos
    const selectedTodo = allTodos.find(todo => todo.id === id) ?? null
    setTodoData(selectedTodo)
  }, [id])

  return (
    <>
      <div>
        <code>
          <pre>{JSON.stringify(todoData, null, 2)}</pre>
        </code>
      </div>
      <small>Child id: {id}</small>
      <br />
      <br />
      <button onClick={() => setId(prev => prev + 1)}>+</button>
      <button onClick={() => id > 1 && setId(prev => prev - 1)}>-</button>
    </>
  )
}

When I clicked on + and - button, it would change the id and will fetch a new todo detail and show it to user.
See Code example demo

This worked perfectly fine and as expected. The issue came when I wanted to update the id(props) in parent.
My dumb common sense would say it should also re-render. But to my suprise it didn't. Here I updated the state:

import { useState } from 'react'
import './App.css'
import MyDumbComponent from './components/MyDumbComponent'

function App() {
  const [count, setCount] = useState(1)

  return (
    <div>
      <p> Parent state variable: {count} </p>
      <button onClick={() => setCount(c => c + 1)}>
        Increment parent state
      </button>
      <br /> <br />
      <br />
      <MyDumbComponent initialId={count} />
    </div>
  )
}

export default App

Here it can be seen React does not 'reload' child component if the prop is used as an initial value for state, even when the prop gets changed

At first, it can be unintuitive. The reason is that React updates a component when it's state changes or it's props changes.
If React just throw away and child and re-make a new one everytime one of it's props gets changed, it would also have to create new DOM nodes, create new ones, and set those.
These can be expensive, specially if the props change frequently or has a large number of such changing props. All of that is expensive and slow. So, React will re-use the component that was there since it's the same type and at the same position in the tree.

Using useEffect as a state updater

I am guilty of using a second effect in this scenario😅
It would like: Hmm.. so we need to do something based on when the prop is changed.. what gets fired when the prop changed... useEffect with that prop in dependency!!
So, I would add this effect after the 1st one(imo the first useEffect should be relaced with react-query or some other data fetching lib, too).
But none-the-less, this is how that would go:

useEffect(() => {
  // Changing children's state whenever our prop `initialId` changes
  setId(initialId)
}, [initialId])

Here it can be seen this appraoch of using an useEffect (tongue-twister, right?) to update the vale of state initialized with some prop works

But this solution can be better. The useEffect updated the value of state in 2nd render.
Also, it is a good rule of thumb to prevent using useEffect as long as one can. I have noticed this increases readability and prevent some bugs with not-very-cared use of useEffect.
This advice has helped me remembering this: useEffect should only be used when an external service / something outside the React paradigm (like custom listeners) need to be integrated with React.
So useEffect can be thought of as useSyncronise

Solution: using Keys to "reload" a React Component

So, what is the way? Keys to the rescue!!🔑 If a component has a key and it changes, React skips comparion and makes new fresh component
So you can consider Keys as an "identity" or source of truth, if you will, for a component. Hence, if the Key changes, the component must be reloaded from scratch.
This is the same reason you need keys while rendering a list, so that React can differentiate you list items when (if) their position / order changes within that list.

So, in our case, we can just pass the key to child component and it will be recreated from scratch:

import { useState } from 'react'
import './App.css'
import MyDumbComponent from './components/MyDumbComponent'

function App() {
  const [count, setCount] = useState(1)

  return (
    <div>
      <p> Parent state variable: {count} </p>
      <button onClick={() => setCount(c => c + 1)}>
        Increment parent state
      </button>
      <br /> <br />
      <br />
      <MyDumbComponent key={count} initialId={count} />
    </div>
  )
}

export default App

Conveniently, I found that the new React docs has an article on resetting state with Keys

Further Read:

What the hell are React Server Components ?

Shivam Jha — Sun, 25 Dec 2022 20:05:00 +0000

Introduction

React Server Components run only on the server. The "only" part is important here. They are designed to leverage your servers better, as described in this rfc published back around October 2022. You can think of them as Normal React Components, but that they only gets executed on server, and then they are sent to the client.

Normal React Components (when Server Rendered) are first "rendered" on the server into HTML and sent to the client (browser). Later, React adds interactivity to them (attaching event listeners to DOM elements). This process is called Hydration

In case of React Server Components, the execution process happens at the server. So, you can think like "hydration" of React Server Components happen only in the Server, the components get rendered into HTML and are sent to the client. And since, they are executed on the server, there is no need for Hydration on the client, and hence they ship without increasing your bundle side

Here is a very good visual representation for you to understand the difference between Server Side Rendering and React Server Components (Credit: @shuding_):

Server Side Rendering

Sorry, your browser doesn't support embedded videos, but don't worry, you can download it and watch it with your favorite video player!

React Server Components

Sorry, your browser doesn't support embedded videos, but don't worry, you can download it and watch it with your favorite video player!

When I should use React Server Components ?

One of the main use cases of RSC(s) is that you can use a large-size library (like for markdown or for date formatting, etc.) in your server, while having zero impact on your bundle size.

  import Foo from 'my-heavy-library'

  // Component that consumes Foo
  function Bar() {
    // ...Do something
  }

  // Same library, but with Server Components, zero bundle size
  import Foo from 'my-heavy-library'

  // Same component
  function Bar() {
    // ...Do something
  }

At other times, you might want to use env variables to access some keys, or do data fetching from your DB. You can do all that with RSC, without leaking anything in the browser source. (Well, you could do the same thing with SSR). As a general rule of thumb, if you want to use Server Resources directly, and don't want them to leak on the client, you can fetch data inside Server Components.

  async function getData() {
    const res = await fetch('https://api.example.com/...', {
      key: process.env.MY_SECRET_KEY,
    })
    // The return value is *not* serialized
    // You can return Date, Map, Set, etc.

    // Recommendation: handle errors
    if (!res.ok) {
      // ...
    }

    return res.json()
  }

  // Server Component
  export default async function Page() {
    const data = await getData()

    return <main></main>
  }

Using RSC, you can make sure that there are no Client Network Waterfalls. (The issue when JavaScript needs to be downloaded before a component can even start fetching data - If that component is nested deep in the component tree and parent component needs some data, then data fetching cannot even start before the child is rendered if traditional client-side rendering is used). Some libraries like Tanstack Query and React Router makes this easier by prefetching data. But still, in case of client-only rendering, you cannot fetch data before your JavaScript is downloaded.

When not to use Server Components ?

Server components cannot have any interactivity (onClick, onScroll, etc.) and can only be used for generating plain HTML stuff. For interactivity, you have to use what are now called Client Components.
Server Components cannot have state (useState) or use Side Effects (useEffect, etc). (Since the cannot have interactivity). Or custom hooks that depend on combination of state and effects.
Since they run on server, and server only, they cannot use browser APIs (like localStorage, etc.)

For a full comparison, check out Next.js docs for app directory

Okay, how do I use them in my app ?

Back in October 2022, Next 13 was released with support for Server Components. You can check out beta Next.js Docs if you want to try out RSC in your existing Next.js Applications. It is still experimental (at the time of writing this blog)
In case of Remix, seems they are not transitioning yet to RSC. Checkout this blog explaining React Server Components and Remix. Btw, Remix already solved the problems that RSC solves. With Remix Loaders, you can fetch data in the Server, and this will be run only on the server, without being shipped to the client. Components server-rendered by Remix can have interactivity (in terms of state and side-effects). Also, Remix comes with built-in mechanism for de-duping requests, handling race conditions & fetch cancellations

useEffect firing twice in React 18

Shivam Jha — Sat, 30 Jul 2022 18:22:00 +0000

Gist

Acoording to React 18 Changelog:

In the future, React will provide a feature that lets components preserve state between unmounts. To prepare for it, React 18 introduces a new development-only check to Strict Mode. React will automatically unmount and remount every component, whenever a component mounts for the first time, restoring the previous state on the second mount. If this breaks your app, consider removing Strict Mode until you can fix the components to be resilient to remounting with the existing state.

So, in short, When Strict Mode is on, React mounts components twice (in development only!) to check and let you know it has bugs. This is in development only and has no effect in code running in production.

If you just came here to "know" why your effects are being called twice that's it, that's the gist. You can spare reading this whole article, and go fix your effects
However, you can stay here and know some of the nuances.

But first, what is an effect?

According to beta react docs:

Some components need to synchronize with external systems. For example, you might want to control a non-React component based on the React state, set up a server connection, or send an analytics log when a component appears on the screen. Effects let you run some code after rendering so that you can synchronize your component with some system outside of React.

The after rendering part here is quite important. Therefore, you should keep this in mind before adding an effect to your component. For example, you might be setting some state in an effect based on a local state or a prop change.

function UserInfo({ firstName, lastName }) {
  const [fullName, setFullName] = useState('')

  // 🔴 Avoid: redundant state and unnecessary Effect
  useEffect(() => {
    setFullName(`${firstName} ${lastName}`)
  }, [firstName, lastName])

  return <div>Full name of user: {fullName}</div>
}

Just don't. Not only it is unnecessary, but it will cause an unnecessary second re-render when the value could've been calculated during render

function UserInfo({ firstName, lastName }) {
  // ✅ Good: calculated during initial render
  const fullName = `${firstName} ${lastName}`

  return <div>Full name of user: {fullName}</div>
}

"But what if calculating some value during a render is not as cheap as our fullName variable here ?" Well, in that case, you can memoize an expensive calculation. You still don't have any need to use an Effect here

function SomeExpensiveComponent() {
  // ...

  const data = useMemo(() => {
    // Does no re-run unless deps changes
    return someExpensiveCalculaion(deps)
  }, [deps])

  // ...
}

This tells React to not re-calculate data unless deps changes. You only need to do this even when someExpensiveCalculaion is quite slow (say takes ~10 ms to run). But it's up to you. First see is it fast enough without a useMemo then build up from there. You can check the time it takes to run a piece of code using console.time or performance.now:

console.time('myBadFunc')
myBadFunc()
console.timeEnd('myBadFunc')

You can see log like myBadFunc: 0.25ms or so. You can now decide whether to use useMemo or not. Also, even before using React.memo, you should first read this awesome article by Dan Abramov

What is useEffect

useEffect is a react hook that lets you to run side effects in your components. As discussed previously, effects run after a render and are caused by rendering itself, rather than by a particular event. (An event can be a user icon, for example, clicking a button). Hence useEffect should be only used for synchronization since it is not just fire-and-forget. The useEffect body is "reactive" in the sense whenever any dependencies in the dependency array change, the effect is re-fired. This is done so that the result of running that effect is always consistent and synchronized. But, as seen, this is not desirable.

It can be very tempting to use an effect here and there. For example, you want to filter a list of items based on a specific condition, like "cost less than ₹500". You might think to write an effect for it, to update a variable whenever the list of items changes:

function MyNoobComponent({ items }) {
  const [filteredItems, setFilteredItems] = useState([])

  // 🔴 Don't use effect for setting derived state
  useEffect(() => {
    setFilteredItems(items.filter(item => item.price < 500))
  }, [items])

  //...
}

As discussed, it is inefficient. React will be needing to re-run your effects after updating state & calculating and updating UI. Since this time we are updating a state (filteredItems), React needs to restart all of this process from step 1! To avoid all this unnecessary calculation, just calculate the filtered list during render:

function MyNoobComponent({ items }) {
  // ✅ Good: calculating values during render
  const filteredItems = items.filter(item => item.price < 500)

  //...
}

So, rule of thumb: When something can be calculated from the existing props or state, don't put it in state. Instead, calculate it during rendering. This makes your code faster (you avoid the extra “cascading” updates), simpler (you remove some code), and less error-prone (you avoid bugs caused by different state variables getting out of sync with each other). If this approach feels new to you, Thinking in React has some guidance on what should go into the state.

Also, you don't need an effect to handle events. (For example, a user clicking a button). Let's say you want to print a user's receipt:

function PrintScreen({ billDetails }) {
  // 🔴 Don't use effect for event handlers
  useEffect(() => {
    if (billDetails) {
      myPrettyPrintFunc(billDetails)
    }
  }, [billDetails])

  // ...
}

I am guilty of writing this type of code in past. Just don't do it. Instead, in the parent component (where you might be setting billDetails as setBillDetails(), on a user's click of button, just do yourself a favor and print it there only):

function ParentComponent() {
  // ...

  return (
    // ✅ Good: useing inside event hanler
    <button onClick={() => myPrettyPrintFunc(componentState.billDetails)}>
      Print Receipt
    </button>
  )

  // ...
}

The code above is now free of bugs caused by using useEffect in the wrong place. Suppose your application remembers the user state on page loads. Suppose user closes the tab because of some reason, and comes back, only to see a print pop-up on the screen. That's not a good user experience.

Whenever you are thinking about whether code should be in an event handler or in useEffect, think about why this code needs to be run. Was this because of something displayed to screen, or some action (event) performed by the user. If it is latter, just put it in an event handler. In our example above, the print was supposed to happen because the user clicked on a button, not because of a screen transition, or something shown to the user.

Fetching Data

One of the most used use cases of effects in fetching data. It is used all over the place as a replacement for componentDidMount. Just pass an empty array to array of dependencies and that's all:

useEffect(() => {
  // 🔴 Don't - fetching data in useEffect _without_ a cleanup
  const f = async () => {
    setLoading(true)
    try {
      const res = await getPetsList()
      setPetList(res.data)
    } catch (e) {
      console.error(e)
    } finally {
      setLoading(false)
    }
  }

  f()
}, [])

We have all seen and probably written this type of code before. Well, what's the issue?

First of all, useEffects are client-side only. That means they don't run on a server. So, the initial page rendered will only contain a shell of HTML with maybe a spinner
This code is prone to errors. For example, if the user comes back, clicks on the back button and then again re-opens the page. It is very much possible that the request that the first fired before the second one may get resolved after. So, the data in our state variable will be stale! Here, in the code above, it may not be a huge problem, but it is in the case of constantly changing data, or for eample querying data based on a search param while typing in input; it is. So, fetching data in effects leads to race conditions. You may not see it in development, or even in production, but rest assured that many of your users will surely experience this.
useEffect does not take care of caching, background updates, stale data, etc. which are necessary in apps that are not hobby.
This requires a lot of boilerplate to write by hand, and hence is not easy to manage and sustain.

Well, does that mean any fetching should not happen in an effect, no:

function ProductPage() {
  useEffect(() => {
    // ✅ This logic should be run in an effect, because it runs when page is displayed
    sendAnalytics({
      page: window.location.href,
      event: 'feedback_form',
    })
  }, [])

  useEffect(() => {
    // 🔴 This logic is related to when an event is fired,
    // hence should be placed in an event handler, not in an effect
    if (productDataToBuy) {
      proceedCheckout(productDataToBuy)
    }
  }, [productDataToBuy])

  // ...
}

The analytics request made is okay to be kept in useEffect, since it will fire when the page is displayed. In Strict Mode, in development in React 18, useEffect will fire twice, but that is fine. (See here how to deal with that)

In many projects, you can see effects as a way of syncing queries to user inputs:

function Results({ query }) {
  const [res, setRes] = useState(null)

  // 🔴 Fetching without cleaning up
  useEffect(() => {
    fetch(`results-endpoint?query=${query}}`).then(setRes)
  }, [query])

  // ...
}

Maybe this seems opposite to what we discussed previously: to put fetching logic in an event handler. However, here the query may come from any source(user input, url, etc.) So, the results need to be synced with the query variable. However, consider the case we discussed before that, the user may press the back button and then forward button; then the data in res state variable may be stale or consider the query coming from user input and user typing fast. The query might change from p to po to pot to pota to potat to potato. This might initiate different fetches for each of those values, but it is not guaranteed that they will come back in that order. So, the results displayed may be wrong (of any of the previous queries). Hence, cleanup is required here, which ensures that results shown are not stale, and prevents race conditions:

function Results({ query }) {
  const [res, setRes] = useState(null)

  // ✅ Fetching with cleaning up
  useEffect(() => {
    let done = false

    fetch(`results-endpoint?query=${query}}`).then(data => {
      if (!done) {
        setRes(data)
      }
    })

    return () => {
      done = true
    }
  }, [query])

  // ...
}

This makes sure that only the latest response from all responses is accepted.
Just handling race conditions with effects might seem like a lot of work. However, there is much more to data fetching such as caching, deduping, handling state data, background fetches, etc. Your framework might provide an efficient in-built data fetching mechanisms than using useEffect.

If you don't want to use a framework, you can extract all the above logic to a custom hook, or might use a library, like TanStack Query (previously known as useQuery) or swr.

So Far

useEffect fires twice in development in Strict Mode to point out that there will be bugs in production.
useEffect should be used when a component needs to synchronize with some external system since effects don't fire during rendering process and hence opt out of React's paradigm.
Don't use an effect for event handlers.
Don't use effect for derived state. (Heck, don't even use the derived state as long as possible, and calculate values during render).
Don't use effect for data fetching. If you are in a condition where you absolutely cannot avoid this, at least cleanup at the end of the effect.

Credits:

Much of the content above is shamelessly inspired from:

Beta React Docs
Dan Abramov's tweets

Liked it? Checkout my blog for more or Tweet this article

Batching in React

Shivam Jha — Sun, 01 May 2022 04:52:30 +0000

One might think that React's useState hook is the simplest hook. Yet, there are some complexities.

What is batching ?

Batching is when multiple calls to setState are grouped into only one state update

function App() {
  const [count, setCount] = useState(0);
  const [flag, setFlag] = useState(false);

  useEffect(() => {
    // only output once per click
    console.log({ count, flag });
  }, [count, flag]);

  const handleClick = () => {
    // Here, react will re-render only once
    // Hence, the state updates are `batched`
    setCount(c => c + 1);
    setFlag(f => !f);
  };

  return (
    <div className='App'>
      <button onClick={handleClick}>Click Me!</button>
      <h3 style={{ color: flag ? 'blue' : 'black' }}>Count: {count}</h3>
    </div>
  );
}

✅ See demo (batching inside event handlers) (Note on click of button, both count and flag changes, but only one console output)

Why Batching ?

Great for performance, since avoids un-necessary re-renders.
Prevents any component from rendering "half-applied" state updates, which may lead to bugs.

Inconsistent Batching Behavior

However, React was (more about that later) not consistent about batching. For example, in an async function / promise based API,
React would not batch the updates & independent updates would happen (performing two setState calls).

// little async function
const sleep = () => new Promise(resolve => setTimeout(resolve, 200));

export default function App() {
  const [flag, setFlag] = useState(true);
  const [count, setCount] = useState(0);

  const handleClick = async () => {
    // mimicing some async call
    // (ex, fecthing data from server, etc.)
    await sleep();

    setFlag(f => !f);
    setCount(c => c + 1);
  };

  useEffect(() => {
    // in this case, two console logs can be seen
    // since `setState` is called inside an asynchronous function
    // So,  React would not batch the updates, and perform two independent updates.
    console.log({ count, flag });

    // whenever `flag` or `count` changes, do somethig!
  }, [count, flag]);

  return (
    <>
      <h2>React's Batching Behavior while inside async callbacks</h2>;
      <p>Count: {count}</p>
      <button
        onClick={handleClick}
        style={{ backgroundColor: flag ? 'orange' : 'blue', color: '#fff' }}
      >
        Click me!
      </button>
    </>
  );
}

⚠️ See demo (not batching updates inside async function) (Note on click of button, two lines get printed on console)

Forced batching in async functions

To force setState to batch updates out of event handlers, unstable_batchedUpdates (an undocumented API) can be used:

import { unstable_batchedUpdates } from 'react-dom';

unstable_batchedUpdates(() => {
  setCount(c => c + 1);
  setFlag(f => !f);
});

This is because React used to only batch updates during a browser event (like click), but here we're updating the state after the event has already been handled (in aync function):

For demo, see React 17: forced batching outside of event handlers

Opt out of automatic batching

Some code may depend on reading something from the DOM immediately after a state change. For those use cases, ReactDOM.flushSync can be used to opt out of batching

Continuing with our previous example,

function App() {
  const [count, setCount] = useState(0);
  const [flag, setFlag] = useState(false);

  useEffect(() => {
    console.log({ count, flag });
  }, [count, flag]);

  const handleClick = () => {
    // setCount((c) => c + 1);

    // Force this state update to be synchronous.
    ReactDOM.flushSync(() => setCount(c => c + 1));
    // By this point, DOM is updated.

    setFlag(f => !f);
  };

  return (
    <div className='App'>
      <button onClick={handleClick}>Click Me!</button>
      <h3 style={{ color: flag ? 'blue' : 'black' }}>Count: {count}</h3>
    </div>
  );
}

See ⚠️ ReactDOM.flushSync: Opt out of automatic batching in event handlers

However, ReactDOM.flushSync is not common & should be sparingly used.

flushSync flushes the entire tree and actually forces complete re-rendering for updates that happen inside of a call, so you should use it very sparingly. This way it doesn’t break the guarantee of internal consistency between props, state, and refs.

To read more about async behavior of this API & why setState is asynchronous, check out this awesome discussion RFClarification: why is setState asynchronous? #11527

Automatic Batching in React 18

React 18 includes some out-of-the-box improvements with ReactDOMClient.createRoot,
which includes support for automatic batching

Starting in React 18, all updates will be automatically batched, no matter where they originate from.

So, call to setState inside of event handlers, async functions, timeouts or any function will batch automatically (same as inside react events)
This will result in less rendering, and therefore better performance in react applications

function handleClick() {
  fetchSomething().then(() => {
    // React 18 and later DOES batch these:
    setCount(c => c + 1);
    setFlag(f => !f);
    // React will only re-render once at the end (that's batching!)
  });
}

Note that this automatic batching behavior will only work in React 18 with ReactDOM.createRoot
React 18 with legacy ReactDOM.render keeps the old behavior
To read more about Automatic batching in React 18, see Automatic batching for fewer renders in React 18 #21

Want to read it on my blog ? Checkout this blog post

Changing caret color with CSS

Shivam Jha — Wed, 05 Jan 2022 19:40:07 +0000

With all of the fun stuff that you can do in CSS, you can even change the caret color: that's right.
Caret is a thin blinking line that appears inside inputs, textboxes, etc.

Just with one line of CSS:

.selector {
  caret-color: red;
}

And the support is basically universal too! (~94% at the time of writing this post)

Best way (one liner) to sort an array by string alphabetically

Shivam Jha — Sun, 02 Jan 2022 12:44:19 +0000

Source:
Twitter Post

Next.js conf 2021!

Shivam Jha — Thu, 14 Oct 2021 08:33:25 +0000

Next JS Conf Ticket

Hacktoberfest 2021 is here!

Shivam Jha — Sat, 02 Oct 2021 07:35:31 +0000

Following are links to get you started:

Hacktoberfest Website
Register for Hacktoberfest 2021
Hacktoberfest 2021 - Quality Standards
Values
Hacktoberfest 2021 - Participation
FAQs
A great dev post summing up Hacktoberfest 2021

Completed 4 PRs in Hacktoberfest 2020

Shivam Jha — Fri, 09 Oct 2020 06:16:25 +0000

Hey, check out my repo, and contribute!
https://github.com/shivamjjha/Evcs_OP/