DEV Community: Shubhajit Chatterjee

Building a single active tab experience

Shubhajit Chatterjee — Tue, 05 May 2026 05:13:26 +0000

I recently had a requirement where, if a user opens the app in multiple browser tabs, only one tab can be active at a time, and the rest are locked.

Core Requirements

Here are the core requirements as I see them:

Uniquely identify each tabs
Store the active tab somewhere
If a user opens a new tab, lock it if there is already an active tab
If the active tab is closed, detect that and inform the other tabs

Sounds simple enough, doesn't it? Take a moment and think about how you'd solve this. It's more interesting than it looks.

Edge Cases

Let’s think through some edge cases:

Next active tab - If the user closes the active tab and multiple tabs are locked, which one should become active?
Stale active tab - If the user closes the browser and returns later, how do we ensure that the previously stored active tab is not considered?
Race condition - If two tabs are opened at the same time, how do you handle the race condition?

Not so simple anymore, right?

Possible Solutions

Let's explore some solutions that I came across.

Local Storage

The most obvious solution is localStorage. Here is how the flow would look like -

Generate a unique identifier for each tab
Store the first tab as active in localStorage
When a new tab is opened, check the storage for any active tab.
If one exists, lock the new tab, otherwise, make it active
Subscribe to storage events to react to active tab changes.
When the active tab is closed, remove it from storage so another tab can become active.

The above does work and new tabs are correctly locked.

Now let's visit the edge cases -

Next active tab - We can store the order in which the tabs are opened, and then based on the order, we can choose to select the next tab. This adds complexity, as we must also remove closed tabs from the order array. We can store this in localStorage as well.
Stale active tab - You might think that we can use beforeunload event and remove it from the localStorage. But the beforeunload event is not that reliable. It won't fire in scenarios like a system crash or an abrupt OS shutdown, leaving stale data in localStorage.
Race condition - Honestly, I couldn't find a clean way to handle this with localStorage alone.

Broadcast Channel

The flow here is almost identical to the localStorage approach, with two differences:

We use a BroadcastChannel to communicate directly between tabs
Instead of storing state in localStorage, each tab maintains its own in-memory copy of the active tab and the order array, kept in sync via BroadcastChannel messages.

Here is how the flow would be like -

Generate a unique identifier for each tab
When a new tab opens, broadcast a message to ask for the current state
An existing tab responds with the active tab and the order array
Based on the response, decide whether to lock the new tab or make it active
When the active tab is closed, broadcast a message so other tabs can update their in-memory state and elect the next active tab

Now let's revisit the edge cases —

Next active tab - Same as before, we maintain the order array in memory and pick the next one when the active tab closes.
Stale active tab - Interestingly, this is partially better. Since state is in-memory, it dies with the browser — no stale data persists to the next session. However, we still rely on beforeunload to notify other tabs, which is not that reliable.
Race condition - Same problem. Still no clean solution here.

A step forward, but still does not covers everything we need.

Web Locks API

Both approaches we discussed earlier got us close, but we were essentially building a locking mechanism from scratch. What if the browser already had one?

This is where the Web Locks API really shines. Instead of building a locking mechanism from scratch, we can use a browser-provided one that already handles coordination between tabs, including queuing and race conditions.

In our case, the application itself becomes the shared resource. We can define a lock name, say dev:app, and use it to ensure that only one tab can acquire it at a time.

Here is how a typical flow would look like -

When a tab is opened, use the Web Locks API to acquire the lock.
If the lock is acquired, set the current tab to active.

That's all. Everything else is handled by the browser.
Here’s how this looks in React, though the same idea applies across frameworks.

const [active, setActive] = useState(false);

useEffect(() => {
  navigator.locks.request("dev:app", () => {
    setActive(true);
  });
}, []);

if (!active) {
  return <div>This tab is not available</div>;
}

return <div>This tab is available</div>

Let's visit the edge cases for this -

Next active tab - The browser handles assigning the next active tab. When the active tab is closed, the lock is released and the browser automatically assigns it to the next tab in the queue.
Stale active tab - Since the Web Locks API doesn't persist any state, there is no stale data to worry about. When the browser is closed, all locks are released automatically.
Race condition - The browser handles this gracefully. When multiple tabs try to acquire the lock at the same time, the browser ensures only one tab gets it, queuing the rest.

Conclusion

What started as a simple requirement turned into a useful reminder that sometimes the real challenge is not in the implementation, but in knowing what the platform already provides. Instead of building our own coordination logic, we can rely on the Web Locks API to handle it in a much more reliable way.

If you find yourself building a locking mechanism from scratch in the browser, stop and check if the Web Locks API fits. Chances are, it does.

Performant Web Apps

Shubhajit Chatterjee — Sun, 08 Sep 2024 12:15:00 +0000

Imagine a world where dynamic web applications are so responsive, they feel as fast as static sites served directly from a user’s local system. That level of speed would create a seamless and delightful user experience.

