DEV Community: Yehonatan Paripsky

Using Effects Effectively in React: Stop Misusing useEffect Once and For All

Yehonatan Paripsky — Wed, 17 Sep 2025 22:41:11 +0000

"Effects specifically are still hard to understand and are the most common pain point we hear from developers."

Quoted from the last blog post in the React documentation site.

To this day, one of the most difficult concepts to wrap your head around as a React developer is using useEffect properly.
It got so bad that even AI uses useEffect incorrectly, leading to even more misuse.
In this post I'll talk about how we got to this point, and how, hopefully we can get to a point where every React dev knows how to use useEffect in the way that it's meant to be used.

Component Lifecycle Hooks

Before React had hooks, components were written as classes that had a render function, a constructor to initialize state and several functions to manage the component's lifecycle, for example a componentDidMount function to run code when the component mounts to the DOM and a componentDidUpdate function to handle component state and prop updates.
This way of writing components had several drawbacks, the main one being that many times, logic had to be split across separate lifecycle hooks, for example when componentDidMount code needed to run a cleanup on unmount.

React Hooks

React 16.8 brought with it a list of hooks that created a new paradigm, instead of thinking about lifecycle hooks, developers were expected to think in terms of effects.
But what are effects in React? Effects refer to operations that occur outside a component’s rendering process, they are escape hatches from React itself and allow you to synchronize React with external systems.
The way to write these effects in code is by using the useEffect hook, that accepts an effect function that returns a cleanup function and a dependency array of variables that are used in the effect.

useEffect should be used for things like:

fetch/axios/WebSockets
Timers (setTimeout, setInterval)
Browser APIs (navigator, localStorage)

The golden rule for effects in React is: "If no external system is involved, you should generally not need an Effect."

Why Is useEffect So Difficult?

This is the original explanation for useEffect in React's legacy docs:

Basically saying:

Which was more confusing than helpful, many developers started using useEffect for running code on mount, syncing state between components, thinking it's proper usage because that's the way that lifecycle hooks worked in React class components.
Later came the new React documentation that explained useEffect properly once and for all in the "You Might Not Need An Effect" article.
But, was that enough?

In my opinion, not really.
The new docs were helpful but it was too little too late, many devs figured that they already know useEffect and skipped the new docs and even new devs might have missed these docs as they're a part of a section called "Escape Hatches", which is the last section in the docs.

Thinking In Effects

The latest React blog post says that one of the biggest reasons for confusion around useEffect is that developers tend to think of Effects from the component’s perspective (like a lifecycle), instead of the Effects point of view.

useEffect(() => {
  const connection = createConnection(serverUrl, roomId);
  connection.connect();
  return () => {
    connection.disconnect();
  };
}, [roomId]);

Many React developers read this example as "on mount and on the change of the roomId variable, connect to the chat room, and on unmount and before connecting to a different roomId, disconnect from the previous chat room" when instead you should think about this code as "I want to connect to a chat room from my component, and disconnect from the chat room when the effect is cleaned up. I connect to a chat room by its room Id so I'll provide it as a dependency in the dependency array of useEffect".
This different way of thinking about effects helps you understand how useEffect should be used properly.

AI Doesn't Get useEffect

So many React developers use useEffect improperly that we've gotten to a point where AI tools like Copilot and Cursor also misuse useEffect.
And without a review from an experienced dev that knows how to use useEffect properly, this code will end up in a git repository, which LLMs might train on, thus just making this problem worse and worse.

The Do's: Examples of what useEffect should be used for

Fetch data using useEffect:

useEffect(() => {
  fetch('/api/user')
  .then(res => res.json())
  .then(data => setUser(data));
}, []);

This is a very simplified example, a proper fetch request should handle errors, have an abort controller for canceling the request on unmount and more.

Sync a state variable to localStorage:

useEffect(() => {
  localStorage.setItem('theme', theme);
}, [theme]);

Listen to DOM events:

useEffect(() => {
  const handleScroll = () => setScrollY(window.scrollY);
  window.addEventListener('scroll', handleScroll);

  return () => window.removeEventListener('scroll', handleScroll);
}, []);

When You Do Need Effects

Fetching data (with important caveats).
Syncing state with external systems.
Subscribing to external data stores and browser APIs (though -useSyncExternalStore is preferred)

The Don'ts: Examples of improper useEffect usage

Avoid: Transforming Data for Rendering

function Form() {
  const [firstName, setFirstName] = useState('Morty');
  const [lastName, setLastName] = useState('Smith');
  const [fullName, setFullName] = useState('');

  useEffect(() => {
    setFullName(firstName + ' ' + lastName);
  }, [firstName, lastName]);

  return <span>{fullName}</span>;
}

Updating a state variable based on another variables isn't an effect, instead calculate the fullName while rendering:

function Form() {
  const [firstName, setFirstName] = useState('Morty');
  const [lastName, setLastName] = useState('Smith');

  const fullName = firstName + lastName;

  return <span>{fullName}</span>;
}

Avoid: Caching Expensive Calculations

function TodoList({ todos }) {
  const [searchTerm, setSearchTerm] = useState('');
  const [matchingTodos, setMatchingTodos] = useState(todos);

  useEffect(() => {
    setMatchingTodos(todos.filter(todo => todo.title.includes(searchTerm)));
  }, [searchTerm]);

  // render
}

Instead calculate matchingTodos as part of the render and use the useMemo hook if it's a heavy calculation, to memoize the result:

function TodoList({ todos }) {
  const [searchTerm, setSearchTerm] = useState('');
  const matchingTodos = useMemo(() => todos.filter(todo => todo.title.includes(searchTerm)), [todos, searchTerm]);

  // render
}

Avoid: Resetting State on Prop Change

function TodoList({ todos }) {
  const [searchTerm, setSearchTerm] = useState('');

  useEffect(() => {
    setSearchTerm('');
  }, [todos]);

  // render
}

Instead you should use the built in key prop to let React know that the provided todos are new todos:

function App() {
  const [todos, setTodos] = useState(todos);

  const todosKey = useMemo(() => todos.map(todo => todo.id).join(','), [todos]);

  return <TodoList todos={todos} key={todosKey} />;
}

function TodoList({ todos }) {
  const [searchTerm, setSearchTerm] = useState('');

  // render
}

If using a key isn't possible you can save a local copy of the todos and check if the prop changed in the render:

function TodoList({ todos }) {
  const [localTodos, setLocalTodos] = useState(todos);
  const [searchTerm, setSearchTerm] = useState('');

  if (todos !== localTodos) {
    setLocalTodos(todos);
    setSearchTerm('');
  }

  // render
}

Calling a setState function as part of the render tells react to perform another render immediately, skipping effects, making this a viable option when using a key just isn't possible.

Avoid: Handling User Events in Effects

function Todo({ title, isSelected, onSelect }) {
  useEffect(() => {
    if (!isSelected) return;
    toast.success(`Todo "${title}" is now selected`);
  }, [isSelected]);

  return (
    <label>
      <input type="checkbox" value={isSelected} onChange={onSelect} /> {title}
    </label>
  );
}

Instead handle the selection event in an event handler:

function Todo({ title, isSelected, onSelect }) {
  const handleSelect = (selected) => {
    onSelect(selected);
    if (!selected) return;
    toast.success(`Todo "${title}" is now selected`);
  };

  return (
    <label>
      <input type="checkbox" value={isSelected} onChange={onSelect} /> {title}
    </label>
  );
}

Avoid: Syncing State Between Parent & Child Components

function TodoList({ todos }) {
  const [selectedTodos, setSelectedTodos] = useState([]);

  return todos.map((todo) => (
    <Todo
      key={todo.id}
      title={todo.title}
      isSelected={selectedTodos.includes(todo.id)}
      onSelect={(isSelected) => {
        setSelectedTodos(
          isSelected
            ? [...selectedTodos, todo.id]
            : selectedTodos.filter((id) => id !== todo.id),
        );
      }}
    />
  ));
}

