DEV Community: Haochen

I Built a “Real‑Time Dashboard Mock” Because Interviews Wouldn’t Let It Go

Haochen — Sat, 28 Feb 2026 08:41:23 +0000

Try it out here:

hcsum.github.io

If you've ever been asked in an interview, "How would you handle real-time, high-frequency data on the frontend?" — welcome to my personal saga. I've heard that question so many times that I finally turned it into a project.
This repo is a Real-Time Dashboard Mock: a playful but practical sandbox that simulates polling/WebSocket-style data firehose and asks your UI to keep up. Think: tens of thousands of list rows, continuous updates, and user interactions (edit, filter, sort) happening at the same time.

Why I Built It

Because interviews don't just want theory — they want proof. This repo is my answer: a visible, testable environment to explore what "smooth" actually means under load.

What's Inside

• A mock data hose that floods the frontend at adjustable rates.
• A dashboard UI where you can filter, edit, and sort while data streams in.
• A clear separation between setup and business UI, so optimization work stays clean.

Where to Optimize

The optimization work lives in src/Dashboard.tsx. That's where you can dig into techniques like these:
• List virtualization — only render rows in the viewport. Libraries like react-window or TanStack Virtual make 50k rows feel trivial.
• Memoization — wrap row components in React.memo and stabilize callbacks with useCallback to stop cascade re-renders on every tick.
• Deferred filtering — use useDeferredValue or debounce to delay expensive filter recalculations while the stream keeps flowing.
• Batching — buffer incoming tick events and flush them in a single setState call per frame to cut re-render frequency way down.
• ID-to-index map — maintain a Map alongside your array so deletions and lookups are O(1) instead of scanning the entire list every time.
• Normalized state — store rows in a Map instead of an array. Updates and deletes become direct key lookups with no find(), splice(), or indexOf() needed.
• Separate display order — keep a dedicated ordered array of IDs for rendering. Sorting only reshuffles the ID list; the data map stays untouched.
• Web Worker offloading — push sort and filter logic off the main thread so the UI stays responsive during heavy computation.
• requestAnimationFrame throttling — gate state flushes to rAF so you never commit more than one update per paint cycle regardless of tick rate.
• Structural sharing — on each update, only create new objects for rows that actually changed so React.memo can bail out cheaply on untouched rows.
The stream generator and tuning controls live in src/App.tsx. That stays as the mock setup layer so your optimizations don't get tangled with the test harness.

Want the Original Unoptimized Challenge?

Check out the /problem branch. That's the raw version without any fixes — perfect if you want to feel the pain first and build your own strategy from scratch.

Try Breaking It

As the time of writing, I haven't fully optimize it yet, but you can test its limit by:
• Crank the tick interval way down.
• Increase batch size.
• Filter while data is flowing.
• Edit rows mid-stream.
• Sort at 100k+ rows.
• Delete items rapidly and watch how long the list scan takes.
If the UI stays smooth, you win. Drop a star on the repo if it helped, or open a PR if you find a technique worth adding.

hcsum / realtime-dashboard-mock

A dashboard demo to handle large volume and frequent data updates

Real‑time Dashboard Mock

This repo simulates a high‑frequency data hose (polling/WebSocket‑like) and a dashboard UI that must stay responsive while rendering a large list.

Quick start

pnpm install
pnpm dev

Where to add your optimized code

Put your rendering and interaction optimizations in the Dashboard component:

src/Dashboard.tsx — list rendering, filtering, editing, and user interaction live here.
src/App.tsx — stream “hose” and tuning controls live here. Keep this as the mock setup layer.

If you want to compare against the original unoptimized version, check out the /problem branch.

What to try

Set Tick Interval to a very low value and Batch Size high to stress the UI.
Type in the filter while the stream is running.
Edit titles/notes while items are streaming in.
Sort the list while the stream is active with 5,000+ rows.

Notes / structure

Dashboard rendering is isolated in src/Dashboard.tsx so you can optimize without touching the…

View on GitHub

Interactive React 19 list demo with useOptimistic hook

Haochen — Tue, 18 Mar 2025 07:01:32 +0000

