DEV Community: Vladimir Simić

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

Vladimir Simić — Tue, 23 Jun 2026 08:54:19 +0000

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.

Why Your Laravel + Inertia.js Fetch Requests Fail with 419 After Save

Vladimir Simić — Thu, 16 Apr 2026 08:52:20 +0000

After a save or reset action, clicking "Preview" returns a 419 Page Expired — even though the page looks fine and you're clearly authenticated. Here's why, and the two-line fix.

The Setup
A settings page uses Inertia.js for save/reset (router.patch / router.delete) and a plain fetch() POST for a live email preview endpoint. The fetch manually reads the CSRF token from the meta tag:

headers: {
  'X-CSRF-TOKEN': (document.querySelector('meta[name="csrf-token"]') as HTMLMetaElement)?.content ?? '',
}

This works on first load. After a save it breaks with 419.

Why It Breaks
Laravel's CSRF system works through a session-bound token. On every response, including Inertia partial responses, Laravel rotates the XSRF-TOKEN cookie to stay in sync with the session.

The meta[name="csrf-token"] tag is rendered once by Blade at initial page load:

<meta name="csrf-token" content="{{ csrf_token() }}">

Inertia never touches that tag. It manages CSRF itself via the XSRF-TOKEN cookie. The same way Axios does. So after an Inertia response, the cookie holds the current token, but the meta tag is stale. Any subsequent fetch() reading the meta tag sends an outdated token, and Laravel rejects it.

The Second Bug
Even if CSRF were fine, the code calls res.text() unconditionally:

setPreviewHtml(await res.text());

When Laravel returns 419, res.text() gets the "Page Expired" HTML error page, which gets rendered inside the iframe. The error looks like broken preview content rather than a clear failure, making it very confusing to diagnose.

The Fix
Two changes to fetchPreview:

const fetchPreview = async () => {
  setPreviewLoading(true);
  try {
    // Read the token Laravel actually keeps fresh — the XSRF-TOKEN cookie
    const xsrfToken = decodeURIComponent(
      document.cookie
        .split('; ')
        .find((c) => c.startsWith('XSRF-TOKEN='))
        ?.split('=')[1] ?? '',
    );

    const res = await fetch(preview(templateKey).url, {
      method: 'POST',
      credentials: 'same-origin',
      headers: {
        'Content-Type': 'application/json',
        'X-XSRF-TOKEN': xsrfToken,        // ← correct header name
      },
      body: JSON.stringify({ locale: activeLocale, body: currentForm.body }),
    });

    if (!res.ok) {                         // ← don't render error HTML in iframe
      toast.error(t('common:failed_to_update'));
      return;
    }

    setPreviewHtml(await res.text());
  } catch {
    toast.error(t('common:failed_to_update'));
  } finally {
    setPreviewLoading(false);
  }
};

Two things changed:

X-CSRF-TOKEN → X-XSRF-TOKEN, reading from the cookie Laravel keeps fresh instead of the stale Blade meta tag.
if (!res.ok) guard - prevents error HTML from leaking into the iframe.

Why X-XSRF-TOKEN Works
Laravel's VerifyCsrfToken middleware checks for a valid token in two places:

_token field in the request body
X-CSRF-TOKEN header (raw token)
X-XSRF-TOKEN header (encrypted cookie value — automatically decrypted and verified)

The cookie is HttpOnly: false intentionally so JavaScript can read it. Inertia, Axios, and now your fetch all use this same mechanism.

Key Takeaway
When mixing Inertia navigation with manual fetch() calls in the same page:

Don't read meta[name="csrf-token"] — it's stale after any Inertia response.
Do read the XSRF-TOKEN cookie and send it as X-XSRF-TOKEN.
Always check res.ok before rendering a response body anywhere visible to the user.

I built a CLI that turns your git commits into social media posts

Vladimir Simić — Wed, 15 Apr 2026 08:59:29 +0000

The problem

Every week I ship things. Features, fixes, refactors. It's all there in git.

But writing a post about it? I'd either skip it entirely or spend 20 minutes staring at a blank box writing something that sounded nothing like me.

I knew what I built. Git knew what I built. The gap was just turning one into the other.

What I built

commitpost — a CLI that reads your git history, sends it to Claude AI, and writes a post in your voice. Optionally generates a cover image with your actual code as the background.

npm install -g commitpost
commitpost generate --include-image

That's it. One command. Post and image ready to copy-paste.

How it works

Runs git log --author --since to grab your recent commits
Sends them to Claude with your tone profile (a writing sample you set once)
Generates the post text
Extracts a real changed file from your commits for the cover image
Syntax-highlights it, applies blur, overlays the headline
Outputs a 1200×627px PNG ready for LinkedIn, Bluesky, or X

The interesting technical parts

Cover image without a browser

My first instinct was Puppeteer. Installed it, no Chrome binary. Pivoted to satori (Vercel's JSX→SVG renderer) + @resvg/resvg-js (Rust SVG→PNG) + sharp for compositing.

No headless browser. No Electron. Pure Node, works anywhere.

Blurring code correctly
Blurring sounds simple. It wasn't.

SVG feGaussianBlur clips at element boundaries — above ~sigma 20, no visible effect. Switched to sharp.blur(). But blurring a transparent PNG destroys the alpha channel and the layer disappears entirely when composited.

The fix: render background + code as one solid image first, then blur. Solid pixels blur correctly. Then composite the UI (headline, author) on top as a separate transparent layer.

Code that starts at something meaningful

Initially the image showed the first 20 lines of a file — which is always imports and require statements. Nobody wants to see import React from 'react' as their cover image.

Added findMeaningfulStartLine() — scans for the first class/function definition per language and starts there instead. Works for JS/TS, PHP, Python, Ruby, Java, Go, Rust, C#.

Tone profiles
One-time setup: paste a writing sample (old blog post, previous tweet, anything). Stored in ~/.commitpost/config.json. Every generated post runs through that sample as a style guide. Posts sound like you, not like ChatGPT.

The meta moment

I used commitpost to generate the LinkedIn post announcing commitpost. It worked.

Try it

# Install
npm install -g commitpost

# Set your API key (Anthropic)
commitpost config --set-key sk-ant-...

# Generate
commitpost generate

# With cover image
commitpost generate --include-image --image-style dark_code

GitHub: vsimke/commitpost
npm: commitpost

Post length is configurable (--length short/medium/long), there are 4 image styles, and 5 built-in tone profiles if you don't want to set up your own.

Open source, MIT. Would love feedback — especially from people using it on non-JS projects.