But is that even possible? Dynamic apps need to load HTML, CSS, JavaScript, retrieve data, render the UI, and often pull in more resources as users interact. So how do we achieve snappy performance, especially when screens depend heavily on server data? A “local-first” approach might help, but it’s not always feasible—and not every manager will agree to it.

I’ll share strategies I’ve learned from blogs, X (formerly Twitter), and YouTube videos to help close the gap and improve the user experience.

We will discuss the following here

The Problem
Possible Cause
Possible Solutions
- Poorly written data fetching or async code
- fetch-as-you-render & render-as-you-fetch

The Problem

Before jumping into performance strategies, let’s define the problem. The perfect user experience depends on factors like network speed, server latency, and data processing.

Our goal is simple: reduce loading states. We won’t focus on code optimization, data structures, or algorithms. Instead, we’ll explore solutions for SPAs that work across frameworks and can be extended to SSR apps.

Possible Causes

One major reason apps feel slow is the network waterfall. This is very well explained on Remix’s homepage. I encourage everyone to check it out if not already done. But how does a traditional app cause this? Common reasons I’ve seen in many codebases include:

Poorly written data fetching or async code
Fetch-as-you-render
Decoupled components that fetch their own data, leading to more fetch-as-you-render scenarios

Thus the above problem statement can be rewritten as reducing network waterfall

Possible Solutions

Tools these days are very good and when used together can handle some of the above scenarios if used properly.

Let's see some ways to resolve some of the mentioned above

Poorly written data fetching or async code

Let’s take a look at this function:

async function fetchUserData(userId: string) {
  const postsResponse = await fetch(`/api/posts/${userId}`);
  const posts = await postsResponse.json();

  const commentsResponse = await fetch(`/api/comments/${userId}`);
  const comments = await commentsResponse.json();

  return { comments, posts }
}

This function fetches a user’s posts and comments based on userId. However, it causes a network waterfall because the comments request waits for the posts request to finish.

We can improve it by fetching both at the same time:

async function fetchUserData(userId: string) {
  const [posts, comments] = await Promise.all([
    fetch(`/api/posts/${userId}`).then((response) => response.json()),
    fetch(`/api/comments/${userId}`).then((response) => response.json()),
  ]);

  return { posts, comments };
}

By using Promise.all, both API calls happen in parallel, removing the waterfall delay.

There are many methods available on Promise that can be useful in different scenarios

Not all API calls can be parallelized—some may depend on the results of others—but many don’t. For dependent requests, this optimization doesn’t apply, and further strategies would depend on specific cases (which we won’t cover here).

The example above doesn’t handle errors, as it’s just for demonstration.

`fetch-as-you-render` & `render-as-you-fetch`

This is an interesting one and is very very common in codebases. So, what is fetch-as-you-render and how does it cause delayed UI?

fetch-as-you-render is caused when data is fetched inside a component and the Fetch-as-you-render happens when data fetching is triggered inside a component, often during the render phase or in lifecycle methods like useEffect. This is common across many frontend frameworks such as Solid, Svelte, and Vue.

Imagine you have three nested components, each fetching its own data. This creates a scenario similar to poorly written data fetching: each component’s data fetch starts only after the component is rendered or mounted. This not only delays the rendering but can also cause additional delays as each fetch waits for the previous one to complete.

Let look at a piece of code:


function UserDataViewer() {
  const [user, setUser] = useState<User | null>(null);
  const [isLoading, setIsLoading] = useState(false);

  useEffect(() => {
    setIsLoading(true);
    fetchUser().then((_user) => {
      setUser(_user);
      setIsLoading(false);
    });
  }, []);

  if (isLoading) {
    return <div>Loading...</div>;
  }

  return (
    <>
      <Posts userId={user.id} />
      <UserCommentsViewer userId={user.id} />;
    </>
  );
}

function Posts({ userId }: { userId: string }) {
  const [posts, setPost] = useState<Post | null>(null);
  const [isLoading, setIsLoading] = useState(false);

  useEffect(() => {
    setIsLoading(true);
    fetchUserPosts(userId).then((_posts) => {
      setPost(_posts);
      setIsLoading(false);
    });
  }, []);

  if (isLoading) {
    return <div>Loading...</div>;
  }

  return (
    <PostsViewer posts={posts} /> // A static component to show Posts
  );
}

function UserCommentsViewer({ userId }: { userId: string }) {
  const [comments, setComments] = useState<Comment | null>(null);
  const [isLoading, setIsLoading] = useState(false);

  useEffect(() => {
    setIsLoading(true);
    fetchUserComments(userId).then((_comments) => {
      setComments(_comments);
      setIsLoading(false);
    });
  }, []);

  if (isLoading) {
    return <div>Loading...</div>;
  }

  return <Comments comments={comments} />; // A static component to show comments
}

The provided code demonstrates the fetch-as-you-render pattern, which can lead to delayed UI updates. Here’s how:

UserDataViewer: It fetches user data and waits for it to complete before rendering the Posts and UserCommentsViewer component.
Posts & UserCommentsViewer: Once UserDataViewer has fetched and set the user data, Posts fetches posts based on the user ID.

