DEV Community: Katerina Bulkina

How to Structure a B2B SaaS Frontend Around Changing Operational Data

Katerina Bulkina — Thu, 15 Oct 2026 05:15:19 +0000

Imagine you're working in a logistics dashboard. You filter shipments to see everything that's delayed. You open one record, check its ETA, and start investigating the problem.

Meanwhile, new shipment information arrives from the server. One shipment changes status. Another gets a new ETA. A background request finishes just after you've changed your filters.

What should the interface do?

If every update replaces the entire screen state, users can lose their place. If the application keeps showing old records, the interface becomes unreliable.

We worked with this type of operational data while designing and developing LogiCore, a logistics and warehouse SaaS application at UITOP.

The product connects shipment monitoring, warehouse locations, inventory records, and operational metrics. Its frontend uses React, TypeScript, and Zustand, with data served through REST APIs backed by Node.js, Express, PostgreSQL, and Prisma.

For shipment monitoring, our team used Zustand-managed polling to retrieve updated status, ETA, and timestamp information. That project gives us a useful starting point for a broader engineering question:

How should a React application manage user interactions and changing server data at the same time?

Start by separating three kinds of state

A common source of frontend bugs is treating every piece of information on a screen as one large object.

Consider a shipment monitoring page. It may contain:

Current shipment records and their statuses
Active filters and pagination
The shipment the user has selected
Loading and refresh indicators
Errors from API requests
A timestamp showing when the data was updated

These values have different responsibilities. I find it useful to separate them into three groups.

Server data

This represents information the application receives from its backend.

Shipment ID
Current shipment status
ETA
Last carrier update
Total number of records matching a query

The backend determines the current business state. The frontend presents a snapshot of that information.

User interface state

This represents the user's current interaction with the page.

Active status filter
Current page
Selected shipment ID
Expanded details
Open dialogs

A background data refresh generally should not reset these choices.

Request state

This describes what's happening while the application communicates with the server.

Initial loading
Background refresh in progress
Last successful response
Request failure
Data that may be stale

This third group matters because a screen can have valid data and an active request at the same time. A user should still be able to inspect the current results while the application retrieves newer information.

Make the user's current view explicit

Suppose a shipment table supports two filters: All and Delayed. The user can also navigate between pages and select a shipment. Those interactions can be represented independently from the returned shipment records.

Zustand example:

import { create } from "zustand";

type StatusFilter = "all" | "delayed";

type ShipmentViewState = {
  status: StatusFilter;
  page: number;
  selectedShipmentId: string | null;

  setStatus: (status: StatusFilter) => void;
  setPage: (page: number) => void;
  selectShipment: (id: string | null) => void;
};

export const useShipmentView =
  create<ShipmentViewState>((set) => ({
    status: "all",
    page: 1,
    selectedShipmentId: null,

    setStatus: (status) =>
      set({
        status,
        page: 1,
        selectedShipmentId: null,
      }),

    setPage: (page) => set({ page }),

    selectShipment: (id) =>
      set({ selectedShipmentId: id }),
  }));

Changing the status filter resets pagination to page 1. The previous page might not exist in the filtered result.

Selection is stored by shipment ID. If shipment records are refreshed, the application can still identify the selected item. The selected object doesn't need to be stored as a separate copy of the entire record.

Whether selection should be cleared when filters change depends on the workflow. In this example, we clear it explicitly. In other products, keeping the detail view open may be preferable.

The important part is making that behavior intentional.

Keep polling separate from table interactions

In LogiCore, shipment status and ETA information are refreshed through background requests to the REST API.

Polling is a reasonable approach when the application needs periodic updates and the source data doesn't require a continuous streaming connection. The challenge is managing those requests as the user changes the current view.

A naive implementation might look like this:

setInterval(async () => {
  const response = await fetch("/api/shipments");
  const data = await response.json();

  setShipments(data);
}, 15000);

It doesn't account for current filters or pagination. It has no error handling. Requests can overlap if one response takes longer than the interval.

It also doesn't address what happens when the component unmounts or the user switches to a different query. A more reliable implementation gives the polling process a clear lifecycle.

React polling example

import { useEffect, useState } from "react";

type Shipment = {
  id: string;
  status: string;
  eta: string | null;
};

type ShipmentPage = {
  items: Shipment[];
  total: number;
  updatedAt: string | null;
};

type FeedState = {
  key: string;
  data: ShipmentPage | null;
  syncing: boolean;
  error: string | null;
};

