Vladimir Simić

Posted on Jun 23

When a Single URL Stops Being Enough: Multi-Table Pages in Inertia.js

#webdev #javascript #fullstack #tutorial

Two Tables, One URL: Solving Inertia.js State Collisions

If you've worked with Inertia.js + TanStack Table for server-side filtering and pagination, you know how satisfying the pattern feels.

A single router.get() call gives you a lot for free:

Filter state lives in the URL
Links are shareable
Browser back/forward works out of the box
Sorting, pagination, and filtering are all server-driven

It's a great default — until you need two independent tables on the same page.

The Problem

Picture a typical admin dashboard with a Users table and an Orders table. Both support filtering, sorting, and pagination. Naturally, you reach for the same Inertia pattern you've been using:

router.get('/dashboard', {
  page: 3,
  sortby: 'name',
  status: 'active'
})

That works beautifully for one table. With two, the URL becomes a shared state container — and things start to collide.

When the Users table navigates to page 3:

/dashboard?users_page=3

What happens to the Orders filters? Without extra care, they get reset or overwritten.

Option 1: Namespace Your Parameters

The most obvious fix is prefixing every parameter by table:

users_page=3&users_sort=name
orders_page=2&orders_status=paid

It works. But every filter hook, every query builder, and every table abstraction now needs to understand namespaced parameters. In my experience, that complexity compounds quickly and adds friction faster than it adds value.

Option 2: Give Each Table Its Own Request

Instead of routing all table interactions through router.get(), I switched to axios.get() per table.

Each table gets:

Its own dedicated endpoint
Its own local state
Its own independent requests

No shared URL, no collisions.

The Hook

The core of the pattern is a reusable useDataTable hook:

export function useDataTable<TData>({
  initialData,
  endpoint,
  columns,
}) {
  const [tableData, setTableData] = useState(initialData)
  const [sorting, setSorting] = useState([])
  const [columnFilters, setColumnFilters] = useState([])
  const [pagination, setPagination] = useState({
    pageIndex: 0,
    pageSize: 50,
  })

  const fetchData = useDebounce(async () => {
    const { data } = await axios.get(endpoint, {
      params: {
        filters: Object.fromEntries(
          columnFilters.map(({ id, value }) => [id, value])
        ),
        page: pagination.pageIndex + 1,
        sortby: sorting[0]?.id,
        sort: sorting[0]?.desc ? 'desc' : 'asc',
      },
    })

    setTableData(data)
  }, 300)

  useEffect(() => {
    fetchData()
  }, [sorting, pagination, columnFilters])

  return useReactTable({
    data: tableData.data,
    rowCount: tableData.total,
    manualFiltering: true,
    manualPagination: true,
    manualSorting: true,
  })
}

Why This Works Well

Tables are truly independent. Paginate one, and the other doesn't flinch. That's exactly the behavior you want from an admin dashboard.

The first render still comes from Inertia. Initial data is hydrated from Inertia props:

const [tableData, setTableData] = useState(initialData)

No loading spinner on mount, no client-side waterfall. The page feels fast from the start — the best of both worlds.

CSRF is handled automatically. Because axios reads Laravel's XSRF cookie by default, there's no extra ceremony. It just works.

The Tradeoff

This pattern makes a deliberate trade.

What you gain: independent tables, simpler code than full query namespacing, and cleaner admin pages.

What you give up: filter state is no longer in the URL. Filters aren't bookmarkable. Shared links won't preserve table state.

Whether that matters depends entirely on your use case.

When to Use Each Approach

Stick with router.get() + URL state when:

You're building a public-facing search or filter page
Users need to share or bookmark filtered views
Deep-linking is part of the product (product catalogs, reporting screens, search results)

Switch to axios per table when:

It's internal admin tooling
The page has multiple independent data views
URL shareability simply isn't a requirement

This Isn't a Criticism of Inertia

I almost called this post "When Inertia isn't enough" — but that framing misses the point.

Inertia is excellent. This is just a case where a single URL stops being the right state container for the job. Recognizing that distinction is the whole insight.

How Are You Handling This?

If you're managing multiple server-side tables with Inertia, I'd love to know your approach. Are you namespacing query params? Using local state and axios? Something smarter?

Drop a comment — if this is a common enough pain point, I'm considering packaging the hook or writing a more detailed follow-up.

DEV Community