In this setup, each component fetches its data only after the previous component’s data is available, causing a cascading delay. Each fetch operation waits for the component to render or mount, leading to slower overall page load times.

Fetching data per component is a common pattern to have colocation but can lead to inefficiencies. Libraries like @tanstack/react-router and SWR simplify the process, but the fetch-as-you-render issue remains. Hoisting data fetching to a parent component helps, but what if that parent component is rendered within another component? How can we further improve this approach?

Render-as-you-fetch is a interesting pattern that can improve this situation. This can have its own blog, maybe I will write this in more details some other time, but let's directly jump to a solution.

Most frameworks provide data loaders integrated with their routers. For example, react-router-dom has loaders and actions, @tanstack/react-router offers loaders, @solidjs/router uses a load function, and @sveltejs/kit includes load function. Let’s explore how we can leverage react-router-dom and its loader and composition to improve data fetching efficiency.

export async function loader() {
  const { userId } = await fetchUser();

  const [posts, comments] = await Promise.all([
    fetch(`/api/posts/${userId}`).then((response) => response.json()),
    fetch(`/api/comments/${userId}`).then((response) => response.json()),
  ]);

  return { posts, comments };
}

function UserDataViewer() {
  const { posts, comments } = useLoaderData();
  return (
    <>
      <Posts posts={posts} />
      <UserCommentsViewer comments={comments} />
    </>
  );
}

The code above eliminates the waterfall effect by fetching data in the loader and passing it to the component as props. While this approach blocks user navigation until the data is fetched, you can adjust this behavior using Await, defer, and Suspense components. For more details, refer to the guide in the react-router-dom documentation.

But this above code has one problem, the data fetching is completely moved to loaders, and the colocation with component is lost. What if I want to drop UserCommentsViewer in another component in another route? I have to make sure that the data loader their fetches the data and correctly pass it to component, I cannot expect that I drop a component and it just works.

Let's improve this further using @tanstack/react-query

export async function loader() {
  const { userId } = await fetchUser();

  void queryClient.ensureQueryData(getPostsQueryOptions(user.id));
  void queryClient.ensureQueryData(getCommentsQueryOptions(user.id));

  return { userId };
}

function UserDataViewer() {
  const { userId } = useLoaderData();
  return (
    <>
      <Suspense fallback={<div>Loading...</div>}>
        <Posts userId={userId} />
      </Suspense>

      <Suspense fallback={<div>Loading...</div>}>
        <UserCommentsViewer userId={userId} />
      </Suspense>
    </>
  );
}

function Posts({ userId }: { userId: string }) {
  const { data } = useQuery(getPostsSuspenseQueryOptions(userId));
  return <div>{/* The actual code to render */}</div>;
}

function UserCommentsViewer({ userId }: { userId: userId }) {
  const { data } = useQuery(getPostsSuspenseQueryOptions(userId));
  return <div>{/* The actual code to render */}</div>;
}

This code tackles the waterfall issue while keeping the data fetching colocated with the component. The above code works as follows -

Loader Function: Instead of just letting the components fetch their own data, the loader triggers the actual api call parallely. This prevents the waterfall. The code above will also render the route without waiting for the data to be fetched, this can be modified by awaiting them.
Colocated Data Fetching: The Posts and UserCommentsViewer components use useQuery to access the already-fetched or ongoing fetch data. Since the loader has done the heavy lifting, these components can render themselves without worrying about the waterfall.

Another great thing about these components is that they’re self-contained. You can drop them anywhere in your React app, and they’ll work just fine. Of course, if you move the component, the route loader will need the prefetch logic too, but that’s easily handled.

There’s another cool benefit to using loaders for prefetching. Most routing libraries can prefetch data when a link is hovered over or rendered, meaning the data is ready before the user even clicks the link. This taps into the render-as-you-fetch pattern, where the component already has the data by the time it renders, eliminating the need for fetch calls inside the component.

I personally find this approach clean and efficient. I stumbled upon this while digging through the @tanstack/react-router docs. You’ll find a similar implementation in the Solid.js repo for Hacker News.

Of course, there are plenty of other reasons why web apps might feel slow, and frameworks are constantly rolling out new solutions. But these approaches are relatively easy to incorporate into existing codebases and can make a noticeable difference.

Hey everyone! This is my first blog, and I’d love to hear your suggestions and feedback to help me improve. I wrote this to share some solutions I’ve come across while working on codebases and tutorials, where I’ve noticed these common issues pop up. Let me know what you think!

DEV Community: Shubhajit Chatterjee

Building a single active tab experience

Core Requirements

Edge Cases

Possible Solutions

Local Storage

Broadcast Channel

Web Locks API

Conclusion

Performant Web Apps

The Problem

Possible Causes

Possible Solutions

Poorly written data fetching or async code

fetch-as-you-render & render-as-you-fetch

`fetch-as-you-render` & `render-as-you-fetch`