export function useShipmentFeed(
  status: string,
  page: number
) {
  const key = `${status}:${page}`;

  const [feed, setFeed] = useState<FeedState>({
    key,
    data: null,
    syncing: true,
    error: null,
  });

  useEffect(() => {
    const controller = new AbortController();
    let active = true;
    let timer: ReturnType<typeof setTimeout>;

    setFeed({
      key,
      data: null,
      syncing: true,
      error: null,
    });

    async function refresh() {
      if (!active) return;

      setFeed((previous) =>
        previous.key === key
          ? { ...previous, syncing: true }
          : previous
      );

      try {
        const params = new URLSearchParams({
          status,
          page: String(page),
        });

        const response = await fetch(
          `/api/shipments?${params}`,
          { signal: controller.signal }
        );

        if (!response.ok) {
          throw new Error(`HTTP ${response.status}`);
        }

        const data =
          (await response.json()) as ShipmentPage;

        if (active) {
          setFeed({
            key,
            data,
            syncing: false,
            error: null,
          });
        }
      } catch (error) {
        if (active && !controller.signal.aborted) {
          setFeed((previous) =>
            previous.key === key
              ? {
                  ...previous,
                  syncing: false,
                  error: "Could not refresh shipments",
                }
              : previous
          );
        }
      } finally {
        if (active) {
          timer = setTimeout(refresh, 15000);
        }
      }
    }

    void refresh();

    return () => {
      active = false;
      controller.abort();
      clearTimeout(timer);
    };
  }, [key, status, page]);

  return feed.key === key
    ? feed
    : {
        key,
        data: null,
        syncing: true,
        error: null,
      };
}

The endpoint, response shape, and 15-second interval are illustrative.

Several common problems here:

Requests follow the active query

The effect depends on the current filter and page. When either changes, React cleans up the previous effect and starts a new request process for the new query.

Old requests cannot update the new view

The cleanup aborts the previous fetch. The active check also prevents a response from updating component state after its effect has been cleaned up. That matters because network requests do not necessarily finish in the order they started. Imagine the user selects Delayed and immediately switches back to All.

The Delayed request may finish last. Its response should not replace the current All result.

Polling requests don't overlap

The next timer is scheduled after the current request settles. That prevents this particular polling loop from starting another request while its previous request is still pending. In a production application, I would also consider an upper limit on request duration.

Existing results remain available during a refresh

After the initial load succeeds, setting syncing to true doesn't clear the current response. The interface can continue showing its most recent results while the next request is in progress. This makes a useful distinction between initial loading and refreshing existing data.

For a real application, I would also consider request deduplication, visibility-aware polling, authentication expiration, retry backoff, and how multiple components share the same data. A dedicated server-state library may be appropriate when those responsibilities grow.

Give every refresh a predictable UI behavior

Fetching current data is only half the implementation. The frontend also needs rules for presenting that data. Consider a shipment with this information:

If the user is looking at that shipment, the interface should present the newer information in the relevant record. But the application must also decide what happens if the new status changes which rows match the active filter.

Suppose the current view shows only In transit shipments. After a refresh, a shipment becomes Delayed.

Should it disappear immediately?

There isn't one correct answer for every operational product. Immediate removal maintains strict consistency with the filter. It can also make a row disappear while someone is examining it.

An alternative interaction is to retain the currently displayed set temporarily and indicate that newer results are available.

The appropriate behavior depends on the task. For a monitoring dashboard, timely changes may take priority. For a table where operators select records and perform multi-step actions, preserving working context may be more important. This is a product decision that frontend and UX teams should agree on before implementation.

Treat timestamps as part of data reliability

A label such as "Last updated" sounds simple, but developers need to agree on what it represents.

When the external carrier produced the information
When the backend received the update
When the API response was generated
When the frontend successfully fetched the response

These times can differ. A successful API request at 12:30 doesn't prove that the carrier supplied new data at 12:30.

In LogiCore, shipment monitoring includes status information, ETA drift indicators, and last-update timestamps associated with refreshed carrier data.

For similar systems, I would make timestamp ownership explicit in the API contract. The response might distinguish:

{
  "shipmentId": "SHP-2048",
  "status": "delayed",
  "eta": "2026-10-23T16:10:00Z",
  "carrierUpdatedAt": "2026-10-23T12:24:00Z",
  "fetchedAt": "2026-10-23T12:30:00Z"
}