function Todo({ title, onSelectChange }) {
  const [isSelected, setIsSelected] = useState(false);

  useEffect(() => {
    onSelectChange(isSelected);
  }, [isSelected, onSelectChange]);

  return (
    <label>
      <input type="checkbox" value={isSelected} onChange={setIsSelected} />{' '}
      {title}
    </label>
  );
}

The selection state is duplicated both in the child and in the parent component, so there's no single source of truth for the selection state. Instead, move the state up to the parent:

function TodoList({ todos }) {
  const [selectedTodos, setSelectedTodos] = useState([]);

  return todos.map((todo) => (
    <Todo
      key={todo.id}
      title={todo.title}
      isSelected={selectedTodos.includes(todo.id)}
      onSelect={(isSelected) => {
        setSelectedTodos(
          isSelected
            ? [...selectedTodos, todo.id]
            : selectedTodos.filter((id) => id !== todo.id),
        );
      }}
    />
  ));
}

function Todo({ title, isSelected, onSelectChange }) {
  return (
    <label>
      <input type="checkbox" value={isSelected} onChange={onSelectChange} />{' '}
      {title}
    </label>
  );
}

When You Don’t Need Effects

Transforming Data for Rendering
Caching Expensive Calculations
Adjusting/Resetting State on Prop Change
Handling User Events
Syncing State Between Parent & Child Components

useEffect Alternative: useSyncExternalStore

If you have a custom hook that syncs to an external store where you can get the current state and listen to state changes you'll be able to use useSyncExternalStore instead of useEffect.
Let's create a useOnline hook for example:

export function useOnlineStatus() {
  const [isOnline, setIsOnline] = useState(navigator.onLine);

  useEffect(() => {
    function updateStatus() {
      setIsOnline(navigator.onLine);
    }

    window.addEventListener('online', updateStatus);
    window.addEventListener('offline', updateStatus);

    // Cleanup function
    return () => {
      window.removeEventListener('online', updateStatus);
      window.removeEventListener('offline', updateStatus);
    };
  }, []);

  return isOnline;
}

using useSyncExternalStore, we can simplify this to:

export function useOnlineStatus() {
  const isOnline = useSyncExternalStore(subscribe, getSnapshot);
  return isOnline;
}

function getSnapshot() {
  return navigator.onLine;
}

function subscribe(callback) {
  window.addEventListener('online', callback);
  window.addEventListener('offline', callback);
  return () => {
    window.removeEventListener('online', callback);
    window.removeEventListener('offline', callback);
  };
}

We don't need useState and useEffect anymore, we just use useSyncExternalStore and give it a function to subscribe to changes and a way to get the current state.

The Future Of useEffect

The team behind React are considering using the new React Compiler as a possible solution, instead of manually providing dependencies to useEffect, the compiler will auto detect dependencies for you, similar to Vue, Solid and others.
This shift will make developers think about the code written in useEffect as an actual side effect instead of thinking "if this dependency changes, run this function".

useEffect(() => {
  const connection = createConnection(serverUrl, roomId);
  connection.connect();
  return () => {
    connection.disconnect();
  };
}); // React Compiler will add these deps automatically

Conclusion

Removing unnecessary Effects makes code simpler to follow, easier to debug, faster to run, and less error-prone.
Also, if we use useEffect correctly, AI will use it properly as well and hopefully after reading this post you know when you should, and mostly shouldn't use useEffect.

Read more about useSyncExternalStore in my blogpost: https://dev.to/paripsky/build-your-own-react-state-management-library-in-under-40-lines-of-code-with-typescript-support-hji

Read "You Might Not Need An Effect" in React's docs for more in depth explanations and examples: https://react.dev/learn/you-might-not-need-an-effect

You Might Not Need Next.js

Yehonatan Paripsky — Tue, 05 Aug 2025 09:51:38 +0000

In times when the official React documentation says:

"If you want to build a new app or website with React, we recommend starting with a framework."