Try it out here: https://interactive-nextjs-list-demo-blond.vercel.app/
(Create a new user, if the page doesn't redirect, please refresh the page.)

Add a new item from the right, press enter, you can see the item immediately gets created in the list, and later when the green flashes it indicates the item is added to the backend.

The syntax of useOptimistic is similar to a useReducer, const [optimisticState, addOptimistic] = useOptimistic(state, updateFn), where updateFn can be a reducer function.

This is the reducer function for this example:

export type OptimisticItem = Item & {
  updating?: boolean;
  deleting?: boolean;
  creating?: boolean;
};

export type ItemReducerAction =
  | { type: "update"; item: ItemUpdateInput }
  | { type: "delete"; itemId: string }
  | { type: "create"; item: Item };

export const itemReducer = (
  state: OptimisticItem[],
  action: ItemReducerAction,
) => {
  switch (action.type) {
    case "update":
      return state.map((item) =>
        item.id === action.item.id
          ? { ...item, ...action.item, updating: true }
          : item,
      );
    case "delete":
      return state.map((item) =>
        item.id === action.itemId ? { ...item, deleting: true } : item,
      );
    case "create":
      return [{ ...action.item, creating: true }, ...state];
    default:
      return state;
  }
};

Noticed there are extra states updating, deleting, creating added to the item by the reducer, which will be handy to display visual cues to the user later.

I opted to use useOptimistic in combination with the context api:

export const OptimisticItemsContext = createContext<{
  items: OptimisticItem[];
  updateOptimisticItems: (action: ItemReducerAction) => void;
} | null>(null);

export const ItemsProvider = ({
  children,
  items,
}: {
  children: React.ReactNode;
  items: Item[];
}) => {
  const [optimisticItems, updateItems] = useOptimistic<
    OptimisticItem[],
    ItemReducerAction
  >(items, itemReducer);
  const [, startTransition] = useTransition();

  const updateOptimisticItems = (action: ItemReducerAction) => {
    startTransition(() => {
      updateItems(action);
    });
  };

  return (
    <OptimisticItemsContext.Provider
      value={{
        items: optimisticItems,
        updateOptimisticItems,
      }}
    >
      {children}
    </OptimisticItemsContext.Provider>
  );
};

export const useOptimisticItemsContext = () => {
  const context = useContext(OptimisticItemsContext);
  if (!context) {
    throw new Error(
      "useOptimisticItemsContext must be used within a OptimisticItemsProvider",
    );
  }
  return context;
};

I think one key takeaway of useOptimistic is that it only creates a temporary state that live between the mutation's started and settled period, as the dispatch function of useOptimistic can only be called in a form action or in a transition. Notice I wrap the dispatch function with a startTransition.

The context value is mainly consumed by the ListTable and AddItemForm component:

In their parent component, the items data is fetched by a server function and passed to the ItemsProvider as prop:

const { items, totalPages, total } = await getItems()
...

return (
    <ItemsProvider items={items}>
         ...
    </ItemsProvider>
)

So instead of the original items data, the ItemTable will display the optimistic version of the items.

Take creating an item as example, I update the state by calling updateOptimisticItems before making the real mutation request:

  const addItemAction = (formData: FormData) => {
    formRef.current?.reset();
    updateOptimisticItems({
      type: "create",
      item: {
        id: new Date().getTime().toString(),
        userId: "xxx",
        name: formData.get("name") as string,
        pieces: parseInt(formData.get("pieces") as string),
        ...
      },
    });
    mutate(formData);
  };

If you try to add an item, you will see the temporary placeholder item appear on top of the ItemTable instantly. After the mutation is succeeded, React replace the placeholder item with the real new item fetched by revalidatePath("/") seamlessly. At this point, I wonder if the extra "refetch" is necessary. If you have any thoughts about this, please let me know.

I was used to working with react-query's caching to improve UX, where I wait for mutation to settle and meanwhile display a loading state, after mutation succeeded, modify cached data without making another fetch, aka. app-like experience. But useOptimistic go beyond that, it can provide instant state change right after the mutation is triggered and before it's settled. It is like what they do in real-time action games, register user input in local device and send request at the same time.

In the ItemForm component, I use the extra state attached to the modified item to display css animations on the items:

  const isEditing =
    (!item.updating && editingId === item.id) ||
    Object.keys(validationErrors).length !== 0;

  const isNewlyCreated = item.creating;
  const isNewlyUpdated =
    new Date().getTime() - new Date(item.updatedAt).getTime() < 1000 * 10;
  const isNewlyDeleted = item.deleting;

return (
    <div
      key={item.id}
      className={`p-4 md:p-8 border rounded-lg transition-colors ${
        isNewlyCreated ? "created-animation" : ""
      } ${isNewlyUpdated ? "confirmed-animation" : ""} ${
        isNewlyDeleted ? "deleting-animation" : ""
      }`}
    >
       ...

One more thing, it is surprisingly easy to handle error and "roll back" state. The way useOptimisic works give this to us for free, since mentioned earlier, the state only lives between the mutation is triggered and settled. So we can handle mutation error like we used to.

I only use useOptimistic to manage the items' state, the categories ' state are managed by Next.js's default way of doing. I'm still exploring and learning about Next.js 15 and React 19, there can be things less ideal in this demo, I'm open to any thoughts and learn from you.

Feel free to fork or clone the repo here: https://github.com/hcsum/interactive-nextjs-list-demo

Use Prisma and PostgresDB in a prevent ticket oversold example

Haochen — Wed, 12 Mar 2025 15:32:43 +0000

This is a quick demo for using the PostgresDB’s isolationLevel to prevent ticket oversold. Full code can be found here

We have this schema set up in schema.prisma:

model User {
  id      Int      @id @default(autoincrement())
  name    String
  tickets Ticket[]
}

model Event {
  id            Int           @id @default(autoincrement())
  title         String
  ticketClasses TicketClass[]
  createdAt     DateTime      @default(now())
  updatedAt     DateTime      @updatedAt
}

model TicketClass {
  id        Int      @id @default(autoincrement())
  title     String
  limit     Int
  createdAt DateTime @default(now())
  updatedAt DateTime @updatedAt
  eventId   Int
  event     Event    @relation(fields: [eventId], references: [id])
  tickets   Ticket[]
}

model Ticket {
  id            Int         @id @default(autoincrement())
  ticketClassId Int
  ticketClass   TicketClass @relation(fields: [ticketClassId], references: [id])
  userId        Int
  user          User        @relation(fields: [userId], references: [id])
  createdAt     DateTime    @default(now())
  updatedAt     DateTime    @updatedAt
}

Each Event can have multiple TicketClasses, e.g. "one-day pass", "two-day pass". Each TicketClass has a limit field that indicate the maximum number of tickets this TicketClass is allowed to be sold. When a User purchase a ticket of a TicketClass, a Ticket record will be created and linked to that TicketClass. Before each purchase, we should count the number of Tickets by the TicketClassId, if it equals limit, we should prevent the purchase.

This is the purchaseTicket implementation:

export const purchaseTicket = async ({
  userId,
  ticketClassId,
  slow = true,
}) => {
  const ticketClass = await prisma.ticketClass.findUniqueOrThrow({
    where: {
      id: ticketClassId,
    },
  });

  const soldTickets = await prisma.ticket.count({
    where: {
      ticketClassId,
    },
  });

  // Introduce an artificial delay
  await new Promise((resolve) => setTimeout(resolve, slow ? 100 : 0));

  if (soldTickets >= ticketClass.limit) {
    throw new Error(
      `${ticketClass.title} is sold out, user ${userId} cannot purchase ticket`,
    );
  }

  const ticket = await prisma.ticket.create({
    data: {
      userId,
      ticketClassId,
    },
  });

  return ticket;
};

We then seed the data:

import prisma from "./index.js";

const seed = async () => {
  const event = await prisma.event.create({
    data: {
      title: "My Event",
    },
  });

  const ticketClass = await prisma.ticketClass.create({
    data: {
      eventId: event.id,
      title: "One-day Pass",
      limit: 2,
    },
  });

  await Promise.all(
    ["Sam", "Bob", "Jane", "May"].map((name) =>
      prisma.user.create({
        data: {
          name,
        },
      }),
    ),
  );
};

seed();

We create a race condition to purchase 4 tickets at the same time under the "one-day pass" TicketClass which only has 2 tickets available:

await Promise.all([
    purchaseTicket({ userId: 1, ticketClassId: 1 }).catch(console.error),
    purchaseTicket({ userId: 2, ticketClassId: 1 }).catch(console.error),
    purchaseTicket({ userId: 3, ticketClassId: 1 }).catch(console.error),
    purchaseTicket({ userId: 4, ticketClassId: 1 }).catch(console.error),
]);

We run npm run reset-db followed by node index.js. With current purchaseTicket function, the TicketClass will oversold:

Then we switch to using purchaseTicketTransaction. Here we use Prisma's $transaction() and provide a callback which has the same implementation as purchaseTicket, and set isolationLevel to Serializable:

export const purchaseTicketTransaction = async ({
  userId,
  ticketClassId,
  slow = true,
}) => {
  try {
    const ticket = await prisma.$transaction(
      async (tx) => {
        const ticketClass = await tx.ticketClass.findUniqueOrThrow({
          where: {
            id: ticketClassId,
          },
        });

        const soldTickets = await tx.ticket.count({
          where: {
            ticketClassId,
          },
        });

        // Introduce an artificial delay
        await new Promise((resolve) => setTimeout(resolve, slow ? 100 : 0));

        if (soldTickets >= ticketClass.limit) {
          throw new Error(
            `${ticketClass.title} is sold out, user ${userId} cannot purchase ticket`,
          );
        }

        const ticket = await tx.ticket.create({
          data: {
            userId,
            ticketClassId,
          },
        });

        return ticket;
      },
      { isolationLevel: "Serializable" },
    );
    return ticket;
  } catch (error) {
    throw new Error(
      `user ${userId} cannot purchase ticket, reason: ${error.message}`,
    );
  }
};

async function main() {
  await Promise.all([
    purchaseTicketTransaction({ userId: 1, ticketClassId: 1 }),
    purchaseTicketTransaction({ userId: 2, ticketClassId: 1 }),
    purchaseTicketTransaction({ userId: 3, ticketClassId: 1 }),
    purchaseTicketTransaction({ userId: 4, ticketClassId: 1 }),
  ]);
}

We reset the db npm run reset-db and run node index.js again.

This time, only one purchase go through:

And the rest got error thrown:

Error: user 1 cannot purchase ticket, reason: Transaction failed due to a write conflict or a deadlock. Please retry your transaction
    at purchaseTicketTransaction (file:///Users/sum/Codes/postgres-playground/handlers.js:81:11)
    at async Promise.all (index 0)
    at async main (file:///Users/sum/Codes/postgres-playground/index.js:4:3)
Error: user 2 cannot purchase ticket, reason: Transaction failed due to a write conflict or a deadlock. Please retry your transaction
    at purchaseTicketTransaction (file:///Users/sum/Codes/postgres-playground/handlers.js:81:11)
    at async Promise.all (index 1)
    at async main (file:///Users/sum/Codes/postgres-playground/index.js:4:3)
Error: user 4 cannot purchase ticket, reason: Transaction failed due to a write conflict or a deadlock. Please retry your transaction
    at purchaseTicketTransaction (file:///Users/sum/Codes/postgres-playground/handlers.js:81:11)
    at async Promise.all (index 3)
    at async main (file:///Users/sum/Codes/postgres-playground/index.js:4:3)

This is interesting because the one-day pass TickeClass has its limit set to 2. Presumably 2 purchases should go through. But due to the transaction and isolation level set to prevent oversold, we can only allow one purchase to go through at a specific time.

We need to balance oversold and user experience.

Learn more about Prisma's interactive transactions: https://www.prisma.io/docs/orm/prisma-client/queries/transactions#interactive-transactions
Example code: https://github.com/hcsum/postgres-playground/tree/prevent-ticket-over-sold-demo