It can show when the shipment information last changed and separately track when the application last synchronized.

This distinction becomes useful during outages, integration delays, and incidents where a user needs to know how current the information actually is.

A failed refresh should be visible

Imagine a dispatcher reviewing 40 shipments. The page initially loads correctly. Five minutes later, the network becomes unstable and the background refresh fails.

Should the table disappear?

Usually, the application still has a previously successful response that the user can inspect. The interface can preserve those records and show that the latest refresh failed. A useful set of UI states will include:

An expired session needs special handling. The product should not keep issuing the same unauthorized request every few seconds. If the request fails repeatedly, retry logic may need an increasing delay.

These are recommended patterns for operational software. Their exact implementation should follow the application's security requirements and data sensitivity.

Don't let background updates interrupt active work

There is another problem that appears when a product moves beyond read-only dashboards.

Suppose a user is editing the assigned carrier or reviewing a shipment exception while new information arrives from the backend. A refresh that blindly replaces an entire local object can overwrite in-progress changes.

For editable records, I would define which fields belong to the current server snapshot and which fields belong to an active local operation. The application also needs a policy for conflicts.

Has the record changed since the user opened it?
Is the user editing the same field that changed on the server?
Can the operation be submitted against the newer record version?
Does the user need to review the difference before continuing?

Depending on the product, that may require version fields, conditional updates, or a conflict-resolution interaction.

These decisions are especially important in ERP, CRM, warehouse management, and other B2B applications where multiple users work with related records. This is a general implementation consideration, not a claim about a specific LogiCore editing workflow.

What I would test before release

For a React interface with changing operational data, I would test scenarios beyond the happy path.

Rapid filter changes. Switch between filters while requests are pending. Confirm that the UI displays the result for the current query.

Slow responses. Simulate a request taking longer than the normal refresh interval.

Unmounting. Navigate away while a request is pending. Confirm that the polling process stops.

Repeated failures. Simulate network errors and authentication expiration. Check what remains visible and how the interface recovers.

Changing records. Update a shipment while a user is reviewing its details. Confirm that selection and navigation behave as intended.

Inactive tabs. Check whether background polling continues unnecessarily when the page isn't being used.

Different refresh speeds. Evaluate whether status changes appear frequently enough for the operational requirements and whether polling creates unnecessary backend traffic.

I would also review accessibility: refresh indicators should communicate meaningful changes, and frequent updates should not continuously interrupt screen-reader users.

What LogiCore taught us about operational frontend architecture

UITOP designed and developed LogiCore as one application connecting shipment monitoring, warehouse structures, inventory, and operational data.

The shipment interface uses React and TypeScript, with TanStack Table for table behavior and Zustand-managed polling for refreshed shipment information.

The backend uses Node.js, Express, PostgreSQL, Prisma, and REST APIs.

Those implementation decisions illustrate an important relationship between the frontend and its data sources. Users control filters, pagination, and navigation. The backend supplies current operational records. The request lifecycle determines when newer data reaches the interface.

A frontend architecture needs to manage those responsibilities consistently as the product grows. If I were reviewing an existing B2B SaaS product today, I would start with one practical scenario:

What happens when the user changes a filter at the same moment a background request returns newer data?
The answer reveals a lot about the quality of the application's state management, request handling, and user experience.

If you read this, read also about the project and the team

LogiCore is a logistics and warehouse SaaS designed and developed by UITOP, a product design and software development team specializing in complex B2B applications.

The project covered product design, frontend and backend development, database architecture, API development, and QA.

Read the LogiCore case study.

Building a shipment table for thousands of live records. What I learned on LogiCore?

Katerina Bulkina — Tue, 13 Oct 2026 15:30:58 +0000

A shipment table seems easy, a few columns, some filters, a status badge. Then real data shows up...

THOUSANDS of shipments, statuses that change all day, and operators who need to find the one late truck fast.

A table that feels fine with 50 test rows can crawl with 5,000.

I ran into this on LogiCore, a logistics and warehouse management platform UITOP designed and built from scratch, for a UK logistics company. The client ran a multi-million dollar business across three or four separate tools. Data didn’t match between them, updates came late, and managers made big calls without the full picture. They wanted one system for the warehouse floor and the office.

Our design, project management, development and QA teams worked on it together. Here’s how we built the shipment table, and why we made each choice.

What the table had to do

Operators used the table to find shipments and spot the ones that need attention. And they did it while statuses and ETAs kept changing.