It's pretty understandable that any developer new to React will choose Next.js by default (It's also the first suggestion on the page).
But is Next.js really a sensible default?

React on the server

"Full-stack frameworks do not require a server.", that is what the React docs say, and it is true, Next.js and other full stack frameworks do have static exports, and React's docs do point to a page in Next.js's docs that explains this.
However, the project initialization command (also the first terminal command in the docs page) is this:

npx create-next-app@latest

This command creates a regular Next.js app with a server, so unless developers specifically research static exports, many will end up with a server even though they never wanted or needed one.

The Old Way

In a time, not that long ago, the default way to use React was create-react-app, a CLI tool that created and managed react project which were all Single Page Apps by default.
As time went on, the project stopped being maintained, became outdated, and was eventually abandoned and archived.
This leaves create-react-app projects looking for a migration path, and many developers are choosing Next.js, even when they haven't used a server before in their create-react-app projects.
Personally, I still believe SPA is the most reasonable default for new React projects.

Next.js SPA

To create a SPA with Next.js you need to edit your next.config.ts file like so:

import type { NextConfig } from 'next'

const nextConfig: NextConfig = {
  output: 'export',
}

export default nextConfig

This will generate an out folder with all of the static assets of your app (HTML, CSS, JS) that can be hosted without a server.

Next.js's docs state that there are benefits to using the SPA mode:

However, a quick look at the list of unsupported features makes it clear that SPAs aren't the primary use case for Next.js:

While you can build SPAs with Next.js, it’s not designed for it and in many cases, a simpler tool is more than enough.

Vite based SPA

Vite is a build tool for modern dev projects, and has plugins for React, Vue and more.
Vite can be used to build a Single Page App with React and is a closer alternative to create-react-app than other frameworks/tools as it is SPA by default and supports many things that create-react-app supported out of the box.
Vite is mentioned in the React docs in a page called "Build a React app from Scratch" but it's clear that the React developers believe frameworks and the server to be the way forward for React.

You Might Not Need A Server

A developer on twitter built a cool website called PatternCraft that allows users to browse and copy background patterns.
Like most new React developers, they used Next.js.

As the site gained popularity, they encountered this issue:

They've reached the free plan limits for server function calls, but, why are function calls needed for a website of this kind?
Looking through it, all of the content is static, there's no auth, and in fact, the entire list of patterns is stored in a single typescript file.
Seems like there isn't a valid reason to use a server, using Next.js was the default way and they just went with it.
Had they used Vite or Next.js's static export, they could've hosted their website for free in a static hosting site like Github Pages or Cloudflare Pages.

The Outcome

Fortunately, PatternCraft's story ends on a high note:

Which is pretty cool, they got sponsored and can continue on, but not every developer is going to get that lucky.
This case shows the importance of understanding React and the ecosystem in order to make the right choices when starting a new project.

Conclusion

You may already know the excellent React documentation section titled “You Might Not Need an Effect.”

I propose another: “You Might Not Need a Server.”

It could start like this:

Do you need a server? if the answer is "Yes" then use Next.js.
if the answer is "No", you should use Vite and consider Github Pages or Cloudflare Pages to host your Single Page Application.

Have you encountered uses of Next.js where a simple Vite SPA would suffice? Share your stories in the comments!

Check out this great intro into Server-side Events and using them with Hono.dev and React

Yehonatan Paripsky — Mon, 02 Dec 2024 16:56:55 +0000

SSE, WebSockets, or Polling? Build a Real-Time Stock App with React and Hono

Itay Ben Ami ・ Dec 2 '24

#javascript #react #webdev #node

Building a Meta Tags Scraping API in Under 40 Lines of Code

Yehonatan Paripsky — Mon, 21 Oct 2024 06:37:56 +0000

Have you ever wondered how messaging apps like Whatsapp or Telegram let you see a preview of a link that you send?

Whatsapp and Telegram url previews

In this post, we'll be building a scraping API with Deno that accepts a URL and retrieves the meta tags for it, so we can get fields like the title, description, image and more from almost any website.

For example:

curl https://metatags.deno.dev/api/meta?url=https://dev.to

will give this result

{
  "last-updated": "2024-10-15 15:10:02 UTC",
  "user-signed-in": "false",
  "head-cached-at": "1719685934",
  "environment": "production",
  "description": "A constructive and inclusive social network for software developers. With you every step of your journey.",
  "keywords": "software development, engineering, rails, javascript, ruby",
  "og:type": "website",
  "og:url": "https://dev.to/",
  "og:title": "DEV Community",
  "og:image": "https://dev-to-uploads.s3.amazonaws.com/uploads/articles/8lvvnvil0m75nw7yi6iz.jpg",
  "og:description": "A constructive and inclusive social network for software developers. With you every step of your journey.",
  "og:site_name": "DEV Community",
  "twitter:site": "@thepracticaldev",
  "twitter:title": "DEV Community",
  "twitter:description": "A constructive and inclusive social network for software developers. With you every step of your journey.",
  "twitter:image:src": "https://dev-to-uploads.s3.amazonaws.com/uploads/articles/8lvvnvil0m75nw7yi6iz.jpg",
  "twitter:card": "summary_large_image",
  "viewport": "width=device-width, initial-scale=1.0, viewport-fit=cover",
  "apple-mobile-web-app-title": "dev.to",
  "application-name": "dev.to",
  "theme-color": "#000000",
  "forem:name": "DEV Community",
  "forem:logo": "https://media.dev.to/cdn-cgi/image/width=512,height=,fit=scale-down,gravity=auto,format=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2F8j7kvp660rqzt99zui8e.png",
  "forem:domain": "dev.to",
  "title": "DEV Community"
}

pretty cool, isn't it?

Meta tags and why do we need them

Meta tags are HTML elements that are used to provide additional information about a page to search engines and other clients.
These tags typically include a name or property attribute that defines the type of information, and a content attribute that contains the value of that information. Here’s an example of two meta tags:

<meta name="description" content="The <meta> HTML element represents metadata that cannot be represented by other HTML meta-related elements, like <base>, <link>, <script>, <style> or <title>.">
<meta property="og:image" content="https://developer.mozilla.org/mdn-social-share.cd6c4a5a.png">

The first tag provides a description of the page, while the second is an Open Graph tag that defines an image to display when the page is shared on social media.

One practical application of meta tags is building a bookmark manager. Instead of manually adding the title, description, and image for each bookmark, you can automatically scrape this information from the bookmarked URL using meta tags.

Open Graph

Open Graph is an internet protocol that was originally created by Facebook to standardize the use of metadata within a webpage to represent the content of a page, it helps social networks generate rich link previews.
Read more about it here.

Why Deno?

Deno has secure defaults, meaning it requires explicit permission for file, network, and environment access, reducing the risk of security vulnerabilities.
Deno is built on web standards, uses ES Modules, and aims to use Web Platform APIs (like fetch) over proprietary APIs, making Deno code very similar to the code you'll write in the browser - but still has some spec deviation from the browser.
Deno has built-in TypeScript support, allowing you to write TypeScript code without a build step.
Deno comes with a standard library that includes modules for common tasks like HTTP servers, file system operations, and more.
Deno provides a Linter, Formatter and Test runner, allowing you to use the platform instead of relying on third party packages or tools, making it an all-in-one tool for Javascript development.
Deno provides Deno Deploy which is a scalable platform for serverless JavaScript/Typescript applications that are globally distributed, ensuring minimal latency and maximum uptime.

The API that we're building will consist of two parts, a function for fetching and parsing the meta tags, and an API server which will respond to HTTP requests.

Getting the meta tags

Let's start by going to Deno Deploy and signing in.
After signing in click on "New Playground"

This we'll give us a hello world starting point.
Now we'll add function that is called getMetaTags that accepts a url and uses the Fetch API to get the HTML of the requested URL and passes it on to a package for HTML parsing (deno-dom).
To add deno-dom to our project we can use the jsr package manager:

import { DOMParser, Element } from "jsr:@b-fuze/deno-dom";

Now we'll use the Fetch API to get the HTML as text:

  const headers = new Headers();
  headers.set("accept", "text/html,application/xhtml+xml,application/xml");
  const res = await fetch(url, { headers });
  const html = await res.text();

After getting the HTML, we can use deno-dom to parse it and then use standard DOM functions like querySelectorAll to get all the meta HTML elements, iterate on them and use getAttribute to get the name, property and content of each one of those tags:

const document = new DOMParser().parseFromString(html, "text/html");
const metaTags = document.querySelectorAll("meta");
const documentMeta = (Array.from(metaTags) as Element[])
    .reduce((acc, meta) => {
      const property = meta.getAttribute("property");
     ...

Finally, we'll also query the <title> element of the page to add it as a field in our API:

documentMeta.title ??= document.querySelector("title").textContent;

It isn't exactly a meta tag, but I think that it is a useful field, so it's going to be part of our API anyway. :)

Our final getMetaTags function should look like this:

import { DOMParser, Element } from "jsr:@b-fuze/deno-dom";

const getMetaTags = async (url: string) => {
  const headers = new Headers();
  headers.set("accept", "text/html,application/xhtml+xml,application/xml");
  const res = await fetch(url, { headers });
  const html = await res.text();
  const document = new DOMParser().parseFromString(html, "text/html");
  const metaTags = document.querySelectorAll("meta");
  const documentMeta = (Array.from(metaTags) as Element[])
    .reduce((acc, meta) => {
      const property = meta.getAttribute("property");
      const name = meta.getAttribute("name");
      const content = meta.getAttribute("content");

      if (!content) return acc;
      if (property) acc[property] = content;
      if (name) acc[name] = content;

      return acc;
    }, {} as Record<string, string>);
  documentMeta.title ??= document.querySelector("title").textContent;

  return documentMeta;
};

The server

For simplicity, I've decided to use Deno's built in http server which is just a simple Deno.serve() call.
Thanks to the fact that deno is built on web standards, we can use the built in Response object in the Fetch API to respond to requests.

Deno.serve({ port: 8000 }, async (request: Request): Promise<Response> => {
  const url = new URL(request.url);

  if (request.method === "GET" && url.pathname === "/api/meta") {
    const metaTags = await getMetaTags(url.searchParams.get("url"));
    const headers = new Headers();
    headers.set("Content-Type", "application/json");
    headers.set("Access-Control-Allow-Origin", "*");
    return new Response(JSON.stringify(metaTags), { status: 200, headers });
  }

  return new Response("not found", { status: 404 });
});

Our server parses the request url, checks if we received a GET request to the /api/meta path, and calls the getMetaTags function we created and then returns the meta tags as the response body.

We also add two headers, the first is Content-Type that is needed for the client to know the kind of data they're getting in the response, which in our case is a JSON response.

The second header is Access-Control-Allow-Origin that allows our API to accept requests from specific origins, in our case I chose "*" to accept any origin, but you might want to change it to only accept request from your frontend's origin.
Note that the CORS headers will only affect requests made by the browser, meaning the browser will block the request according to the origin that is specified in the header, but directly calling the API from a server will still be possible. Read more about CORS here.

You can now click on "Save & Deploy"

Then wait for deno deploy to deploy your code to the playground:

The url on the top right is your playground's url, copy it and add /api/meta?url=https://dev.to to see it in action, the url should look something like https://metatags.deno.dev/api/meta?url=https://dev.to
You should now see the API responding with dev.to's meta tags!

Deployment

Using Deno deploy's playground means your code is technically already deployed, it is public and can be accessed by anyone.
For a simple API like the one we're building, a single file playground can be enough, but in many cases we'd like to scale our project further, for that you can use Deno deploy's Github export to make a proper code repository for you API, with support for automatic building on new code pushes:

or from the playground's settings:

Caveats

The scraping method presented in this post only works on websites that have meta tags in the html file that’s returned from the server, meaning server rendered or prerendered sites are more likely to return proper results, single page apps can also work as long as the meta tags are set in build time and not in runtime.

Conclusion

We've demonstrated how quick and simple it is to build and deploy an API with Deno, we've gone over Meta tags, and how we can use the Fetch API, a DOM parser and Deno's built in server to build a Meta tags scraping API in under 40 lines of code.

To see the project built in this post you can check out the Deno deploy playground (You'll need to add /api/meta?url=https://dev.to to the url bar on the right to see an example response) or this github repository.

What Will You Build Next?

I hope this post has inspired you to explore the power of meta tags and Deno! Try building your own version of the API or integrate it into a project like a bookmark manager.

Got stuck, have questions, or want to show off what you built? Drop a comment below or connect with me on Twitter/X – I’d love to hear from you!

Check out my previous post about building a react state management library in under 40 lines of code here.

Build your own React state management library in under 40 lines of code - with typescript support

Yehonatan Paripsky — Tue, 21 May 2024 19:47:15 +0000

Have you ever wondered how react state management libraries are built? from solutions like redux, with a lot of boilerplate and a large bundle size to libraries like zustand or jotai that are much lighter and simpler. Today we'll build our own state management library and see the magic that happens behind the scenes.

Understanding useSyncExternalStore

React 18 introduced a new hook called useSyncExternalStore which allowes react to sync to any external store.

useSyncExternalStore(subscribe, getSnapshot, getServerSnapshot?)

Here's a breakdown of its parameters:

subscribe receives a callback as a parameter, and subscribes the callback to the external store so that it is called when the store state changes, it needs to return an unsubscribe function.
getSnapshot gets the current snapshot of the store, this snapshot must be a cached value as react compares this value on each render using Object.is(getSnapshot(), oldSnapshot), providing a new value each time will cause an infinite loop.
getServerSnapshot (optional) allows us to return a snapshot when rendering on the server, which can be helpful in certain cases where the external store or subscription source can't run on the server or needs specific handling to run on the server.

Leveraging useSyncExternalStore, we can build a minimalist store tailored to our requirements.

Why not just use React Context?

React Context is a feature in react that allows a component to pass down props to the entire component tree below it, which means that it can be used as a store and is a viable option.

React context requires some boilerplate:

const context = createContext();

const CountProvider = ({ children }) => {
  const [count, setCount] = useState(0);
  return <context.Provider value={{ count, setCount }}>{children}</context.Provider>;
};

export function App() {
  return (
    <CountProvider>
      <Outer />
      <Other />
    </CountProvider>
  );
}

Using Context a lot can lead to "Context Hell", where a lot of context providers are nested in the App component:

export function App() {
  return (
    <CountProvider>
      <AuthProvider>
        <ThemeProvider>
          <CacheProvider>
            <IntlProvider>
              <TooltipProvider>
                <UserSettingsProvider>
                  <NotificationProvider>
                    <AnalyticsProvider>
                      <Content />
                    </UserSettingsProvider>
                  </NotificationProvider>
                </AnalyticsProvider>
              </TooltipProvider>
            </IntlProvider>
          </CacheProvider>
        </ThemeProvider>
      </AuthProvider>
    </CountProvider>
  );
}

Moreover, using context can inadvertently trigger re-renders across the entire component tree, as demonstrated below:

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

  return (
    <context.Provider value={{ count, setCount }}>
      <Outer />
      <Other />
    </context.Provider>
  );
}

Using setCount from a consumer of the context will cause a re-render of the entire app (both Outer and Other will be re-rendered) because the state is set on the App component, and when it re-renders, all of it's child components are also re-rendered.

Also, using an external store can allow us to more easily sync react with external systems like http requests, with context you'll resort to using useEffect, while with an external store you can just update the store directly and the change will take effect in the subscribing components.

Building our store

Let's delve into the implementation of our store. We'll start with a basic structure and gradually enhance it based on our requirements.

import { useSyncExternalStore } from 'react';

export type Listener = () => void;

function createStore<T>({ initialState }: { initialState: T }) {
  let subscribers: Listener[] = [];
  let state = initialState;

  const notifyStateChanged = () => {
    subscribers.forEach((fn) => fn());
  };

  return {
    subscribe(fn: Listener) {
      subscribers.push(fn);
      return () => {
        subscribers = subscribers.filter((listener) => listener !== fn);
      };
    },
    getSnapshot() {
      return state;
    },
    setState(newState: T) {
      state = newState;
      notifyStateChanged();
    },
  };
}

Subscribers is an array of listeners that our store will notify on every change of the store's state.
State is the store's state which we'll update when setState is called and then notify all of the store's subscribers of the update.

To use the store in react we'll create createUseStore which is a helper that wraps createStore and useSyncExternalStore in a convenient way:

export function createUseStore<T>(initialState: T) {
  const store = createStore({ initialState });
  return () => [useSyncExternalStore(store.subscribe, store.getSnapshot), store.setState] as const;
}

Using the store

With our store in place, let's start by building a Counter component:

import React, { useState } from "react";

export function Counter() {
  const [count, setCount] = useState(0);

  const increment = () => {
    setCount(count + 1);
  };

  const decrement = () => {
    setCount(count - 1);
  };

  return (
    <div>
      <p>Count: {count}</p>
      <button onClick={increment}>Increment</button>
      <button onClick={decrement}>Decrement</button>
    </div>
  );
}

and render it three times in our app:

import React from 'react';
import ReactDOM from 'react-dom/client';
import { Counter } from './Counter.tsx';

ReactDOM.createRoot(document.getElementById('root')!).render(
  <React.StrictMode>
    <Counter />
    <Counter />
    <Counter />
  </React.StrictMode>,
);

We now see three counters in our page, clicking on Increment only increments one of the counters:

Let's make these 3 counters use the same state using our store, first we'll create useCountStore using the createUseStore helper that we've created before:

export const useCountStore = createUseStore(0);

now let's use our useCountStore hook in our counter:

import { useCountStore } from "./countStore";

function Counter() {
  const [count, setCount] = useCountStore();

  const increment = () => {
    setCount(count + 1);
  };

  const decrement = () => {
    setCount(count - 1);
  };

  return (
    <div>
      <p>Count: {count}</p>
      <button onClick={increment}>Increment</button>
      <button onClick={decrement}>Decrement</button>
    </div>
  );
}

Now our 3 counters are synced up and all of them increment together:

Thanks to the use of generics, typescript knows that count is a number and setCount is a callback that accepts a number:

Next steps

Some ideas on how our simple store can be improved and built upon:

Reducing state
Setting state is pretty direct in our store, which is convenient but we sometimes might need to handle complex logic when determening our state, that's where a reducer might help us, we can add a new dispatch function to our store:

dispatch(action) {
  state = reducer(action);
  notifyStateChanged();
},

Handling deeply nested state
Setting new state requires destructuring the existing state, which can be annoying if we have a deeply nested state, to solve that we can use immer or a similar library:

// without immer
setState({
    ...state,
    nested: {
        ...state.nested,
        sub: {
            ...state.nested.sub,
            new: true,
        }
    }
});

// with immer
import { produce } from "immer";

const nextState = produce(state, s => {
    s.nested.sub.new = true;
});
setState(nextState);

We can even add immer to our store internally, and accept a callback in setState like so:

setState((state) => {
    state.nested.sub.new = true;
    return state;
});

Conclusion

In this tutorial, we went through the steps of building a simple React state management library with TypeScript support.
By leveraging React's useSyncExternalStore hook, we built a simple yet powerful store that seamlessly integrates with React components.
Now that you've got the hang of it, you're all set to build your own tailor made state management library.

Read more about useSyncExternalStore in the react docs.

To see the implementation of the concepts discussed in this article in action, check out tinystate-react here. This library is built using the approach described in this tutorial, allowing you to dive deeper into the code and examples.