The frontend runs on React, TypeScript and Vite, with TanStack Table (React Table v8), Zustand and Tailwind CSS. The backend uses Node.js, Express, PostgreSQL and Prisma ORM behind a REST API.

We had three separate problems to solve:

too much data to load,
too many rows to draw,
data that goes stale while the page is open.

Problem 1: the browser doesn’t need every shipment

Why load thousands of records when the operator looks at one screen at a time? Loading everything makes the first view slow and wastes memory.

So we used server-side pagination. The frontend asks the API for one page. PostgreSQL runs the query with the active filters and returns only that page.

Details matter more than they look:

Reset the page when a filter changes. If someone sits on page 12 and the new filter returns three pages, they should land on page 1, not on an empty screen.
Keep sorting stable. Records change all day, so the API needs a fixed order. Otherwise rows jump between pages and people lose their place.

Problem 2: one page can still be heavy

Pagination cuts how much data comes back. It doesn’t cut how much the browser has to draw. Each shipment row carries a status badge, an ETA drift indicator and a “Last Updated” timestamp. Draw hundreds of those at once, and React has a lot of work to do.

So we added row virtualization on top. The table only mounts the rows on screen, plus a small buffer for scrolling. TanStack Table handles the table logic, and the virtualization layer decides which rows exist in the DOM right now.

The two techniques solve different problems:

Server-side pagination controls how much data travels from the database to the browser.
Virtualization controls how much the browser renders.

So you test both: API response times and rendering.

Problem 3: the data changes while someone is looking at it

A shipment moves to a new status. An ETA slips. A carrier sends an update. If the screen shows old data, the operator decides based on a stale picture, and that’s the problem LogiCore was built to fix.

We handled this with background polling. A Zustand store fetches fresh data from the REST API on a schedule, and the badges, ETA drift indicators and timestamps update from it. “Last Updated” shows the latest carrier update, not a cached value.

The tricky part here is UX. If a badge changes while someone reads the list, the table shouldn’t reset their filters or scroll position. Polling also raises its own questions: how often to refresh, what to do with failed requests, and whether to keep polling when nobody is at the screen.

Polling fit LogiCore’s update rhythm. A product that needs second-by-second updates might be better off with WebSockets or server-sent events.

The backend decides how fast the table feels

A slow query makes even a well-tuned React table feel broken. So a lot of the speed work happened below the UI.

On the inventory screen, a multi-location SKU expands with a scoped REST call that fetches only that item’s child records. The first load stays at 100 rows, no matter how deep the data goes. The warehouse location tree loads the same way, one level at a time, from facility down to shelf.

Filters by client, warehouse or SKU run through Prisma’s dynamic where clauses. That way we avoid raw SQL and still support any filter combination. For the KPI cards, PostgreSQL window functions calculate week-over-week changes inside the database, and the frontend just shows the result.

Design and performance are one conversation

More columns don’t make a table more useful. They make it harder to scan. We gave status and timing a fixed place in each row, because that’s what operators check first.

Every design choice here has a frontend cost. Columns decide how heavy each cell is. Filters decide what the API has to query. And the design system needs states for loading and errors, not only the happy path.

What came out of it

Before launch, our QA team ran stress tests under heavy load, and the platform held at 100% stability. The office and the warehouse now work from the same live data. Managers see transit delays and stock shortages as they happen, so they fix problems before those cost money. Daily shipping decisions got 2x faster.

Where to start with your own table

If you’re building a B2B SaaS product with big tables, start with three questions. How much data does the screen request? How much does it render? What happens when the records change? The answers usually point to the next engineering decision.

FAQ

How do you make a React table fast with thousands of records?
Combine server-side pagination with row virtualization. Pagination limits what the API sends, and virtualization limits what the browser draws. On LogiCore, we used both with TanStack Table.

Should a logistics dashboard use polling or WebSockets?
It depends on how fast the data changes. Polling worked for LogiCore’s shipment statuses and ETAs. If operators need second-by-second updates, WebSockets or server-sent events fit better.

What should I look for in a team building custom warehouse management software?
Look for a team that covers design, backend and QA together, because table speed depends on the database as much as on the UI. UITOP built LogiCore that way, and the platform held 100% stability under peak-load stress tests.

About the project

LogiCore is a logistics and warehouse management platform designed and built by UITOP, a product design and development studio for complex B2B software.

Case study: https://uitop.design/case-studies/logicore/