SvGrid Blog

Building a Real-Time Trading Grid in Svelte

Kamelia M — Sat, 29 Aug 2026 07:12:00 GMT

A busy trading feed will push 150 price ticks per second across 100+ instruments. A new message every 6-7 ms. The frame budget is 16 ms. If you write a Svelte state update on every single message, you are scheduling ten reactive microtasks per frame and the grid bogs down before the market even opens.

The fix is not complicated, but it is non-obvious: never write to $state directly from a WebSocket callback. Collect all incoming ticks into a plain Map and flush the whole batch in a single requestAnimationFrame. That one change drops render overhead by roughly 80% on a busy feed, and it is the foundation everything else builds on.

Why plain mutation is not enough

Svelte 5 reactivity is fine-grained - change rows[i].price and only cells reading price update. But rows[i].price = x does not actually trigger anything, because the object reference on rows[i] did not change. You have to replace the object:

rows[i] = { ...rows[i], price: newPrice }

This is the correct pattern but it makes the "update on every tick" problem worse, not better, because now you are creating a new object reference for every message. On a 150 tick/second feed that is 150 object allocations and 150 Svelte reactive flushes per second. The rAF batcher solves both problems at once: it coalesces multiple ticks for the same symbol and limits total flushes to the display refresh rate.

The tick batcher

// feed.ts
export type Direction = 'up' | 'down' | null

export type Instrument = {
  id: string
  symbol: string
  sector: string
  price: number
  change: number      // % from open, e.g. 2.34 or -1.07
  volume: number
  direction: Direction
  flashAt: number     // timestamp of last tick, used to expire flash class
}

export function connectFeed(
  rows: Instrument[],
  onFlush: () => void,
): () => void {
  // Build a lookup so we never scan the array on every tick
  const index = new Map()
  rows.forEach((r, i) => index.set(r.id, i))

  const pending = new Map()
  let scheduled = false

  function flush() {
    scheduled = false
    const now = Date.now()
    for (const [id, tick] of pending) {
      const i = index.get(id)
      if (i == null) continue
      const prev = rows[i]!
      rows[i] = {
        ...prev,
        price: tick.price,
        change: tick.change,
        direction: tick.price > prev.price ? 'up'
               : tick.price < prev.price ? 'down'
               : null,
        flashAt: now,
      }
    }
    pending.clear()
    onFlush()
  }

  // Replace this block with a real WebSocket in production:
  // const ws = new WebSocket('wss://feed.example.com/ticks')
  // ws.onmessage = (e) => { ... }
  let prng = 0xC0FFEE42
  function rand() {
    prng = (prng * 1664525 + 1013904223) >>> 0
    return prng / 0xFFFFFFFF
  }

  const timer = setInterval(() => {
    const i = Math.floor(rand() * rows.length)
    const row = rows[i]!
    pending.set(row.id, {
      price: Math.max(0.01, row.price + (rand() - 0.49) * 2.5),
      change: row.change + (rand() - 0.5) * 0.4,
    })
    if (!scheduled) {
      scheduled = true
      requestAnimationFrame(flush)
    }
  }, 7) // simulates ~143 messages/second

  return () => clearInterval(timer)
}

Two details worth noting. First, the index map avoids an Array.findIndex call on every tick - at 150 ticks/second that would be 150 linear scans per second on top of everything else. Second, if two ticks for the same symbol arrive before the next rAF, the second overwrites the first in pending. The grid sees one update per symbol per frame, which is exactly right. Intermediate prices within a single 16 ms frame are invisible to a human anyway.

Wiring to SvGrid

Conditional formatting on the change column drives profit/loss color without any snippet overhead. The price column gets a flash class from a cellClass function that reads the direction field.




   { api = a }}
  />

Stable row identity and why it matters

The rowId="id" prop is not optional in this use case. Without it, SvGrid keys rows by array index. After the user sorts by change to find today's biggest movers, the row at index 0 is now a different instrument than before. A tick arrives for CYBR, updates rows[i] by the old index, and patches the wrong DOM node.

With rowId, the virtualization layer tracks each row by its id string. Sort order changes which DOM node is visible at position 0, but each DOM node stays bound to the same instrument across re-renders. This also means the grid does not tear down and rebuild DOM nodes during a sort - it repositions them. At 12 rows that is invisible. At 200 rows the difference is measurable.

The flash cycle

Flash is entirely CSS-driven. When a tick arrives, direction is set to 'up' or 'down'. The cellClass function returns 'flash-up' or 'flash-down', which applies a background color. The CSS transition: background-color 400ms ease-out then animates that color back toward transparent over 400 ms.

The onFlush callback does a single pass over all rows and clears direction on any row whose flashAt is more than 400 ms old. No setTimeout per tick, no timer accumulation. At 143 ticks/second across 12 rows you would otherwise accumulate over 100,000 live timers in twelve minutes. The single-pass approach keeps the timer count at exactly one.

Keeping format separate from value

The format option on the price column controls display only. The underlying cell value stays a raw number. This matters because SvGrid uses the raw value for sorting: if you pre-format price as the string "$184.12" and store that in the accessor, lexicographic sort puts "$9.99" after "$99.00" and before "$100.00". Always store the number, let format handle rendering.

The same logic applies to change. A percent change of -0.07 sorts correctly between -0.08 and -0.06 as a number. Formatted as "-0.07%" it sorts as a string and the ordering breaks for negative values.

Scaling past 12 rows

The patterns above handle 200 rows at 150 ticks/second comfortably on a mid-range laptop. The rAF flush rate is capped at 60fps regardless of feed speed. The index map makes per-tick row lookup O(1). Object allocation per frame is bounded by the number of distinct symbols that ticked, not the feed rate.

If you need to go further - say 1,000 rows with per-cell sparklines - the next lever is restricting which rows are actually reactive. Keep the visible window in a separate $state slice and only update rows whose index falls in the virtualized viewport. The api.getDisplayedRows() call returns exactly that set, updated after each sort or scroll.

// Only update rows currently visible in the viewport
const displayedIds = new Set(api.getDisplayedRows().map((r) => r.id))
for (const [id, tick] of pending) {
  if (!displayedIds.has(id)) continue   // skip off-screen rows entirely
  // ... apply update
}

Off-screen rows still hold correct data - their price field updates in the backing array via the index map - but Svelte never needs to schedule a DOM update for them. When the user scrolls, the virtualizer reads the current values from the array and renders fresh cells. No visible staleness, significantly lower CPU on very large boards.

Reactivity with Large Arrays and Objects in Svelte 5

Victor Vidolov — Fri, 28 Aug 2026 07:12:00 GMT

Every Svelte 5 object you put in $state gets wrapped in a Proxy. One object, negligible. Fifty thousand objects with ten properties each - that is 500,000 proxy handlers allocated before the first row paints. This is the quiet culprit behind grids that stutter on initial load even when the renderer itself is virtualized and fast.

Why deep proxying hurts at scale

Svelte 5's fine-grained reactivity works by intercepting property reads and writes on every object in your state tree. The upside: write rows[42].status = 'shipped' and only the single cell displaying that status updates. The downside: building that dependency graph requires walking every object recursively at construction time.

Measure it with a quick benchmark. Drop 50,000 plain objects into $state versus $state.raw and time the assignment:

// With deep proxy (plain $state):
// ~90-130 ms on a mid-range laptop
let rows = $state(await fetchOrders()) // Svelte recurses into all 50k objects

// With $state.raw:
// ~1-3 ms - Svelte stores the reference, nothing more
let rows = $state.raw(await fetchOrders())

The numbers vary by machine and object shape, but the gap is always large enough to be visible to users. A 100 ms freeze before any row appears is not a rendering problem - it is a state initialization problem.

SvGrid's virtualizer only ever reads 20 to 60 rows at a time, so the DOM work scales regardless. But the proxy wrapping happens before the virtualizer touches anything. Virtualization and $state.raw solve two different problems; you need both for large server-driven datasets.

When to reach for `$state.raw`

The rule is straightforward: if your code replaces the array as a unit rather than mutating individual elements, use $state.raw. The classic scenario is a paginated server grid where each page load replaces the whole dataset:



{#if loading}
  Loading...
{/if}

 { api = g }}
  style="height: 600px"
/>


  
  Page {currentPage}

This pattern loads fast at any page size because Svelte never recurses into the rows array. The grid gets a raw array, the virtualizer slices it for display, and the whole thing stays off the reactivity tracking graph until the next page reassignment.

Editing rows without rebuilding the world

$state.raw imposes one firm rule: mutating an element in place does not trigger a rerender. rows[0].status = 'paid' silently does nothing visible. This trips people up the first time, usually in an edit callback.

The correct pattern is surgical replacement - create a new array with one new object, keep every other reference stable:

// Wrong: creates 50,000 new object references
// SvGrid's row model sees every row as changed and re-renders all of them
rows = rows.map(r => r.id === targetId ? { ...r, status: 'paid' } : { ...r })

// Also wrong: mutates in place on a $state.raw value - no rerender at all
rows.find(r => r.id === targetId)!.status = 'paid'

// Right: one new object, 49,999 stable references
// SvGrid can diff the array and only update the changed row
function updateStatus(id: string, status: Order['status']) {
  const i = rows.findIndex(r => r.id === id)
  if (i === -1) return
  const next = rows.slice() // shallow copy of the array wrapper
  next[i] = { ...rows[i]!, status }
  rows = next
}

If you find yourself doing in-place edits frequently - inline cell editing, live form validation, optimistic UI updates - plain $state is the better tool. The proxy cost is real but the ergonomics pay it back. Use $state.raw for datasets that arrive from a server and get replaced wholesale; use plain $state for user-editable datasets that change field by field.

Live updates from a WebSocket feed

The wrong instinct when rows arrive from a WebSocket is to rebuild the array every time. At 5 messages per second on a 10,000-row dataset, each full reassignment triggers a rerender of the entire visible window even if only one row changed.

SvGrid's applyTransaction handles streaming inserts, updates, and removals without touching the rest of the display model:

let api = $state | null>(null)

function connectFeed() {
  const ws = new WebSocket('wss://orders.example.com/live')

  ws.onmessage = (event) => {
    const msg: { type: 'insert' | 'update' | 'delete'; row: Order } = JSON.parse(event.data)

    if (!api) return

    if (msg.type === 'insert') {
      api.applyTransaction({ add: [msg.row] })
    } else if (msg.type === 'update') {
      api.applyTransaction({ update: [msg.row] })
    } else if (msg.type === 'delete') {
      api.applyTransaction({ remove: [msg.row] })
    }
  }
}

This avoids the array reassignment entirely. SvGrid merges each transaction into the existing row model, re-derives sort and filter state for the affected rows only, and queues a targeted DOM update. At 50 messages per second you get smooth incremental updates rather than 50 full repaints.

Mixing `$state.raw` and `$state` in the same component

You do not have to choose one approach for an entire component. A practical pattern is raw state for the data and regular reactive state for UI concerns - selection, edit drafts, loading flags:

// Server data: raw, replaced as a unit
let rows = $state.raw([])

// UI state: fine-grained, mutated in place
let selectedIds = $state(new Set())
let editDraft = $state | null>(null)
let filterText = $state('')

// Derive the filtered view without touching rows itself
let visible = $derived(
  filterText.trim()
    ? rows.filter(r =>
        r.customer.toLowerCase().includes(filterText.toLowerCase()) ||
        r.sku.toLowerCase().includes(filterText.toLowerCase())
      )
    : rows
)

$derived reading a $state.raw array registers a dependency on the array reference, not its contents. So visible recomputes when rows or filterText changes, but not when you mutate a row element in place - which is consistent with the raw contract and actually what you want here.

The threshold question

Below roughly 5,000 rows on a modern machine, the difference between $state and $state.raw is under 5 ms and not worth the ergonomic tradeoff. Profile with performance.mark around your state assignment if you are unsure where your dataset lands. If you do not see a gap, use plain $state and enjoy the simpler mutation model.

Above 20,000 rows, the proxy overhead is consistently user-visible on mid-range hardware. At 50,000 rows it is the dominant cost on page load - not the network, not the rendering, not the sort. Switch to $state.raw, adopt the surgical replacement pattern for edits, and use applyTransaction for streaming updates. The three together keep a large grid feeling immediate regardless of dataset size.

Building a Project / Task Board with a Svelte Data Grid

Victor Vidolov — Thu, 27 Aug 2026 07:12:00 GMT

Kanban boards look great in demos. In practice, when a sprint has 80 tasks spread across 6 engineers, a drag-and-drop board becomes a scrolling nightmare. A grid view with grouping, inline editing, and fast keyboard navigation handles that volume much better. I've seen teams switch from purpose-built project tools to a well-configured data grid and never look back.

A project breakdown as tree rows in SvGrid.

The data model that makes everything else easier

Before writing a single column definition, get the data shape right. Tasks with subtasks need a parentId field - SvGrid's tree data feature uses this to build the hierarchy client-side. You don't need a recursive structure; a flat array with parent references is enough.

// types.ts
export interface Task {
  id: string
  parentId: string | null
  title: string
  assignee: string
  status: 'todo' | 'in-progress' | 'done' | 'blocked'
  priority: 'low' | 'medium' | 'high' | 'critical'
  dueDate: string | null  // ISO date string
  storyPoints: number | null
  sprint: string
}

The parentId: null tasks are root-level; anything with a parentId is a subtask. This flat-with-references pattern is what most APIs return anyway, so you can often skip a transformation step.

Column definitions: what to show and how to edit it

The column setup does most of the heavy lifting. Status and priority are the most-edited fields in any task board, so make them fast to edit in place rather than opening a dialog.



{#snippet statusCell({ value }: { value: string })}
  
    {value}
  
{/snippet}

{#snippet priorityCell({ value }: { value: string })}
  
    ● {value}
  
{/snippet}

 { api = a }}
/>

The conditionalFormat on the due date column is one of those small details that makes a task board genuinely useful - overdue tasks turn red automatically without any custom cell renderer.

Grouping by status gives you a lightweight board view

Grouping is where the grid earns its keep over a plain table. Group by status and you get something that looks like a Kanban board but lets you sort within each group, bulk-select, and see aggregated story points per column.

// Toggle grouping mode programmatically
function groupByStatus() {
  api.setGroupBy(['status'])
  api.expandAllGroups()
}

function groupByAssignee() {
  api.setGroupBy(['assignee'])
  api.expandAllGroups()
}

function groupBySprint() {
  api.setGroupBy(['sprint', 'status'])
  api.expandAllGroups()
}

function clearGrouping() {
  api.setGroupBy([])
}

The two-level grouping ['sprint', 'status'] is particularly useful for sprint planning - you see each sprint broken into status buckets with counts and story point totals per group.

Subtasks as tree rows

SvGrid handles tree data by reading parentId and building the hierarchy automatically. Parent tasks show expand/collapse controls; subtasks are indented. You get rollup aggregation on the parent - so if a parent has 3 done subtasks out of 5, you can show "3/5" in a custom cell.

The tree feature activates when you pass a getSubRows option. For a flat array with parentId:

import SvGrid from '@svgrid/grid'

// SvGrid resolves the hierarchy from your flat data
// Pass getSubRows to define how children are found
const gridOptions = {
  data: tasks,     // flat Task[] with parentId
  columns,
  getSubRows: (row: Task, allRows: Task[]) =>
    allRows.filter(r => r.parentId === row.id),
}

One thing to watch: if your dataset is large (thousands of tasks), the getSubRows traversal runs on every render cycle. For that scale, pre-build a children map once and reference it:

const childMap = new Map()
for (const task of tasks) {
  const bucket = childMap.get(task.parentId) ?? []
  bucket.push(task)
  childMap.set(task.parentId, bucket)
}

const getSubRows = (row: Task) => childMap.get(row.id) ?? []

The pre-built map turns O(n) per-row lookups into O(1). For 5,000 tasks with deep subtask nesting, this is the difference between 60fps and noticeable jank.

Saving views so engineers can get back to their context

Every engineer has a personal filter they run every day: "show me my in-progress tasks for Sprint 12, sorted by priority". Making that view persistent costs three lines:

import { createNamedViews, localStorageViews } from '@svgrid/grid'

const views = createNamedViews({
  storage: localStorageViews('task-board'),
})

// Save current filters, grouping, column order, and sort
function saveView(name: string) {
  const state = api.getState()
  views.save(name, state)
}

// Restore a saved view
function loadView(name: string) {
  const state = views.load(name)
  if (state) api.setState(state)
}

// Get the list of saved view names for a dropdown
const savedViews = views.list()

getState() captures filters, sorts, grouping, column widths, visibility, and pinning in one call. setState() restores all of it. You can serialize this to a URL for shareable views, or push it to a database so views survive across devices.

Bulk operations for fast triage

When a sprint ends and you need to move 15 tasks from "in-progress" to "done", selecting each task individually is painful. Select all with Ctrl+A, or select a range, then apply a transaction:

function bulkMarkDone() {
  const selected = api.getSelectedRows()
  const updates = selected.map(row => ({
    ...row,
    status: 'done' as const,
  }))
  api.applyTransaction({ update: updates })
}

function bulkReassign(newAssignee: string) {
  const selected = api.getSelectedRows()
  api.applyTransaction({
    update: selected.map(row => ({ ...row, assignee: newAssignee })),
  })
}

applyTransaction is optimistic - the grid updates instantly. Wire up your API call alongside it and roll back if the server rejects it. That pattern keeps the UI snappy even with a slow backend.

When a dedicated tool makes more sense

The grid approach works well when you need speed, density, and customization. It struggles when your primary workflow is visual drag-and-drop ordering (a real Kanban board is better for that), or when non-technical users need a polished no-config experience.

If your users are engineers or analysts who live in spreadsheets, the grid will feel natural. If they're used to a visual board, expect a learning curve. The good news is you can ship both - a Kanban view and a grid view pulling from the same data - because the grid is just a rendering layer over your task state. Setting the board prop renders these same rows as draggable cards; see building a Kanban board in Svelte 5 for that side of it.

The conditional row highlighting for blocked tasks, the overdue date coloring, the instant group-by toggle - these are the details that make an internal tool feel finished. They're also the kind of details that take weeks to build in a custom table but come out of the box here.

Progress and Percentage Bar Cells in SvGrid

Victor Vidolov — Wed, 26 Aug 2026 07:12:00 GMT

Raw numbers in a data grid are hard to scan. A column full of values like 73, 12, 98, 41 tells you almost nothing at a glance - you have to read each one and carry context from cell to cell. A bar changes that. You see 98 as "basically done" and 12 as "barely started" before your brain even processes the digits.

SvGrid cells accept any Svelte snippet, so a progress bar is just HTML and a couple of CSS rules. The trick is knowing which concerns belong to the cell renderer and which belong to the column definition - get that boundary wrong and you lose sorting, filtering, and conditional formatting.

The bar lives in the snippet, the value lives in the field

This is the only rule worth internalizing before writing any custom cell: the column's field or accessorFn owns the value. The snippet owns the presentation. If you compute or transform the value inside your snippet, you break every feature that reads the column's value - sorting, filtering, column stats, copy-to-clipboard.

Here is the correct pattern:



{#snippet ProgressCell(p: { value: number })}
  {@const pct = Math.max(0, Math.min(100, p.value))}
  
    
    {pct}%
  
{/snippet}

{@const columns: ColumnDef[] = [
  { id: 'task', field: 'task', header: 'Task', width: 200 },
  {
    id: 'progress',
    field: 'progress',
    header: 'Progress',
    width: 160,
    cell: (ctx) => renderSnippet(ProgressCell, { value: ctx.getValue() }),
  },
]}

The column reads from field: 'progress', so clicking the header sorts by the real number. The snippet receives the value and renders the bar. These concerns never mix.

Styling the track and fill

CSS variables from SvGrid's token set keep the bar consistent with whatever theme is active:

.progress-track {
  position: relative;
  height: 16px;
  border-radius: 8px;
  background: color-mix(in srgb, var(--sg-fg) 8%, transparent);
  overflow: hidden;
  margin: 0 4px;
}

.progress-fill {
  height: 100%;
  border-radius: 8px;
  background: var(--sg-accent);
  transition: width 150ms ease;
}

.progress-label {
  position: absolute;
  inset: 0;
  display: flex;
  align-items: center;
  justify-content: center;
  font-size: 11px;
  font-weight: 600;
  color: var(--sg-fg);
  mix-blend-mode: difference;
}

mix-blend-mode: difference on the label keeps the text readable whether it sits on the filled portion or the empty track. If you find blend modes unreliable in your target browsers, use two overlapping spans instead - one clipped to the fill region and one for the empty region, each with a contrasting color.

Color thresholds

A single-color bar is better than a number. A threshold-colored bar is better still. Color maps progress to status: green means on track, amber means at risk, red means blocked. You can drive this entirely from the snippet, since color is presentation:

{#snippet ThresholdBar(p: { value: number })}
  {@const pct = Math.max(0, Math.min(100, p.value))}
  {@const color =
    pct >= 80 ? 'var(--color-success, #22c55e)' :
    pct >= 40 ? 'var(--color-warning, #f59e0b)' :
                'var(--color-danger,  #ef4444)'}

  
    
    {pct}%
  
{/snippet}

The thresholds are expressed as plain numbers - easy to adjust, easy to read. If your threshold boundaries come from server config or user preferences, pull them in through a prop or a context store rather than hardcoding them.

When you want SvGrid's conditional formatting instead

If you want the whole cell - background, text color, font weight - to change based on the value, the conditionalFormat column option is the cleaner path. It avoids writing threshold logic inside your snippet:

import { resolveCellFormat, type ColumnDef } from '@svgrid/grid'

const columns: ColumnDef[] = [
  {
    id: 'progress',
    field: 'progress',
    header: 'Progress',
    width: 160,
    cell: (ctx) => renderSnippet(ProgressCell, { value: ctx.getValue() }),
    conditionalFormat: [
      {
        condition: ({ value }) => value < 40,
        style: { color: '#ef4444', fontWeight: '700' },
      },
      {
        condition: ({ value }) => value >= 80,
        style: { color: '#16a34a' },
      },
    ],
  },
]

The conditional format applies to the cell wrapper, so it affects the label text and can tint the cell background independently of the bar fill. Use it when the visual state should be obvious even before the bar width registers, such as a status overview where users scan the label color more than the bar length.

Stacked and segmented variants

Some use cases need a segmented bar - completed, in-progress, and blocked as three colored segments in one cell. The data shape changes (you need three fields or a structured value), but the rendering principle stays the same:

{#snippet SegmentedBar(p: { done: number; inProgress: number; blocked: number })}
  {@const total = p.done + p.inProgress + p.blocked}
  {@const pDone = total > 0 ? (p.done / total) * 100 : 0}
  {@const pActive = total > 0 ? (p.inProgress / total) * 100 : 0}
  {@const pBlocked = total > 0 ? (p.blocked / total) * 100 : 0}

  
    
    
    
  
{/snippet}

.seg-track { display: flex; height: 14px; border-radius: 7px; overflow: hidden; gap: 1px; }
.seg       { height: 100%; }
.seg.done    { background: #22c55e; }
.seg.active  { background: #f59e0b; }
.seg.blocked { background: #ef4444; }

For segmented bars the field on the column still matters - point it at whichever sub-value you want to sort by. If you want to sort by "done count", set field: 'done' and the accessor pulls from the right property.

One thing to watch with virtualization

SvGrid virtualizes rows by default. When a row scrolls out of view its DOM node is reused. If your progress bar uses a CSS transition on width, you may briefly see the fill animate from the previous row's value to the new one as cells are recycled. This is usually imperceptible at normal scroll speeds, but if it bothers you, either remove the transition or reset it on mount:

{#snippet ProgressCell(p: { value: number })}
  {@const pct = Math.max(0, Math.min(100, p.value))}
  
    
  
{/snippet}

Removing the transition entirely is the pragmatic call for most grids. Reserve animated bars for dashboards where rows do not scroll - where you are showing live updates to a fixed set of items and the animation communicates that a value just changed.

Progress bars are one of those additions that take ten minutes to build and immediately make a grid feel like a product rather than a spreadsheet. The pattern scales from a single completion column to a full project-tracking view with segment bars, threshold colors, and sorted-by-value headers.

svelte-headless-table and the Svelte 5 upgrade: your three options

Boyko Markov — Wed, 26 Aug 2026 07:12:00 GMT

If you are upgrading a Svelte app to 5 and svelte-headless-table is in your package.json, you have already hit the wall: the install warns about a peer conflict, and nobody has published a fix.

This post is the decision, not the sales pitch. We maintain SvGrid, which is one of the three options below - and for a good number of you it is the wrong one. The recommendation logic here is the same one we would give you in a GitHub thread.

What actually broke

Three facts, all checkable on the registry as of 26 August 2026:

The last release of svelte-headless-table is 0.18.3, published 28 October 2024. That is 22 months of silence.
It declares peerDependencies: { "svelte": "^4.0.0" }. Installing it next to Svelte 5 is a peer-range conflict - an ERESOLVE error on npm, a warning-then-breakage on pnpm.
It still pulls roughly 64,000 downloads a month. This is not a dead library with three users. It is a widely used one that stopped moving.

One thing that is not broken, despite what a lot of migration posts (including, until today, one of our own docs pages) claim: Svelte 5 did not remove let: or slots. They are deprecated in favour of snippets and they still render. The official migration guide is explicit that they "continue to work". So your blocks are not a compile error.

The real friction is narrower and worth stating precisely, because it changes the decision:

The peer range is a hard install-time stop.
Slotted content cannot be passed to a component that renders with {@render ...}. The moment your codebase moves to snippets, the boundary between your runes components and headless-table's slot-based Subscribe starts to chafe.
Nothing is coming. Stores still work in Svelte 5, so this is not urgent in the way a breaking change would be - but you are building on a library whose maintainer has moved on.

That combination means: you have time, you are not in a crisis, and you should pick deliberately rather than reflexively rewriting.

Option 1: the maintained fork

@humanspeak/svelte-headless-table - v6.0.13, published 6 August 2026, peerDependencies: svelte ^5.30.0. Same API.

npm remove svelte-headless-table
npm i @humanspeak/svelte-headless-table

Then change your import paths. That is the migration.

Pick this if your table works and you only need it to install on Svelte 5. It is the cheapest path by a wide margin, and "cheapest path that works" is usually the correct engineering answer. Roughly 8,900 downloads a month say others reached the same conclusion.

The honest risk: it is a fork with one maintainer, so you are trading a stalled upstream for a smaller one. Check its commit activity before you commit to it - if that is not a trade you want to make, keep reading.

Option 2: TanStack Table v9

@tanstack/svelte-table - v9.1.2, published 9 August 2026, peerDependencies: svelte ^5.0.0. Around 194,000 downloads a month.

The category leader now has a first-party Svelte 5 adapter, so the old "TanStack has no Svelte 5 story" advice is out of date. If you like headless tables as a category - you want to own the markup, and the library should only own the row model - this is the largest, best-funded option in that category.

Pick this if you want to stay headless and you value ecosystem size. The concepts port over cleanly: column defs are column defs, and headless-table's plugins map onto TanStack's row models.

The honest cost: it is still headless-only. Every

, , and remains yours to write, style, virtualize, and make accessible. You are re-doing the markup work, not inheriting it. And v9 is a real migration - the API is not headless-table's.

Option 3: a grid that ships the renderer

This is us. SvGrid is Svelte 5 runes-native, MIT-licensed at the core, and it inverts the trade: instead of a row model plus your markup, you get a component with virtualization, sticky headers, keyboard navigation, and ARIA already handled - with a headless core underneath at @svgrid/grid/core for when you do need the DOM.

npx @svgrid/migrate             # preview the changes
npx @svgrid/migrate src --write # apply them

The codemod translates column definitions and plugin config, deletes the Subscribe/Render scaffolding, and reports what it could not map instead of dropping it silently. Full detail in the migration guide.

Pick this if the markup is the part you are tired of. The clearest signal is if you have hand-rolled virtualization, a filter menu, or column resizing on top of headless-table and you resent maintaining them.

The honest cost: you give up DOM control at the component level, and some things genuinely do not come across - createRender(MyComponent) cell renderers become snippets, and custom plugins have no equivalent because there is no plugin system to port them into. That is a rewrite, not a migration. Advanced features (export, pivot, board and scheduler views) are a paid add-on; the grid itself is not.

Choosing

If this is you	Take
The table works; I just need Svelte 5 to install	The fork
I want to own the markup, with the biggest ecosystem behind me	TanStack v9
I am tired of maintaining table markup	A rendered grid
I depend on custom headless-table plugins	The fork - the others are a rewrite
My "table" is 20 rows and no interaction	None of them. An `{#each}` is less code

That last row is not a joke. A meaningful share of headless-table usage is a static list that never needed a table library, and the upgrade is a good moment to delete a dependency instead of replacing it.

The one thing not to do

Do not pin svelte@4 to avoid the decision. That trades a scoped afternoon of work now for a compounding one later, as the rest of your dependencies move to Svelte 5 and you fall off the upgrade path for every one of them. All three options above are live, maintained, and installable today - which is a better position than most stranded libraries leave their users in.

If you want the side-by-side on our option specifically, it is at SvGrid vs svelte-headless-table, including the cases where we tell you to use something else.

Porting a React MUI X DataGrid Screen to Svelte

Kamelia M — Tue, 25 Aug 2026 07:12:00 GMT

MUI X DataGrid is a solid grid for React apps. When teams migrate to Svelte 5, the grid screen is usually what they dread most - partly because of the Pro tier's API surface, partly because renderCell looks entangled with JSX in ways that seem hard to untangle. In practice, the porting work is more mechanical than it looks. The column model maps almost one-to-one, and a chunk of the React boilerplate just evaporates.

The column model, renamed

The biggest conceptual change is small in practice. GridColDef becomes ColumnDef, headerName becomes header, and that's mostly it for the basic fields.

// MUI X DataGrid (React)
import { GridColDef } from '@mui/x-data-grid'

const columns: GridColDef[] = [
  { field: 'id', headerName: 'ID', width: 80 },
  { field: 'name', headerName: 'Full Name', width: 200 },
  {
    field: 'salary',
    headerName: 'Salary',
    width: 130,
    type: 'number',
    valueFormatter: ({ value }) => `$${Number(value).toLocaleString()}`,
  },
  {
    field: 'department',
    headerName: 'Department',
    width: 160,
    valueGetter: (params) => params.row.dept?.name ?? '-',
  },
]

// SvGrid (Svelte 5)
import type { ColumnDef } from '@svgrid/grid'

const columns: ColumnDef[] = [
  { id: 'id', field: 'id', header: 'ID', width: 80 },
  { id: 'name', field: 'name', header: 'Full Name', width: 200 },
  {
    id: 'salary',
    field: 'salary',
    header: 'Salary',
    width: 130,
    type: 'number',
    format: { type: 'currency', currency: 'USD' },
  },
  {
    id: 'department',
    header: 'Department',
    width: 160,
    accessorFn: (row) => row.dept?.name ?? '-',
  },
]

valueGetter becomes accessorFn. valueFormatter becomes format for standard cases (currency, date, number precision) or a formatter function when you need custom logic. The id field is required in SvGrid - it drives keyed rendering under virtualization.

Here is the full concept map:

MUI X DataGrid	SvGrid
`rows` prop	`data` prop
`columns: GridColDef[]`	`columns: ColumnDef[]`
`headerName`	`header`
`valueGetter`	`accessorFn`
`valueFormatter`	`format` / `formatter`
`renderCell`	`cell` snippet
`renderEditCell`	`editorType` or custom editor
`sortingMode="server"`	`createServerDataSource`
`paginationModel` + `onPaginationModelChange`	`pageable` + `createServerDataSource`
DataGridPro pivot, Excel export	`@svgrid/enterprise`

Cell renderers: JSX to snippets

MUI X uses renderCell returning JSX. SvGrid uses Svelte 5 snippets. The mental model is the same; the syntax is different, and frankly cleaner once you have written a few.



{#snippet statusCell({ value }: { value: string })}
  {value}
{/snippet}

The snippet is defined in the same file and referenced directly in the column def. No callback wrapper, no import from a separate component. Svelte's snippet scoping means the badge class logic stays where you can see it.

Server-side data and the hooks that disappear

The React version of a server-side MUI X DataGrid typically involves useState for pagination and sort, useEffect to trigger fetches when those state values change, and a rowCount prop to tell the grid the true total. It ends up being 30-40 lines of wiring before you even write the fetch call.

SvGrid wraps this with createServerDataSource:

import { createServerDataSource } from '@svgrid/grid'

const ds = createServerDataSource({
  fetch: async ({ page, pageSize, sort, filters }) => {
    const params = new URLSearchParams({
      page: String(page),
      size: String(pageSize),
    })

    if (sort.length) {
      params.set('sortField', sort[0].field)
      params.set('sortDir', sort[0].direction)
    }

    for (const f of filters) {
      params.set(`filter_${f.field}`, f.value)
    }

    const res = await fetch(`/api/employees?${params}`)
    const json = await res.json()
    return { rows: json.data, total: json.total }
  },
})

Then the component is:

The useEffect dependency array, the rowCount state sync, the three separate model-change callbacks - none of that exists. The data source handles it. When sort or filter changes, the data source re-fetches automatically.

Editable cells

MUI X editable columns use editable: true on the column def and optionally renderEditCell for custom editors. SvGrid follows the same pattern: editable: true on the column and editorType for overriding the default editor.

const editableColumns: ColumnDef[] = [
  { id: 'name', field: 'name', header: 'Name', width: 180, editable: true },
  {
    id: 'salary',
    field: 'salary',
    header: 'Salary',
    width: 130,
    type: 'number',
    editable: true,
  },
  {
    id: 'status',
    field: 'status',
    header: 'Status',
    width: 140,
    editable: true,
    editorType: 'select',
    editorOptions: { items: ['active', 'inactive', 'pending'] },
  },
]

MUI X's processRowUpdate becomes SvGrid's onCellEdit callback or a reactive $effect on the data. Undo/redo (a MUI Premium feature) ships in SvGrid's free tier via api.undo() and api.redo().

What transfers and what does not

Most MUI X DataGrid functionality has a direct equivalent in SvGrid. The two cases that do not translate cleanly are the built-in tree data view and the column reorder animation. If your app relies heavily on either, factor that into the migration timeline.

Everything else transfers faster than expected. Svelte reactivity eliminates an entire class of state synchronization bugs that come from keeping pagination, sort, and filter state in separate useState calls that have to stay in sync. The server-side data source removes that problem at the source. Cell snippets are genuinely easier to read than renderCell callbacks once you stop expecting JSX syntax.

For apps with custom MUI X slot overrides deep in the theme layer, that part won't translate directly. You will need to rebuild those pieces with SvGrid's CSS custom properties (--sg-bg, --sg-accent, --sg-header-bg, --sg-border) and the headerCell snippet API. That is the part I would budget extra time for - not the column defs, not the cell renderers, but the theme customization layer if your design system relies on it heavily.

Pro and Premium features like pivot tables and Excel export map to @svgrid/enterprise. The free community tier covers sorting, filtering, grouping, virtualization, editing, and pagination - which handles the majority of real-world grid screens.

Paste from Excel into a Svelte Data Grid

Kamelia M — Mon, 24 Aug 2026 07:12:00 GMT

Excel users have muscle memory: copy a block, tab to the grid, Ctrl+V. If that doesn't work, your grid is a viewer, not an editor. Getting paste right is what turns SvGrid into a legitimate data-entry surface.

A spreadsheet-style SvGrid accepting pasted tabular data.

What the clipboard actually contains

When someone copies a block from Excel or Google Sheets and your page receives a paste event, the text/plain MIME type carries a TSV (tab-separated values) string. Rows are separated by \r\n or \n, cells by tabs. That's all there is to it - no exotic format, no API key, no browser extension.

// paste-utils.ts
export function parseClipboard(text: string): string[][] {
  return text
    .replace(/\r\n/g, '\n')
    .replace(/\r/g, '\n')
    .split('\n')
    .filter(Boolean)
    .map((line) => line.split('\t'))
}

// Type-coerce a raw pasted string to match a column's data type.
// Without this, pasted "42" stays a string and numeric sorts break.
export function coercePastedValue(
  raw: string,
  type: 'number' | 'date' | 'boolean' | 'string' = 'string'
): unknown {
  if (type === 'number') {
    const n = Number(raw.replace(/,/g, ''))
    return isNaN(n) ? raw : n
  }
  if (type === 'date') {
    const d = new Date(raw)
    return isNaN(d.getTime()) ? raw : d.toISOString()
  }
  if (type === 'boolean') return raw === 'TRUE' || raw === '1' || raw === 'true'
  return raw
}

The comma-stripping in the number branch handles localized Excel exports where 1,234 means one thousand two hundred thirty-four, not a string with a comma in it.

Wiring the paste handler into SvGrid

The cleanest approach is to listen for paste on the grid container and use the SvGrid API to read the active cell position and commit changes as a transaction. That way undo/redo works out of the box.




   { api = a }}
  />

The outer div captures paste before it reaches any focused input, so the handler fires whether the user is focused on a cell or just on the grid container. The role="grid" and tabindex keep keyboard focus sensible.

Growing the grid when the paste block overflows

Clipping silently at the last row frustrates users who are pasting into a blank region. A better policy is to append new rows for any overflow. The shape of the new rows needs sensible defaults - for our example, an auto-incremented ID and empty strings elsewhere.

function applyPasteWithGrowth(
  rows: Row[],
  matrix: string[][],
  startRow: number,
  editableFields: { field: keyof Row; type: string }[]
): { updated: Row[]; appended: Row[] } {
  const updated: Row[] = []
  const appended: Row[] = []
  const maxId = Math.max(...rows.map((r) => r.id), 0)

  matrix.forEach((line, r) => {
    const rowIndex = startRow + r
    const isNew = rowIndex >= rows.length
    const base: Row = isNew
      ? { id: maxId + appended.length + 1, name: '', qty: 0, price: 0, shipped: '' }
      : { ...rows[rowIndex] }

    line.forEach((val, c) => {
      const colDef = editableFields[c]
      if (!colDef) return
      ;(base as any)[colDef.field] = coercePastedValue(val, colDef.type as any)
    })

    if (isNew) appended.push(base)
    else updated.push(base)
  })

  return { updated, appended }
}

// Then in the paste handler:
// const { updated, appended } = applyPasteWithGrowth(rows, matrix, startRow, editableFields)
// api.applyTransaction({ update: updated, add: appended })

Whether you clip or grow depends on your use case. A product catalog where rows have meaning (fixed set of SKUs) should clip. A data-import flow where users are filling an empty table should grow.

Validation that surfaces errors without blocking work

Silently skipping bad cells is annoying. Blocking the entire paste because one cell has a bad value is worse. The right middle ground: apply everything that's valid, collect the invalid cells, and surface a non-modal summary.

The invalid array from the handler above is the hook for this. Feed it into a Svelte snippet that renders a dismissible banner above the grid:

{#if pasteErrors.length}
  
    {pasteErrors.length} cell{pasteErrors.length === 1 ? '' : 's'} skipped:
    {pasteErrors.map((e) => `${e.col} row ${e.row + 1} ("${e.value}")`).join(', ')}
    
  
{/if}

Keep pasteErrors as a $state([]) variable, set it after every paste, and clear it on dismiss or on the next paste. Users can see what was skipped, fix the source data in Excel, and repaste just the bad rows.

A note on column ordering

The handler above assumes you know which columns are editable and in what order the user sees them. That assumption breaks when column reordering is enabled. In that case, get the visible column order from the API before mapping:

// inside handlePaste, after api is confirmed not-undefined
const visibleCols = api.getState().columnOrder ?? columns.map((c) => c.id)
// then map matrix columns against visibleCols starting at the active column

If you pin non-editable columns on the left (ID, name) and all editable columns in the middle, users can copy a block from Excel that matches exactly what they see - which is the most intuitive paste target anyway.

Pasting from Excel is a small feature with outsized impact on power users. Once it works, you'll hear about it every time someone evaluates your app.

Building an Order Management Dashboard in Svelte

Kamelia M — Sun, 23 Aug 2026 07:12:00 GMT

Most e-commerce operations teams spend more time in their order grid than anywhere else. They need to read status at a glance, drill into line items, bulk-mark shipments, and occasionally pull a report. That is a lot to pack into one view - but it maps almost directly to SvGrid's feature set.

This post walks through the full order dashboard: server-side data with filters and pagination, a status workflow in editable cells, master-detail line items loaded on demand, and bulk fulfillment actions. Each section shows real code you can adapt.

A live order-management grid in SvGrid.

Columns that communicate order state

The column definition is where most of the UI work happens. A good order grid shows what operators actually need: order ID, customer name, total value, current status, and a created-at timestamp. Status and totals get special treatment.

The conditional formatting on status is worth calling out: it runs per-cell with zero extra render cost. Operators see red/amber/green immediately, without needing to parse labels.

Server-side data with filters operators actually use

Order tables grow fast. Even a modest shop accumulates tens of thousands of orders within a year. Server-side filtering is not optional here - it is the only approach that stays responsive.



 { api = a }}
/>

The filter row gives operators direct column-level filtering. Status gets a dropdown, date fields get range inputs, and customer gets a text search. All of it goes back to the server on change - the grid handles the debounce.

Line items as expandable detail

The master-detail pattern fits orders perfectly. The order is the master row; its line items are the detail. Load them lazily so a 5000-row grid does not pre-fetch 50,000 line item records.



 { api = a }}
/>

One thing to get right: the {:catch} branch. Network requests fail, especially in operations tools that run all day. A blank or stuck expand state looks like a bug; an error message looks like the system is working correctly.

Bulk fulfillment via row selection

Selection plus a toolbar is where the grid stops being a read-only table and becomes a tool. The selection API is straightforward, but there is one important detail: with server-side data, "select all" means select all matching records on the server, not just the current page.



{#if api && api.getSelectedRows().length > 0}
  
    {api.getSelectedRows().length} orders selected
    
    
    
  
{/if}

The applyTransaction call is the right move after a bulk action. It updates the local state optimistically without triggering a full server round-trip. If the server call fails, you can reverse it - but in most fulfillment workflows, success is the default.

Status advancement and edge cases

Editable status cells need a bit of guard logic. An operator should not be able to move an order from "shipped" back to "pending". The cell editor can enforce this:

{#snippet editableStatus({ value, row, stopEditing })}
  {@const allowed = nextStatuses(value)}
  
{/snippet}

function nextStatuses(current: Order['status']): Order['status'][] {
  const transitions: Record = {
    pending: ['paid'],
    paid: ['fulfilled'],
    fulfilled: ['shipped'],
    shipped: [],
  }
  return [current, ...transitions[current]]
}

Showing only valid transitions in the dropdown prevents data integrity errors without needing server-side validation to bubble back a rejection. The operator never sees an option that would fail.

What this approach handles well

The combination of server-side data, master-detail rows, and bulk selection covers the core of operations work. The grid itself does the heavy lifting: virtualization keeps large lists smooth, the filter row reduces the need for a separate filter panel, and selection state persists across page changes.

Where this needs extension: if you need real-time updates (new orders coming in, status changed by a different operator), wire a WebSocket or SSE feed into api.applyTransaction. The grid handles incremental updates cleanly - you push changes in, it re-renders only the affected rows.

Audit trails are the other common addition. Most order systems need a log of who changed a status and when. That is backend work, but hooking into the grid's cell edit callback gives you the right event to emit.

Optimistic UI Explained

Victor Vidolov — Sat, 22 Aug 2026 07:12:00 GMT

Most save operations succeed. That one fact is the entire foundation of optimistic UI, and if you internalize it, the pattern stops feeling like a trick and starts feeling obvious.

Optimistic UI in a SvGrid grid: apply now, confirm in the background.

The pessimistic default and why it costs you

The conventional request-then-update loop looks safe because nothing on screen is wrong. Click save, spinner appears, response arrives, screen updates. But that 200-400ms gap is not neutral - it makes the app feel sluggish, and users feel the wait even when they cannot put a number on it.

The deeper problem is that you are making users wait for a confirmation they will get 99% of the time anyway. You are optimizing for the rare failure case at the expense of every single success.

Optimistic UI flips the assumption. Update the screen first, send the request in parallel, and only intervene if the request fails. The failure path becomes the exception branch, not the main branch.

Three steps, one try/catch

The core pattern is almost embarrassingly short. A grid cell edit is the canonical example because it has a clear old value, a new value, and a specific row to revert:



 { gridApi = api }}
/>

The user sees the change immediately. The network round trip is invisible. A failure is the only thing that interrupts the experience - and even then, you have the old value to restore.

Making failure visible without alarming users

Silent rollbacks are a trust problem. A user edits a cell, nothing seems to go wrong, and ten minutes later they notice their change is gone. That is worse than a visible error.

The errorRowId in the snippet above gives you a hook for visual feedback. You can use it to apply conditional formatting at the row level or trigger a notification:



{#if toastMessage}
  {toastMessage}
{/if}

The red background and the toast together do two things: they tell the user something went wrong, and they confirm the original value was restored. Without both signals, users guess.

The reconciliation problem

There is one edge case that bites teams who do not think about it: what happens when a background data refresh arrives while an optimistic change is pending?

If your grid polls the server every 30 seconds and a response arrives 150ms after the user made an edit, a naive rows = serverData will silently overwrite their pending change - and they will have no idea until the next refresh either confirms or denies it.

The fix is to track which rows have in-flight edits and merge around them:

// Track pending edits by row id
const pendingEdits = new Map>()

async function handleCellEdit(event) {
  const { rowIndex, row, columnId, newValue, oldValue } = event

  // Mark this row as having a pending edit
  pendingEdits.set(row.id, { ...(pendingEdits.get(row.id) ?? {}), [columnId]: newValue })

  rows[rowIndex] = { ...row, [columnId]: newValue }

  try {
    await fetch(`/api/companies/${row.id}`, {
      method: 'PATCH',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify({ [columnId]: newValue }),
    })
    // Only clear the specific field once confirmed
    const pending = pendingEdits.get(row.id)
    if (pending) {
      delete pending[columnId]
      if (Object.keys(pending).length === 0) pendingEdits.delete(row.id)
    }
  } catch {
    rows[rowIndex] = { ...row, [columnId]: oldValue }
    pendingEdits.delete(row.id)
  }
}

// When server data arrives (polling, SSE, etc.)
function applyServerData(serverRows: typeof rows) {
  rows = serverRows.map((serverRow) => {
    const pending = pendingEdits.get(serverRow.id)
    // Merge pending edits on top of fresh server data
    return pending ? { ...serverRow, ...pending } : serverRow
  })
}

This is the part most tutorials skip, and it is where optimistic UI breaks down in production if you are not careful.

When optimism is the wrong call

Optimistic UI suits high-success, low-stakes interactions: cell edits, status toggles, tag assignments, row reordering. The success rate is near 100% and the worst case is a visible revert.

Three situations where you should not be optimistic:

Payment and billing operations. A user who sees a "Payment successful" flash before the charge clears will be justifiably angry if the charge fails. Show a real pending state and wait.

Irreversible deletes. If there is no undo on the server side, do not pretend the delete happened. A rollback gives back data that is already gone.

High-concurrency records. If ten users can edit the same row and your API does not support optimistic locking (ETags, version fields), you will silently drop updates. Either add conflict detection or use a pessimistic lock.

The tell is usually the failure rate combined with the cost of a wrong impression. At 0.5% failure and easy rollback, go optimistic. At 5% failure on a payment, do not.

The performance argument is secondary

Teams often frame optimistic UI as a performance technique, and it does make apps feel faster. But the real value is that it shifts the mental model: the network is a background concern, not a blocker. Users stay in flow. The UI responds to them, not to the server.

Once you start building that way, pessimistic flows start feeling unnecessary every time you add them. Most of the time, they are.

Open-Source vs Commercial Svelte Data Grids

Boyko Markov — Fri, 21 Aug 2026 07:12:00 GMT

Most teams pick a grid based on a GitHub star count or a quick feature table, then spend the next six months fighting the decision. The licensing model matters less than people think at first, and more than they realize once they're shipping.

Here's the honest version.

What "free" actually costs in practice

MIT-licensed means no license fee. It does not mean no cost.

The typical open-source Svelte grid in 2025-2026 gives you rendering, sorting, and basic filtering. Beyond that, you're on your own. Virtualization that handles 100k rows? Maybe. Cell editing with undo/redo? Probably not. Server-side data with pagination, filtering, and sorting wired together? Build it yourself.

A mid-complexity data grid feature - say, server-side sorting plus a custom filter row plus sticky headers - takes one to three days to build and wire correctly. Do that four times across a project and you've spent two weeks on grid plumbing that a paid library would have solved on day one. At $150/hr, that's $12,000 before you've shipped anything.

Open-source is cheapest when the feature set fits your need exactly. It stops being cheap the moment you start building on top of it.

What you're actually buying with commercial licensing

A commercial grid is not a pile of features. It's risk transfer.

When something breaks in production on a Friday and you have a $1M demo on Monday, you want a support ticket going to a team who maintains that codebase for a living. You want a fix or a workaround, not a GitHub issue that might get picked up in two weeks.

You're also buying roadmap continuity. An open-source grid maintained by one person is one job change away from becoming unmaintained. Commercial grids have business incentives to stay maintained. That's not a guarantee, but it's a meaningful signal.

The real risk with commercial, beyond price, is lock-in. When the license restricts deployment environments, or seats are counted per-developer, or you need a new contract for each client project, the overhead becomes its own cost.

The feature gap in Svelte specifically

Svelte's ecosystem is younger than React's. The result is that even decent Svelte grids tend to be missing things you'd take for granted in an ag-Grid or TanStack Table setup.

Things that look standard but frequently aren't in free Svelte grids:

Row virtualization that handles pinned columns correctly
Column grouping with nested headers
Cell-level selection (not just row selection)
Editable cells with type-aware inputs
Export to Excel with formatting
Pivot tables

Here's what a typical server-side + virtualized setup looks like in SvGrid's free tier, which covers most of these:

That runs entirely on the free @svgrid/grid package. The server handles sorting and filtering; the grid handles pagination, virtual scrolling, and the filter row UI.

Where the paid tier changes the picture

The enterprise package (@svgrid/enterprise) adds the things you'd otherwise build yourself: pivot tables, Excel export with multi-sheet support, import, AI assistant, and priority support.

Pivot is the clearest example of why commercial tiers exist. Building a pivot engine from scratch is weeks of work. Getting it right under virtualization, with nested row groups and column totals, is a distinct and hard problem. Paying for it is almost always cheaper than building it.



 { api = a }}
/>

That code would be a multi-week project to replicate from scratch. The license cost is a rounding error by comparison.

The open-core middle ground

The cleanest answer to "open-source or commercial" is often neither, in the pure form.

Open-core grids ship a real, capable free tier under a permissive license and charge for the tier above it. You evaluate and prototype for free. You pay only when you need the advanced features. You don't pay per developer for the core package.

SvGrid is built this way. @svgrid/grid is MIT-licensed and covers a wide range of production use cases - row and column virtualization, grouping, server-side data, editing, undo/redo, named views, conditional formatting, cell selection, and more. Enterprise adds the commercial-grade extras.

Here's a realistic view of how the imperative API works for managing grid state across both tiers:

import SvGrid from '@svgrid/grid'
import { createNamedViews, localStorageViews } from '@svgrid/grid'

// Named views: save/restore column layout, filters, sort state
const views = createNamedViews(localStorageViews('my-grid'))

// After onApiReady:
function saveCurrentView(name: string) {
  const state = api.getState()
  views.save(name, state)
}

function restoreView(name: string) {
  const state = views.load(name)
  if (state) api.setState(state)
}

// Programmatic column management
api.setColumnVisible('internalId', false)
api.setColumnPinning({ left: ['name', 'sku'], right: ['actions'] })
api.autosizeAllColumns()

// Grouping and pagination together
api.setGroupBy(['category', 'region'])
api.setPageSize(50)
api.setPage(0)

// Selection
api.selectAllRows()
const selected = api.getSelectedRows()

// Edit flow
api.startEditing(rowIndex, 'price')
// ... user edits ...
api.stopEditing()
api.undo() // revert if needed

All of that is free, MIT-licensed, ships in production today.

How to make the call

Three questions that cut through the noise:

What features do you actually need at launch? List them. Match them against the free tier. If virtualization, sorting, filtering, editing, and server-side data are enough, the free tier is the right call. If you need pivot or Excel export, price in the commercial tier from the start.

How expensive is your time relative to license cost? A per-developer annual license for an enterprise grid is typically $300-700/year. If your hourly rate is $100+, one day of building a feature that the grid already has breaks even on a full year of license cost. Do the math honestly.

What's the abandonment risk? An MIT grid with one maintainer and 200 stars carries real risk. A commercial grid with paying customers has financial incentive to keep the lights on. For a grid you'll depend on for three or more years, that durability matters.

For most Svelte teams building internal apps or B2B products: start with a capable open-core free tier, evaluate whether you hit the ceiling, and upgrade if you do. Don't pay for features you won't use. Do pay for features that would cost more to build than to license.

Multi-Level (Grouped) Column Headers in SvGrid

Victor Vidolov — Thu, 20 Aug 2026 07:12:00 GMT

Twenty columns in a flat header is a navigation problem disguised as a data problem. Users scan left to right looking for meaning, and a wall of equal-weight labels gives them nothing to anchor on. Grouped headers - a parent band spanning several child columns - solve this by creating visual hierarchy before the user has to think.

SvGrid handles grouped headers through nested column definitions. There is no separate API call, no post-setup configuration. You nest a columns array inside a parent column object and the grid renders a spanning header above the children. That simplicity has real implications for how you can compose things.

Grouped, multi-level column headers in SvGrid.

The nesting model

The core idea is that any column object can have a columns property. When it does, SvGrid treats it as a group header - it spans the full width of its children and cannot itself hold data. The children are ordinary leaf columns with all the usual properties: field, width, type, editable, pinned, and so on.

import SvGrid from '@svgrid/grid'
import type { ColumnDef } from '@svgrid/grid'

type Row = {
  product: string
  q1_revenue: number
  q2_revenue: number
  q3_revenue: number
  q4_revenue: number
  q1_units: number
  q2_units: number
}

const columns: ColumnDef<{}, Row>[] = [
  {
    id: 'product',
    field: 'product',
    header: 'Product',
    width: 200,
    pinned: 'left',
  },
  {
    header: '2026 Revenue',
    columns: [
      { id: 'q1_rev', field: 'q1_revenue', header: 'Q1', width: 110, type: 'number', format: { type: 'currency', currency: 'USD' } },
      { id: 'q2_rev', field: 'q2_revenue', header: 'Q2', width: 110, type: 'number', format: { type: 'currency', currency: 'USD' } },
      { id: 'q3_rev', field: 'q3_revenue', header: 'Q3', width: 110, type: 'number', format: { type: 'currency', currency: 'USD' } },
      { id: 'q4_rev', field: 'q4_revenue', header: 'Q4', width: 110, type: 'number', format: { type: 'currency', currency: 'USD' } },
    ],
  },
  {
    header: '2026 Units',
    columns: [
      { id: 'q1_units', field: 'q1_units', header: 'Q1', width: 90, type: 'number' },
      { id: 'q2_units', field: 'q2_units', header: 'Q2', width: 90, type: 'number' },
    ],
  },
]

The "2026 Revenue" band spans four columns. "2026 Units" spans two. The product column is pinned left and stands alone. The grid takes care of the rowspan and colspan math, so you do not write any HTML by hand.

Sorting and filtering still work on leaf columns

A common concern with multi-level headers is whether interactive features break down. They do not. Sorting, filtering, and resizing all operate on the leaf columns exactly as they would in a flat header. The group bands are display-only.



 { api = a }}
/>

Filter rows appear under the leaf headers, not under the group bands, which is exactly where users expect to type. If you have showFilterRow={true}, the group bands get an empty cell spanning the group width - the filter inputs sit in the next row aligned to their columns.

Three levels and why you probably want two

Nesting can go deeper. Year > Half > Quarter is a legitimate structure and SvGrid will render all three rows:

const columns: ColumnDef<{}, Row>[] = [
  { id: 'region', field: 'region', header: 'Region', width: 160, pinned: 'left' },
  {
    header: '2025',
    columns: [
      {
        header: 'H1',
        columns: [
          { id: 'q1_25', field: 'q1_2025', header: 'Q1', width: 100, type: 'number' },
          { id: 'q2_25', field: 'q2_2025', header: 'Q2', width: 100, type: 'number' },
        ],
      },
      {
        header: 'H2',
        columns: [
          { id: 'q3_25', field: 'q3_2025', header: 'Q3', width: 100, type: 'number' },
          { id: 'q4_25', field: 'q4_2025', header: 'Q4', width: 100, type: 'number' },
        ],
      },
    ],
  },
  {
    header: '2026',
    columns: [
      {
        header: 'H1',
        columns: [
          { id: 'q1_26', field: 'q1_2026', header: 'Q1', width: 100, type: 'number' },
          { id: 'q2_26', field: 'q2_2026', header: 'Q2', width: 100, type: 'number' },
        ],
      },
    ],
  },
]

Three levels is technically fine. Four is where it starts costing users more in visual effort than it saves in organization. My rule of thumb: if the group label is more than five words, or if you are approaching four rows of headers, consider whether a column chooser or a tab-based view would serve better.

Combining grouped headers with column grouping and aggregation

These are two different things that the same word ("grouping") can confuse. Column header groups organize the header display. Row grouping (via groupable and setGroupBy) aggregates rows by a field value. They compose cleanly:



 {
    api = a
    // Group rows by region; column header bands are separate
    api.setGroupBy(['region'])
  }}
/>

The header bands ("2026 Revenue", "2026 Units") remain visible and unchanged while rows are grouped by region. Aggregated totals appear per group and in the footer, tied to whichever leaf columns have aggregate configured. This is the combination that makes financial dashboards work - you want both the organizational structure in the header and the roll-up structure in the rows.

When flat headers are actually better

Grouped headers add cognitive load even when they add clarity. A few situations where I reach for flat columns instead:

Fewer than six columns. Grouping three columns under one band is visual overhead with no payoff.
Heterogeneous data where columns do not share a natural parent dimension. Forcing them into a group gives users a false taxonomy.
Heavy filtering workflows. When users are constantly showing and hiding columns via a column chooser, a deep header hierarchy gets confusing as columns come and go and group bands collapse.

When the data genuinely has a parent-child relationship between header concepts, though, grouped headers communicate that relationship immediately. A year with quarters underneath reads as "these four things belong to 2026" in a way that four separate "2026 Q1", "2026 Q2" flat headers do not.

Column visibility with grouped headers

If all children of a group are hidden, the group band itself collapses and disappears. If some children are hidden, the band narrows to span only the visible ones. This means you can safely wire a column chooser to leaf columns without writing any special logic for group visibility:

// Hide all revenue columns - the "2026 Revenue" band disappears automatically
api.setColumnVisible('q1_rev', false)
api.setColumnVisible('q2_rev', false)
api.setColumnVisible('q3_rev', false)
api.setColumnVisible('q4_rev', false)

// Show one back - the band reappears, spanning only q4_rev
api.setColumnVisible('q4_rev', true)

This behavior is one of the places where having the group structure encoded in the column definition (rather than set up through a separate API) pays off. The grid always knows which leaves belong to which band and can recompute spans reactively.

Choosing the Most Accessible Svelte Data Grid

Boyko Markov — Wed, 19 Aug 2026 07:12:00 GMT

Most data grid accessibility stories go like this: a vendor's feature page has a green checkbox next to "WCAG 2.1 AA". A procurement team checks the box. Six months later, a screen-reader user files a support ticket because they cannot navigate past column 3.

Accessibility claims are cheap. The real question is how to verify them before you commit to a component.

A high-contrast, accessible SvGrid theme.

What the WAI-ARIA grid pattern actually requires

The W3C defines a composite widget called grid that is meant for grids of interactive cells - not for static data tables. The DOM requirements are specific:

The container gets role="grid"
Each row gets role="row"
Header cells get role="columnheader"
Data cells get role="gridcell"

Inspect any Svelte grid candidate with DevTools before trusting the docs. A library that renders

with no ARIA role fails this immediately - assistive technology has nothing to announce.

Beyond roles, the pattern requires that the grid function as a single tab stop. You Tab into it, arrow keys move focus between cells, and Tab again takes you out. If Tab walks through every cell in a 1000-row table, that is a keyboard trap by a different name, and it fails WCAG 2.1 criterion 2.1.2.

The four things you must test yourself

Feature pages lie by omission. These four tests take under ten minutes and tell you almost everything:

1. Keyboard navigation without a mouse. Open the grid, tab into it, and try to reach the last cell using only arrow keys, Home, End, Page Up, Page Down, Ctrl+Home, and Ctrl+End. Try editing with F2 or Enter and cancelling with Escape. A grid that supports only arrow movement but drops the rest fails in practice.

2. Focus survival under virtualization. This is where most grids quietly break. Virtualization recycles DOM nodes as you scroll - when a focused row leaves the viewport, the grid may destroy the node that held focus. Navigate to a row near the bottom of the viewport, scroll it off screen, then scroll back. Is the focused cell still focused, or did focus silently move to ?

3. Screen-reader announcements. With VoiceOver or NVDA running, navigate with arrow keys. You should hear the cell content, the column header, and the row/column position (e.g. "row 5, column 3"). Sort state changes should be announced via aria-sort. Row selection should be announced via aria-selected.

4. Custom cell accessibility. This one is your responsibility, but the grid shapes how easy or hard it is. Render an action column with a button in each cell, then keyboard-navigate to it. Does focus land inside the cell correctly? Does pressing Space or Enter activate the button? A grid that puts interactive elements inside gridcell correctly will make this straightforward.

How to build accessible custom cells in SvGrid

Even a grid with perfect built-in accessibility can be broken by the cells you write. Here is the pattern that keeps things correct:



{#snippet statusCell({ value })}
  
  
    {value}
  
{/snippet}

{#snippet actionsCell({ row })}
  
  
{/snippet}

The two rules that matter: use real

Migrating a Svelte 4 Table Component to Svelte 5

Victor Vidolov — Tue, 18 Aug 2026 07:12:00 GMT

Most Svelte 4 tables hit the same wall around the same time: someone adds sorting, then filtering, then someone else asks why 10,000 rows lock up the browser. By that point, you're maintaining a small grid library inside your app. Svelte 5 is a natural pause to decide whether to carry that forward or hand it off.

Either way, you need to know the translation. Here it is, concept by concept, with a real recommendation at the end.

The mental model shift

Svelte 4's reactivity was implicit. $: statements re-ran whenever referenced values changed, and the compiler tracked what those were. Svelte 5 makes that explicit: $derived and $effect replace $:, $state replaces let for reactive variables, and $props() replaces export let.

The upside is that the new model composes much better. Once you're used to it, you stop wondering which $: blocks will re-run and in what order.

Props - the easy part

The destructuring syntax is cleaner for typed code. In Svelte 4, TypeScript annotations on export let required some gymnastics; with $props() you annotate the destructured type directly.

Reactive state and derived values

This is where most of the migration effort lives.

A few things to notice. First, $derived chains: sorted depends on filtered, and the runtime tracks that automatically. Second, local state variables (sortKey, sortDir, filterText) become $state calls. You no longer need a store just because a value is reactive.

Stores to $state

Svelte 4 projects often used writable stores to share state between a table component and its parent - page index, selected rows, column visibility. With runes, you can pass $state values directly as props, or use a plain object with $state fields.

The .svelte.ts extension matters - it tells the Svelte compiler to process rune syntax in a non-component file. This pattern replaces the store module pattern cleanly.

Slots to snippets

Custom cell rendering is usually the messiest part of any table migration. Svelte 4 used named slots, which meant the consuming side had to reach into the table with slot="cell" and hope the binding worked. Svelte 5 snippets are explicit and type-safe.



{#each sorted as row}
  
    {#each columns as col}
      
        
          {row[col.key]}
        
      
    {/each}
  
{/each}



  
    {#if col.key === 'status'}
      {value}
    {:else}
      {value}
    {/if}





{#each sorted as row}
  
    {#each columns as col}
      
        {#if cell}
          {@render cell({ row, col, value: row[col.key] })}
        {:else}
          {row[col.key]}
        {/if}
      
    {/each}
  
{/each}


{#snippet statusCell({ row, col, value })}
  {#if col.key === 'status'}
    {value}
  {:else}
    {value}
  {/if}
{/snippet}

Events become callback props




 handleRowClick(row)}>...




 onRowClick?.(row)}>...

The event dispatcher is gone. Callback props are just functions. This is actually easier to type, easier to test, and removes the implicit string-based event name entirely.

When porting stops making sense

The translation above handles a table that does sorting, filtering, and basic selection. That's a few hundred lines and maybe a day of work for most codebases. But there's a set of features where the cost curve of hand-rolling goes vertical: virtualized scrolling for large datasets, server-side pagination with loading states, column resizing and pinning, accessibility (full keyboard navigation, ARIA grid role, screen reader announcements), and cell-level editing with validation.

If your Svelte 4 table already has these, you've built a grid library and you're maintaining it in parallel with your app. If it doesn't have them and someone on your team keeps asking for them, migration time is the right moment to stop.

SvGrid is built Svelte 5 native - runes throughout, no adapter layer. Dropping it in looks like this:



 { api = a }}
/>

You get virtualization, keyboard navigation, server-side data, and column pinning without writing them. The snippet pattern for custom cells is identical to what you'd write in the hand-rolled version above, so the knowledge transfers.

For small static tables, port it - the Svelte 5 version will be cleaner than what you had. For anything with real data volume or feature expectations, use the migration as the opportunity to stop maintaining infrastructure.

Migrating from DataTables.net to a Svelte Data Grid

Victor Vidolov — Wed, 12 Aug 2026 07:12:00 GMT

jQuery DataTables is a decade-old plugin that still runs on a surprising share of internal tools and admin panels. If you are moving one of those to SvelteKit, you will find that most of the concepts translate - column definitions, server-side pagination, custom cell rendering - but the execution shifts from imperative jQuery to reactive Svelte state. The delta is smaller than it looks, and the result is significantly less code.

What the two libraries are trying to do

DataTables attaches behavior to an existing

element. You hand it options at init time, and it wires up sorting, filtering, and pagination on top of whatever HTML you already have. Every subsequent interaction goes through method calls (table.page(2).draw()) or event listeners.

SvGrid is a Svelte component. There is no DOM element to attach to; you describe your grid declaratively and it renders itself. State changes happen through reactive props and an imperative API you get access to via onApiReady. The mental model is closer to a controlled React component than to a jQuery plugin.

This distinction matters when planning the migration. You are not swapping implementations of the same idea. You are moving from an outside-in jQuery pattern to an inside-out Svelte component pattern.

Column definitions

DataTables column definitions look like this:

$('#myTable').DataTable({
  columns: [
    { data: 'name',   title: 'Name'   },
    { data: 'email',  title: 'Email'  },
    { data: 'salary', title: 'Salary', render: (d) => `$${d.toLocaleString()}` },
    { data: 'status', title: 'Status', orderable: false },
  ],
  order: [[2, 'desc']],
  pageLength: 25,
})

The same columns in SvGrid, as a ColumnDef array:



 { api = a }}
/>

A few things are different here. render callbacks become the format option for built-in formatters, or a cell snippet when you need full control over the rendered output. The initial order config maps to setting sort state after onApiReady fires: api.setSort('salary', 'desc'). The pageLength option is just pageSize.

Server-side data

DataTables' serverSide: true mode sends a POST with start, length, order[], and search[value] parameters baked into its own wire format. You return recordsTotal and recordsFiltered in a specific envelope. It works, but the format is opaque and the parameters come in DataTables' own naming convention.

SvGrid's server-side mode gives you a typed fetch callback with clean parameters. You own the request shape:

The page parameter is zero-indexed. Your API endpoint gets clean named parameters instead of DataTables' positional array syntax. The total count comes back in your return value alongside the rows - no envelope keys to remember.

Custom cell rendering

DataTables render callbacks return an HTML string, which gets injected via innerHTML. That works until you need interactivity inside the cell - then you are wiring up event listeners manually against DOM nodes DataTables manages.

SvGrid uses Svelte snippets. A snippet is a typed, reactive block that renders as part of the component tree, so Svelte event handling and reactivity work normally inside it:



{#snippet statusCell({ value }: { value: string })}
  
    {value}
  
{/snippet}

{#snippet actionsCell({ row }: { row: Employee })}
  
{/snippet}

The snippet gets typed value and row parameters. No HTML string construction, no document.querySelector after render. Svelte handles the DOM.

The honest tradeoffs

DataTables has 15 years of plugins - editor, responsive, buttons, select. If your project depends on several of those plugins working together, the migration cost is real. You are rebuilding that functionality, not just swapping components.

Where SvGrid clearly wins: virtualization for large client-side datasets (DataTables would page rather than virtualize), native Svelte reactivity so the grid responds to state changes without .draw() calls, and TypeScript types on columns, rows, and the API surface.

The DataTables method call pattern (table.column(0).search('value').draw()) can feel familiar if you have written a lot of jQuery. SvGrid's imperative API is similar in spirit - api.setFilter('name', { operator: 'contains', value: 'Alice' }) - but it goes through Svelte's reactivity system rather than triggering a DOM re-render manually.

One thing that trips people up: DataTables initializes once and then you mutate it. SvGrid is reactive, so updating data to a new array re-renders the grid automatically. If you are used to calling .ajax.reload() to refresh data, the equivalent is just updating your $state variable.

The migration is mostly mechanical once you have the column definition shape down. The server-side adapter is the part that requires thought, because you are replacing DataTables' baked-in wire format with your own - which gives you more control but also means writing the parameter mapping yourself.

Migrating from ag-grid-react to a Svelte Stack

Kamelia M — Tue, 11 Aug 2026 07:12:00 GMT

The React-to-Svelte migration conversation always stalls at the same point: "but we have a lot of AG Grid." That anxiety is usually disproportionate. Column definitions translate almost one-to-one, cell renderers become snippets, and the server-side row model maps to a single adapter function. The real migration work is the surrounding React patterns, not the grid.

An admin template built with SvGrid.

Column definitions: mostly a rename job

AG Grid's columnDefs array and SvGrid's columns array share the same shape. The fields you use constantly - field, headerName, width, pinned, editable, valueFormatter - have direct equivalents. The API names are slightly different, but nothing requires rethinking.

ag-grid-react	SvGrid (@svgrid/grid)
`rowData`	`data`
`columnDefs`	`columns`
`headerName`	`header`
`field`	`field`
`valueFormatter`	`format` or `formatter`
`valueGetter`	`fieldFn`
`cellRenderer`	`cell` (snippet or component)
`onCellValueChanged`	`onCellValueChange`
`suppressMovable`	`movable: false`
Server-Side Row Model	`createServerDataSource`
AG Grid Enterprise	`@svgrid/enterprise`

A typical AG Grid column definition like this:

// ag-grid-react column def
const columnDefs = [
  { field: 'name', headerName: 'Name', width: 180, pinned: 'left' },
  {
    field: 'price',
    headerName: 'Price',
    width: 100,
    type: 'numericColumn',
    editable: true,
    valueFormatter: (p) => `$${p.value.toFixed(2)}`,
  },
  { field: 'status', headerName: 'Status', width: 120, cellRenderer: StatusRenderer },
  { headerName: '', width: 80, cellRenderer: ActionsRenderer, pinned: 'right' },
]

becomes this in SvGrid:

import type { ColumnDef } from '@svgrid/grid'

const columns: ColumnDef[] = [
  { id: 'name', field: 'name', header: 'Name', width: 180, pinned: 'left' },
  {
    id: 'price',
    field: 'price',
    header: 'Price',
    width: 100,
    type: 'number',
    editable: true,
    format: (value) => `$${Number(value).toFixed(2)}`,
  },
  { id: 'status', field: 'status', header: 'Status', width: 120, cell: statusCell },
  { id: 'actions', header: '', width: 80, cell: actionsCell, pinned: 'right' },
]

The pattern is consistent. If you have a script that generates column defs programmatically, a few targeted string replacements will get you most of the way there.

Cell renderers to snippets

This is the area where React and Svelte diverge most visibly - and where Svelte wins on brevity. A React cell renderer is a component with props threading and a forwardRef if you need the grid API. A Svelte 5 snippet is a few lines of markup declared inline or in the same file.

// ag-grid-react: a status badge renderer
const StatusRenderer = ({ value }: { value: string }) => (
  {value}
)

// ag-grid-react: an actions renderer that calls the grid API
const ActionsRenderer = ({ data, api }: ICellRendererParams) => (
  
)

In SvGrid, both become snippets, and the grid instance comes from onApiReady rather than being injected per-cell:



{#snippet statusCell({ value }: { value: string })}
  {value}
{/snippet}

{#snippet actionsCell({ row }: { row: Row })}
  
{/snippet}

 { api = a }} />

No prop threading. No forwardRef. The snippet has access to everything in the component's scope.

Reactivity: the hook mental model doesn't port

This is the actual migration challenge. React's mental model is "re-render the component when state changes, and memoize the expensive parts." Svelte 5's mental model is "track which reactive values each expression reads, and re-run only that expression."

In practice, you stop writing useMemo and useCallback entirely. A derived value is just a $derived. A side effect is a $effect. The dependency array is inferred automatically.

A common pattern in AG Grid React apps is filtering data in a useMemo before passing it to rowData:

// React pattern - explicit memoization and dependency arrays
const [rows, setRows] = useState(rawRows)
const [query, setQuery] = useState('')

const filteredRows = useMemo(
  () => rows.filter((r) => r.name.toLowerCase().includes(query.toLowerCase())),
  [rows, query]
)

//

In Svelte 5, the same logic without the overhead:

If you had useEffect hooks reacting to grid events (like selection changes), those become $effect blocks or event callbacks on the SvGrid component directly.

Server-side data

AG Grid's Server-Side Row Model is one of its most distinctive features - and the one most teams worry about losing. SvGrid handles this with createServerDataSource, which takes a single fetch function and returns a data source you pass directly to data.

import SvGrid, { createServerDataSource } from '@svgrid/grid'

const ds = createServerDataSource({
  fetch: async ({ page, pageSize, sort, filters }) => {
    const params = new URLSearchParams({
      page: String(page),
      size: String(pageSize),
    })

    if (sort.length > 0) {
      params.set('sortField', sort[0].id)
      params.set('sortDir', sort[0].desc ? 'desc' : 'asc')
    }

    for (const f of filters) {
      params.set(`filter_${f.id}`, JSON.stringify(f.value))
    }

    const res = await fetch(`/api/rows?${params}`)
    const json = await res.json()
    return { rows: json.data, total: json.total }
  },
})

Then use it like any other data source:

Sorting, filtering, and pagination all trigger the fetch function automatically. You do not need to wire up event handlers or manually call api.refreshServerSide() the way you would in AG Grid.

What you actually lose

Honest assessment: there are some things AG Grid does that SvGrid does not replicate exactly.

AG Grid Enterprise's range selection (spreadsheet-style multi-cell drag select) and the Excel-like fill handle are not in SvGrid yet. If your app uses those heavily, that is a real gap.

AG Grid's charting integration is a standalone module that we do not try to match. SvGrid has SvGridChart and buildSparkline for column-level data visualization, but not the full in-grid chart builder.

The flip side: SvGrid's Svelte-native rendering means your custom cell content is real Svelte, with access to stores, runes, and component composition. AG Grid's React renderer runs React inside a non-React context, which creates an invisible performance ceiling and awkward lifecycle interactions. That tradeoff disappears entirely in SvGrid.

The migration order that works

Start with the simplest screens first - read-only tables with basic sorting. Get comfortable with the column def translation and the snippet pattern. Then move to editable screens. Server-side data adapters should be last because they require the most careful testing of edge cases (empty results, error states, filter combinations).

For conditional formatting - something many AG Grid users handle with cellStyle callbacks - SvGrid has a dedicated conditionalFormat field on the column definition that keeps the logic out of your renderers:

{
  id: 'score',
  field: 'score',
  header: 'Score',
  conditionalFormat: [
    { condition: ({ value }) => Number(value) < 50, style: { color: 'red', fontWeight: 'bold' } },
    { condition: ({ value }) => Number(value) >= 90, style: { color: 'green' } },
  ],
}

The grid concepts are the same. The implementation is Svelte-native. Most teams are surprised by how little of their actual grid logic needs to change.

Measuring Data Grid Performance in DevTools

Kamelia M — Mon, 10 Aug 2026 07:12:00 GMT

"It feels slow" is not a bug report, it is a hypothesis. Before you touch a single line of grid code, you need a number - a frame time, a node count, a millisecond budget. Without that number, you cannot know whether your fix helped, hurt, or just reshuffled the problem somewhere less visible.

Here is the workflow I actually use when a grid starts misbehaving under load.

Capture a baseline before anything else

Open Chrome DevTools, switch to the Performance tab, and set CPU throttle to 4x (found in the gear icon). This simulates a mid-range laptop and surfaces problems your developer machine hides. Then hit Record, do the exact interaction that feels slow - scroll from top to bottom, sort a column with 50 000 rows, type in a filter box - and stop after 5-8 seconds.

You are looking for three things in the recording:

Long tasks - any orange triangle on the main thread timeline marks a task over 50ms. These are the ones that block input response.
Frame duration - hover over the green frame bars at the top. 60fps means 16.7ms per frame. If your scroll frames are hitting 80ms, you have dropped 4 out of 5.
What fills the long frames - drill down into a bad frame. Yellow is scripting (JS), purple is rendering (style/layout), green is painting. The color that dominates tells you where to look first.

Save the trace file (Export profile button). You will re-import it later to compare against your fix.

DOM node count is the fastest virtualization check

With 50 000 rows, SvGrid should only render the ~30-50 rows visible in the viewport at any moment. Pop open the Console and run:

document.querySelectorAll('[data-row-index]').length

Note the number, scroll halfway down, run it again. If the count is stable (say, 38 to 42 rows), virtualization is working. If it grows linearly with scroll position, the virtual scroller is not engaging.

The almost-universal cause: the grid container has no explicit height. The virtualizer measures the container to decide how many rows to render, and if it reads 0 or auto, it falls back to rendering everything.

You can also pass rowHeight explicitly. When SvGrid knows the row height upfront, it skips a measurement pass per row during initial render:

 { gridApi = api }}
/>

Reading a scripting spike

When yellow (scripting) dominates your bad frames, expand the flame chart to find the hot function. Two patterns show up constantly:

Array allocation on every render. If you pass data={rows.map(transform)} as an inline expression, Svelte re-evaluates it every time any reactive state changes, creating a new array identity on every tick. Move the transform outside:

Cell components re-mounting. If your custom cell creates a Svelte component per row and those components mount/unmount on every scroll, you will see a wall of component lifecycle calls in the flame chart. Snippets are lighter than components for simple cells:



{#snippet stockCell({ value })}
  {value}
{/snippet}

A snippet is just a function call. A component is a full lifecycle - mount, update, destroy. For cells that render thousands of times per second during a scroll, that difference is not academic.

Forced reflow warnings

If you see red "Forced reflow" annotations in the timeline, you have layout thrash: something reads a layout property (like offsetHeight or getBoundingClientRect) and then writes to the DOM, forcing the browser to flush and recalculate layout synchronously.

In grid code, this usually happens in a custom cell that reads the row element's dimensions and then applies a class. The fix is to separate reads and writes, or use a ResizeObserver instead of reading layout imperatively.

Check whether the reflow is inside your code or inside SvGrid itself. Expand the stack trace in the reflow warning. If it traces into your cell snippet, that is yours to fix. If it traces into grid internals, file an issue with the trace.

Compare before and after

After making a change, re-record the same interaction - same scroll path, same duration, same throttle setting. Import the old trace in one DevTools window, open the new one alongside it, and compare:

Average frame time during the scroll
Max long task duration
DOM node count stability

If your change shortened average frame time from 80ms to 22ms, that is a real improvement. If the numbers are the same, you changed the wrong thing. This sounds obvious but most performance work skips this step and ends up with "optimizations" that do nothing measurable.

A quick profiling checklist

Before filing a performance bug or spending a day optimizing:

Confirmed CPU throttle was on during the profile (4x or 6x)
Checked DOM node count during scroll - stable or climbing?
Identified whether the bottleneck is yellow (scripting), purple (layout), or green (paint)
Verified the grid container has an explicit pixel height
Checked that data is not being reallocated on every tick
Compared a before/after trace with the same interaction

Most grid performance problems fall into one of three buckets: missing container height breaking virtualization, rebuilding data arrays on every reactive update, or cell components that are heavier than they need to be. The flame chart tells you which bucket you are in, and then the fix is usually straightforward. Measurement is the part that takes discipline.

Building a Logistics / Fleet Tracking Grid in Svelte

Kamelia M — Sun, 09 Aug 2026 07:12:00 GMT

Fleet dispatchers don't browse data - they triage it. A vehicle goes offline at 3am and nobody notices until a delivery window is missed. The grid has one job: put the exception in front of the person who can fix it before the customer calls.

This post builds out a real fleet tracking grid: live telemetry updates, color-coded delay indicators, lazy-loaded trip history per vehicle, and a filter toggle that surfaces only the rows that need attention. Each piece is its own decision worth thinking through.

A fleet operations board built with SvGrid.

Column layout and left-pinned identity

Start with what dispatchers need at a glance: vehicle ID, driver, current status, location, ETA, and how late they are. Vehicle and driver should be pinned left so they remain visible when the table scrolls horizontally on smaller screens.



{#snippet statusCell({ value }: { value: string })}
  {value}
{/snippet}

 { api = a }}
/>

The conditionalFormat on the delay column does what a simple formatter can't: it changes the visual weight of the cell based on severity without any custom cell renderer. Red and bold for anything over an hour, amber for 15-60 minutes, green for on time or early.

Pushing telemetry updates without re-rendering the world

Telemetry arrives fast - typically one update per vehicle every 10-30 seconds for a mid-size fleet, but potentially hundreds per minute during route changes. The right pattern is to batch updates with applyTransaction rather than swapping the entire data array, which would force a full re-render and lose scroll position.

Batching to the animation frame means no matter how many messages arrive between frames, the grid paints once. On a fleet of 2000 vehicles with updates coming in at 100/second, the difference between this and naive .data = newData is the difference between a usable app and a slideshow.

Trip history per vehicle

Expand a vehicle row to see its stops and completed legs. The detail panel should load lazily - pulling all trip history upfront would make the initial load slow and waste bandwidth on vehicles the dispatcher never expands.



{#snippet vehicleDetail({ row }: { row: Vehicle })}
  
    Recent trips - {row.vehicleId}
    {#await loadTrips(row.vehicleId)}
      Loading trip history...
    {:then trips}
      
    {:catch}
      Could not load trips. Try expanding again.
    {/await}
  
{/snippet}

 { api = a }}
/>

The {:catch} branch matters here. Trip history is a secondary request and network failures should degrade gracefully rather than crashing the detail panel.

Exception-first filtering

The most requested feature in any ops grid is "show me only what's broken." That means two things: a fast toggle to filter to exception rows only, and sensible default sort that puts the worst offenders at the top.

The in filter operator on the status column is the right tool here - you want offline AND idle, not just one. Pairing it with a sort on delay descending means the most critical situation is always row one when the filter is active.

Running server-side for large fleets

A national fleet with 5000+ vehicles can't run client-side. Set up server-side data with createServerDataSource and filter by depot or region at the API level, pushing live updates only for the vehicles currently in the visible page.



 { api = a }}
/>

With server-side paging you can push WebSocket updates scoped to the current depot or region - no point streaming telemetry for 4800 vehicles when the dispatcher is looking at a 200-vehicle regional view.

Stale GPS as a data quality signal

One thing that catches people off guard: a vehicle showing "Moving" with a 20-minute-old GPS timestamp isn't moving - the GPS unit is failing or the vehicle drove into a tunnel. The isStale check in the lastSeen column above flags this visually. You can go further and add a filter preset for "stale GPS" that combines a timestamp age filter with status != Offline. Dispatchers often don't know to look for this, but once they see it highlighted they start relying on it heavily.

The fleet tracking grid is one of those cases where the data model is straightforward but the operational requirements shape almost every display decision. Exception-first layout, stale signal detection, and lazy trip history aren't nice-to-haves - they're what makes the difference between a grid that dispatchers keep open all day and one that gets replaced by a phone call.

Building a Log Viewer for Large Logs in Svelte

Victor Vidolov — Sat, 08 Aug 2026 07:12:00 GMT

Most grid demos show 1,000 rows of fake employee data. A log viewer is the opposite: real production logs routinely run into the hundreds of thousands of lines, spike to millions during incidents, and keep arriving in real time while someone is actively scrolling through them. If your grid can't handle that without choking the main thread, it's not useful for this case.

SvGrid handles it well because virtualization is on by default and the live-update path is fast. Here's a complete blueprint.

Virtualization keeps the DOM bounded regardless of how many log lines are buffered.

Column layout that actually works for logs

The column shape matters. Timestamp, level, source, and message are the four you always need, and each has a specific display concern:



{#snippet tsSnippet({ value })}
  {value}
{/snippet}

{#snippet levelSnippet({ value })}
  {value}
{/snippet}

 { api = a }}
/>

Pin the timestamp left. The message column should be wide - people scan it with their eyes horizontally, and truncation at 200px makes the grid nearly useless during debugging. If you want full message text on demand, expanding the row beats a tooltip for logs because messages can be 2,000 characters of stack trace.

Why uniform row height is non-negotiable at scale

Virtualization works by calculating which rows are visible based on scroll position and row height. If every row has a different height, the grid has to measure every row above the viewport to know the scroll offset - which defeats the whole point at a million rows.

Set rowHeight to a fixed pixel value. Use monospace for timestamps so they don't reflow. If you need expandable rows for full stack traces, that's fine - just keep the collapsed state at a uniform height. The performance difference between variable-height and fixed-height virtualization at 500k rows is not subtle.

Severity coloring without a custom renderer

The conditionalFormat array on each column applies CSS styles inline based on cell value. This is fast because it runs during render, not in a separate pass. Coloring the level column handles the badge; if you also want to tint the whole row, apply the same conditions at the row level:

The first thing anyone does when opening a log viewer is filter to errors. Make that painless - a dedicated level filter in the filter row plus a one-click "errors only" button wired to api.setFilter('level', { operator: 'equals', value: 'ERROR' }) covers 80% of the use cases before they even type anything.

Server-side filtering for very large datasets

For a live system, you don't want to buffer millions of rows in the browser. You want to query the log backend and page through results. createServerDataSource handles this:

The filter state flows directly from the grid UI into your fetch parameters. Add debounce on the text inputs if your backend can't handle a query per keystroke.

Live tailing without yanking the user

Tailing - new lines appending at the bottom while someone is scrolled up reading old lines - is the hardest part to get right. The failure mode is aggressive: the grid auto-scrolls to the bottom on every new batch, interrupting whoever is investigating an issue. The correct behavior is:

If the user is at (or very near) the bottom, auto-scroll to follow new lines.
If they have scrolled up at all, stop auto-scrolling. Let them read.
Resume auto-scroll if they scroll back to the bottom themselves.




   { api = a }}
  />

The slice(-50000) caps the in-memory buffer. Without a cap, a process that logs at 10k lines per minute will consume gigabytes of RAM over hours. 50,000 lines is usually enough history for incident investigation; adjust based on what your backend already retains and queryable.

Batching to requestAnimationFrame is critical when log velocity is high. A firehose pushing 200 messages per second would trigger 200 Svelte state updates per second without batching, which kills performance. Coalescing those into one update per frame keeps the grid smooth.

The filter you'll add last but users ask for first

Time range filtering. Most log backends support from and to timestamp parameters, and users almost always want "show me the 10 minutes around when the alert fired." Add two datetime inputs bound to filter state and wire them to your server-side fetch or to a client-side filter on the timestamp field:

The "errors only" button and clear filters are worth adding as dedicated UI elements rather than relying on the filter row alone. During a production incident, people are moving fast and don't want to type.

What actually breaks at scale

A few things that will bite you in production that aren't obvious from a demo:

Timestamps with milliseconds tend to be stored as strings in logs, and string comparison sorts them lexicographically correctly only if the format is ISO 8601 with zero-padded fields. If your backend sends 1/5/2026 9:04:03 AM, sorting breaks. Parse to Date objects or to epoch milliseconds before putting them in the buffer.

Message columns with ANSI escape codes from terminal output look like noise: \x1b[32mINFO\x1b[0m connected. Strip escape codes server-side or in a column valueFormatter before render.

If you're rendering 10k rows with conditionalFormat on every column, measure. Conditional formatting runs a comparison per cell per render. For a log viewer where most rows are INFO, short-circuiting on the common case (checking for ERROR first) keeps the hot path fast.

The grid itself isn't the bottleneck at typical log volumes. The bottleneck is usually JSON.parse on the WebSocket messages, or Svelte reactivity triggered on every individual append. Batching at the data layer - not at the grid layer - is where you get the performance back.

Lazy-Loading Master-Detail Content in SvGrid

Kamelia M — Fri, 07 Aug 2026 07:12:00 GMT

A grid with 2,000 orders should not fire 2,000 API calls. Yet that is exactly what happens when detail panels load up front. The fix is straightforward: fetch only when someone actually expands a row, cache results so collapsing and re-expanding costs nothing, and cancel any in-flight request if the user changes their mind before data arrives.

This pattern is not complex, but there are a few places to get it wrong. Here is a solid recipe that handles all three concerns.

Detail data fetched only on expand, cached on subsequent opens.

Why up-front loading fails at scale

The intuitive approach is to prepare detail data for every row when the grid initializes. It works fine on a demo dataset of 20 rows. At 500 rows it bogs down the page load. At 5,000 it makes the grid unusable.

The root problem is that a user typically opens a handful of rows - rarely more than a dozen in a session. Loading detail for every row to support those few is wasteful by definition. The fix is demand-driven loading: nothing fetches until the row actually opens.

Fetching on expand with Svelte's await block

SvGrid passes a row object into your detail snippet. That is the trigger point. Wrap the fetch in {#await} and Svelte handles the three states - loading, success, and error - without any extra state variables:



{#snippet detailPanel({ row }: { row: Order })}
  {#await fetchLineItems(row.id)}
    
       Loading line items...
    
  {:then items}
    
      
    
  {:catch err}
    
      Failed to load. 
    
  {/await}
{/snippet}

The grid renders immediately. fetchLineItems does not run until the user expands a row. Svelte's reactive {#await} block takes care of the rest.

Caching so the second open is instant

The snippet above re-fetches every time a row is expanded. Collapsing and re-opening the same order should not round-trip to the server again. The cleanest way to prevent that is to cache the promise, not the result:

// lib/line-item-cache.ts
const cache = new Map>()

export function fetchLineItems(orderId: string): Promise {
  if (!cache.has(orderId)) {
    cache.set(orderId, fetchFromApi(orderId))
  }
  return cache.get(orderId)!
}

async function fetchFromApi(orderId: string): Promise {
  const res = await fetch(`/api/orders/${orderId}/line-items`)
  if (!res.ok) throw new Error(`HTTP ${res.status}`)
  return res.json()
}

// Call this if the user edits an order and you need to bust the cache
export function invalidate(orderId: string) {
  cache.delete(orderId)
}

Caching the promise (not the resolved data) means two expansions that fire before the first fetch completes both get the same promise - no duplicate requests. It is a subtle point that matters in grids where someone can expand rows rapidly.

Cancelling abandoned requests

Users scroll fast. Someone might expand row 47, start reading, then collapse it and jump to row 120. If the line-items request for row 47 is still in flight, it is waste. Cancel it.

// lib/line-item-cache.ts (revised to support cancellation)
const cache = new Map>()
const controllers = new Map()

export function fetchLineItems(orderId: string): Promise {
  if (cache.has(orderId)) return cache.get(orderId)!

  const controller = new AbortController()
  controllers.set(orderId, controller)

  const promise = fetch(`/api/orders/${orderId}/line-items`, {
    signal: controller.signal,
  })
    .then(res => {
      if (!res.ok) throw new Error(`HTTP ${res.status}`)
      return res.json() as Promise
    })
    .finally(() => {
      controllers.delete(orderId)
    })

  cache.set(orderId, promise)
  return promise
}

export function cancelFetch(orderId: string) {
  controllers.get(orderId)?.abort()
  // Remove from cache so a future expand retries cleanly
  cache.delete(orderId)
}

export function invalidate(orderId: string) {
  cancelFetch(orderId)
}

Wire cancelFetch into a collapse handler if you want strict cancellation. In practice, aborting only matters for slow connections or very large payloads - for sub-200ms API responses, the extra plumbing may not be worth it. Know your p99 latency before adding complexity.

How this interacts with row virtualization

SvGrid virtualizes rows by default. Only the rows currently visible in the viewport render - detail snippets included. That means an expanded row that scrolls out of view unmounts its detail panel, and when it scrolls back in, {#await} re-runs. With caching in place, re-running hits the cache immediately and the panel appears without a flash or refetch.

Without caching, every re-enter into the viewport triggers a fresh request. On a fast connection you might not notice. On a slow one, or when the detail panel contains a nested grid that itself needs settling time, the repeated fetch becomes visible jank. Cache the promise.

Nested grids inside detail panels

If the detail content is itself a (orders -> line items, accounts -> transactions), there is one sizing concern worth knowing: the outer grid does not know the inner grid's height until it renders. Set an explicit height on the detail panel container so the outer grid can allocate space cleanly:

{#snippet detailPanel({ row }: { row: Order })}
  {#await fetchLineItems(row.id)}
    Loading...
  {:then items}
    
      
    
  {:catch}
    Load failed.
  {/await}
{/snippet}

A fixed height also avoids layout shifts when data arrives - the outer grid reserves the space during the loading state and nothing reflows when items populate the inner grid.

When to skip caching

Short sessions, frequently updated data, or detail panels where freshness matters more than speed. If your order line items can change in the seconds between a user opening and closing a row, stale cache is a real risk. In that case, either skip the cache entirely or pair it with a short TTL:

const cache = new Map, ts: number }>()
const TTL = 30_000 // 30 seconds

export function fetchLineItems(orderId: string): Promise {
  const entry = cache.get(orderId)
  if (entry && Date.now() - entry.ts < TTL) return entry.promise

  const promise = fetch(`/api/orders/${orderId}/line-items`).then(r => r.json())
  cache.set(orderId, { promise, ts: Date.now() })
  return promise
}

Thirty seconds is usually enough to cover the "collapse and immediately re-open" case while keeping data reasonably fresh. Adjust based on how often your backend data actually changes.

The core principle stays constant: pay for only what the user looks at, serve it instantly if they look again, and clean up what they walked away from.

Building an IoT Sensor Dashboard in Svelte

Victor Vidolov — Thu, 06 Aug 2026 07:12:00 GMT

A factory floor with 800 sensors reporting every two seconds gives you 1,600 row updates per second. A naive grid implementation will drop frames, leak memory, or just lock the browser. The grid has to be smarter than a spreadsheet.

A live, updating dashboard grid in SvGrid.

This post walks through the actual architecture for an IoT dashboard: batched updates keyed by device ID, sparkline cells tracking recent history, conditional formatting for threshold breaches, and stale-sensor detection. These are the pieces that distinguish a real production dashboard from a demo.

Why raw websocket events will wreck your frame rate

The instinct is to wire a WebSocket directly to the grid: message arrives, call api.applyTransaction({ update: [row] }), done. This works fine at a handful of updates per second. It falls apart when sensors report fast enough that you're calling applyTransaction 50 times between two animation frames.

The fix is a pending-updates map keyed by sensor ID. New readings overwrite old ones in the map, and a single requestAnimationFrame callback drains the whole map in one transaction per frame. You never render more than once per frame regardless of update volume.

import { type SvGridApi } from '@svgrid/grid'

let api: SvGridApi

// called by your WebSocket message handler
const pending = new Map()
let flushScheduled = false

function onReading(reading: SensorRow) {
  pending.set(reading.id, reading)
  if (!flushScheduled) {
    flushScheduled = true
    requestAnimationFrame(flush)
  }
}

function flush() {
  flushScheduled = false
  if (!api || pending.size === 0) return

  const updates = [...pending.values()]
  pending.clear()

  api.applyTransaction({ update: updates })
}

With 800 sensors all firing at 2 Hz, you still only call applyTransaction 60 times per second, each batch containing however many updates arrived since the last frame. The grid renders once, not 1,600 times.

Column layout for sensor data

The column structure matters. Sensor dashboards are scanned visually, so information density and visual hierarchy both need attention.

import SvGrid from '@svgrid/grid'
import {
  type ColumnDef,
  tableFeatures,
  rowSortingFeature,
  columnFilteringFeature,
  rowSelectionFeature,
  buildSparkline,
  resolveCellFormat,
} from '@svgrid/grid'

type SensorRow = {
  id: string
  name: string
  zone: string
  value: number
  unit: string
  history: number[]
  status: 'ok' | 'warning' | 'critical'
  lastSeen: number // unix ms
}

const features = tableFeatures({
  rowSortingFeature,
  columnFilteringFeature,
  rowSelectionFeature,
})

const columns: ColumnDef[] = [
  {
    id: 'name',
    field: 'name',
    header: 'Sensor',
    width: 200,
    pinned: 'left',
  },
  {
    id: 'zone',
    field: 'zone',
    header: 'Zone',
    width: 120,
  },
  {
    id: 'value',
    field: 'value',
    header: 'Reading',
    width: 110,
    type: 'number',
    cell: valueCellSnippet,
    conditionalFormat: [
      {
        condition: ({ row }) => row.original.status === 'critical',
        style: { color: '#c0392b', fontWeight: 'bold' },
      },
      {
        condition: ({ row }) => row.original.status === 'warning',
        style: { color: '#e67e22' },
      },
    ],
  },
  {
    id: 'trend',
    field: 'history',
    header: 'Trend',
    width: 120,
    cell: ({ value }) => buildSparkline(value, { color: '#3b82f6', height: 28 }),
  },
  {
    id: 'status',
    field: 'status',
    header: 'Status',
    width: 100,
    cell: statusCellSnippet,
  },
  {
    id: 'lastSeen',
    field: 'lastSeen',
    header: 'Last Seen',
    width: 130,
    cell: lastSeenCellSnippet,
  },
]

Pin the sensor name left so it stays anchored while users scroll through data columns. The trend sparkline renders inline from the rolling history array - every update appends the new value and trims the oldest, so the cell always shows the last N readings without extra state.

Threshold alerts with conditional row styling

Color alone is not enough for alerts - about 8% of men have some form of color blindness, and dashboards are often viewed in bright ambient light. Pair color with a status badge.

{#snippet statusCellSnippet({ value })}
  
    {#if value === 'critical'}
      Critical
    {:else if value === 'warning'}
      Warning
    {:else}
      OK
    {/if}
  
{/snippet}

{#snippet valueCellSnippet({ value, row })}
  {value} {row.original.unit}
{/snippet}

{#snippet lastSeenCellSnippet({ value })}
  {@const age = Date.now() - value}
  {@const isStale = age > 30_000}
  
    {isStale ? `${Math.round(age / 1000)}s ago` : 'live'}
  
{/snippet}

For threshold logic, compute status when processing each incoming reading - that way the grid only stores the derived value and the conditional format check is a simple string comparison. Don't put the threshold comparison inside the cell renderer; that runs on every render.

Stale-sensor detection

A sensor that stops reporting is itself a failure mode - often more critical than a high reading, because a dead sensor means you have no visibility into that zone. The lastSeen timestamp handles this. Set a background interval to touch the grid with a status recalculation pass every 10-15 seconds, which flags any sensor that has not reported in your staleness threshold (typically 30s to 2 minutes depending on the sensor's expected report interval).

// Recompute stale status periodically, independent of incoming readings
setInterval(() => {
  const now = Date.now()
  const staleThreshold = 30_000

  const updates = api.getData()
    .filter(row => now - row.lastSeen > staleThreshold && row.status !== 'stale')
    .map(row => ({ ...row, status: 'stale' as const }))

  if (updates.length > 0) {
    api.applyTransaction({ update: updates })
  }
}, 10_000)

This keeps the staleness state in the grid's data layer rather than in a parallel reactive store, which means sorting by status will correctly sort stale sensors alongside critical and warning ones.

Keeping critical sensors visible

Once you have status data, let users sort critical sensors to the top. Call this on initial load and expose it as a button for operators who want to see the worst-case view:

function pinCriticalToTop() {
  api.setSort('status', 'asc') // 'critical' < 'ok' < 'warning' alphabetically - adjust to your sort order
}

// Or use a custom sort comparator if your order is critical -> warning -> ok
function showWorstFirst() {
  const order = { critical: 0, warning: 1, stale: 2, ok: 3 }
  api.setSort('status', 'asc', {
    compareFn: (a, b) => (order[a] ?? 4) - (order[b] ?? 4),
  })
}

Scale considerations

Virtualization handles the rendering side - even with 5,000 sensors, only the visible rows are in the DOM at any time. The batched-update pattern above handles the JavaScript side. The third constraint is memory: rolling history arrays that grow without bound will eventually exhaust heap. Cap them explicitly when you push new readings.

For very large sensor fleets grouped by zone or building, keep live updates scoped to the currently visible group. Expand the zone in the grid and subscribe to that zone's feed; collapse it and unsubscribe. Server-side grouping with createServerDataSource works well here - paginate by zone, push live updates only for the active page.

import { createServerDataSource } from '@svgrid/grid'

const ds = createServerDataSource({
  fetch: async ({ page, pageSize, sort, filters }) => {
    const params = new URLSearchParams({
      page: String(page),
      size: String(pageSize),
      zone: activeZone,
    })
    const json = await fetch(`/api/sensors?${params}`).then(r => r.json())
    return { rows: json.data, total: json.total }
  },
})

The combination of batched RAF updates, sparkline history cells, conditional status formatting, and stale-device detection covers most of what makes an IoT dashboard genuinely useful to the operators watching it. Each piece is independent - you can start with just the batched updates and add sparklines and alerts incrementally.

Building an Inventory Management Grid in Svelte

Boyko Markov — Wed, 05 Aug 2026 07:12:00 GMT

Warehouse staff don't read dashboards. They glance at a grid for three seconds, find the row that's wrong, fix the number, and move on. If the grid makes that hard - slow saves, no visual hierarchy, no keyboard navigation - they work around it with sticky notes and spreadsheets. Building an inventory grid that people actually trust means getting those fundamentals right before adding anything else.

Threshold and anomaly highlighting applied to stock levels.

Column layout that works at a glance

The column order matters. SKU and product name go on the left and get pinned so they stay visible when scrolling right. Quantity columns - on hand, reserved, available - come next, right-aligned and formatted as integers. Then reorder level, status badge, and last-updated date on the right.

import SvGrid from '@svgrid/grid'
import type { ColumnDef } from '@svgrid/grid'

interface InventoryRow {
  sku: string
  product: string
  onHand: number
  reserved: number
  available: number
  reorderLevel: number
  status: 'in-stock' | 'low' | 'out'
  updatedAt: string
}

const columns: ColumnDef[] = [
  { id: 'sku', field: 'sku', header: 'SKU', width: 110, pinned: 'left' },
  { id: 'product', field: 'product', header: 'Product', width: 240, pinned: 'left' },
  { id: 'onHand', field: 'onHand', header: 'On Hand', width: 100, type: 'number', editable: true },
  { id: 'reserved', field: 'reserved', header: 'Reserved', width: 100, type: 'number' },
  { id: 'available', field: 'available', header: 'Available', width: 110, type: 'number',
    conditionalFormat: [
      { condition: ({ value }) => value <= 0, style: { color: '#dc2626', fontWeight: '700' } },
      { condition: ({ value, row }) => value > 0 && value <= (row as InventoryRow).reorderLevel,
        style: { color: '#d97706', fontWeight: '600' } },
    ]
  },
  { id: 'reorderLevel', field: 'reorderLevel', header: 'Reorder At', width: 110, type: 'number' },
  { id: 'status', field: 'status', header: 'Status', width: 100, cell: statusBadge },
  { id: 'updatedAt', field: 'updatedAt', header: 'Updated', width: 140, type: 'date' },
]

Pinning SKU and product means a user can scroll to the reserved/reorder columns without losing context. That's a small thing that warehouse staff will notice on day one.

Making low stock impossible to miss

Color alone is not enough - someone will always be working in a washed-out environment or have reduced color vision. The right approach combines a tinted row, a colored cell value, and a text badge that says "Low" or "Out" explicitly.

Row-level tinting comes from a rowClass function. Cell-level color comes from conditionalFormat (shown in the column def above). The status badge is a Svelte snippet that renders both a color dot and a text label.



{#snippet statusBadge({ value }: { value: string })}
  
    {#if value === 'out'}Out{/if}
    {#if value === 'low'}Low{/if}
    {#if value === 'in-stock'}In Stock{/if}
  
{/snippet}

 { gridApi = api }}
/>

The rowClass function is evaluated per row during render. Returning an empty string for in-stock rows means no extra DOM attribute to strip - it just skips the class entirely.

Inline editing that doesn't interrupt the workflow

The on-hand column is where edits happen. A warehouse worker receives a shipment, tabs to a row, hits a number, presses Enter, and expects the cursor to drop to the next row - exactly like a spreadsheet. SvGrid's default editing behavior handles that: Enter commits the edit and moves down, Escape cancels it.

For saves, I recommend optimistic updates rather than waiting on a network round-trip. Update the local row immediately, fire the API call in the background, and only revert if it fails. The grid's applyTransaction API is the right tool here.

import { createServerDataSource } from '@svgrid/grid'

async function handleCellEdit(event: { rowIndex: number; field: string; newValue: unknown; row: InventoryRow }) {
  const { rowIndex, field, newValue, row } = event

  // Optimistic: update local state immediately
  gridApi.applyTransaction({
    update: [{ ...row, [field]: newValue }]
  })

  // Derive status from the new available count
  const updated = { ...row, [field]: newValue }
  const newStatus = updated.available <= 0
    ? 'out'
    : updated.available <= updated.reorderLevel
    ? 'low'
    : 'in-stock'

  try {
    await fetch(`/api/inventory/${row.sku}`, {
      method: 'PATCH',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify({ [field]: newValue, status: newStatus }),
    })
  } catch {
    // Revert on failure
    gridApi.applyTransaction({ update: [row] })
  }
}

One thing to keep in mind: when on-hand changes, available usually changes too (available = on-hand - reserved). If that derived column isn't recalculated before the grid re-renders, you'll show stale data. Either compute it server-side and return the full updated row, or derive it inline in the edit handler before calling applyTransaction.

Undo/redo (api.undo() / api.redo()) is worth enabling too. Reconciliation errors happen when someone enters 120 instead of 12. Ctrl+Z is the fastest recovery path.

Bulk operations and filtering for action

The filter row is your friend in an inventory grid. Filtering by status = "low" or "out" lets a buyer see exactly what needs reordering - far more useful than scrolling through 4000 SKUs. Filtering by supplier or category narrows the list for a category manager doing a cycle count.

For bulk updates (marking a batch discontinued, applying a restock to a supplier's range), select the filtered rows and apply a transaction to all of them:

function markSelectedDiscontinued() {
  const selected = gridApi.getSelectedRows()
  const updates = selected.map(row => ({ ...row, status: 'out', reorderLevel: 0 }))
  gridApi.applyTransaction({ update: updates })
  // then POST to /api/inventory/bulk
}

function restockSelected(quantity: number) {
  const selected = gridApi.getSelectedRows()
  const updates = selected.map(row => ({
    ...row,
    onHand: row.onHand + quantity,
    available: row.available + quantity,
    status: (row.available + quantity) > row.reorderLevel ? 'in-stock' : 'low',
  }))
  gridApi.applyTransaction({ update: updates })
}

This pattern - filter to a meaningful subset, select all, apply a named operation - covers most of the bulk editing scenarios I've seen in practice.

CSV import for cycle counts

Physical inventory counts still come back as spreadsheets. The import flow I use: parse the CSV client-side with a small utility, match rows by SKU, compute the delta between counted and on-hand, then load into the grid for review before committing. The reviewer sees a diff - rows where the counted quantity diverges from the system quantity are tinted. Approving the diff calls applyTransaction with the updates.

For large catalogs (tens of thousands of SKUs), push filtering and sorting server-side with createServerDataSource. The client never needs to hold the full dataset:

import { createServerDataSource } from '@svgrid/grid'

const ds = createServerDataSource({
  fetch: async ({ page, pageSize, sort, filters }) => {
    const params = new URLSearchParams({
      page: String(page),
      size: String(pageSize),
      ...(sort?.[0] ? { sortField: sort[0].id, sortDir: sort[0].desc ? 'desc' : 'asc' } : {}),
    })
    filters.forEach(f => {
      params.set(`filter_${f.id}`, String(f.value))
    })
    const res = await fetch(`/api/inventory?${params}`)
    const json = await res.json()
    return { rows: json.items, total: json.total }
  }
})

Server-side paging with a 50-row page size keeps the initial load fast even for a catalog of 100k products. The filter row still works - it just drives server-side query parameters instead of client-side predicate functions.

What I'd prioritize for a first version

The order matters: get the column layout and low-stock highlighting right first, because those affect every session. Inline editing with optimistic saves comes next, because that's the core interaction. Bulk operations and CSV import can come in a later sprint - they're high-value but not every user needs them on day one.

The grid being fast matters more than it being feature-complete. Warehouse staff develop muscle memory. If the grid responds in under 50ms to a keypress, they'll trust it. If it hesitates on every edit, they'll go back to spreadsheets.

Importing CSV into a Svelte Data Grid

Boyko Markov — Tue, 04 Aug 2026 07:12:00 GMT

CSV is the file format that never dies. Every enterprise client has a spreadsheet export they want to "just upload," and no two of them look the same. Quoted commas, BOM characters, inconsistent date formats, trailing newlines - the actual parsing is maybe five percent of the work. The rest is defense.

With SvGrid the rendering side is trivial: get an array of objects and set it as data. The challenge is building a pipeline that transforms an untrusted file into something the grid can display without silent data corruption.

A spreadsheet-style SvGrid grid loaded with imported data.

Getting the file into memory

Start with a plain file input scoped to CSV types. The browser's File API gives you a text() method that returns the raw content as a string - no library needed for this part.





{#if parseError}
  {parseError}
{:else if importedRows.length > 0}
  
{/if}

Why naive splitting fails

The first instinct is row.split(','). That works until someone uploads a CSV where a field value contains a comma - like "Smith, John" or "$1,200.00". RFC 4180 allows commas inside quoted fields, and real exports from Excel, Google Sheets, and every accounting system use them constantly.

A correct parser needs to handle: quoted fields with embedded commas, escaped quotes (""), newlines inside quoted fields, and optionally a UTF-8 BOM at the start of the file. Writing that from scratch is doable but tedious. There are small, well-tested libraries (PapaParse being the most popular) or you can write a state-machine parser once and reuse it.

Here is a minimal but correct parser that covers the cases that actually come up:

function parseCsv(raw: string): Record[] {
  // strip UTF-8 BOM if present
  const text = raw.startsWith('') ? raw.slice(1) : raw

  const lines: string[][] = []
  let current: string[] = []
  let field = ''
  let inQuotes = false

  for (let i = 0; i < text.length; i++) {
    const ch = text[i]

    if (inQuotes) {
      if (ch === '"') {
        if (text[i + 1] === '"') {
          field += '"'
          i++
        } else {
          inQuotes = false
        }
      } else {
        field += ch
      }
    } else {
      if (ch === '"') {
        inQuotes = true
      } else if (ch === ',') {
        current.push(field)
        field = ''
      } else if (ch === '\n' || (ch === '\r' && text[i + 1] === '\n')) {
        if (ch === '\r') i++
        current.push(field)
        field = ''
        if (current.some(Boolean)) lines.push(current)
        current = []
      } else {
        field += ch
      }
    }
  }

  if (field || current.length) {
    current.push(field)
    if (current.some(Boolean)) lines.push(current)
  }

  if (lines.length < 2) throw new Error('CSV has no data rows')

  const [headers, ...body] = lines
  return body.map((cells) =>
    Object.fromEntries(headers.map((h, i) => [h.trim(), (cells[i] ?? '').trim()]))
  )
}

The BOM strip is easy to forget and causes undefined values when the first column header is name instead of name. It shows up in every Excel-exported CSV.

Validating rows before they hit the grid

Loading raw strings into the grid and calling it done is how you end up with NaN in number columns and broken sorts. Do a validation pass after parsing: coerce types, flag bad rows, and give the user a chance to see what will be skipped.

type ValidationResult = {
  valid: Row[]
  invalid: Array<{ row: Record; reason: string; index: number }>
}

function validateRows(
  raw: Record[],
  fieldMap: Record
): ValidationResult {
  const valid: Row[] = []
  const invalid: ValidationResult['invalid'] = []

  raw.forEach((rawRow, index) => {
    const mapped: Row = {}
    let reason: string | null = null

    for (const [csvHeader, field] of Object.entries(fieldMap)) {
      const raw = rawRow[csvHeader] ?? ''

      if (field === 'amount') {
        const n = parseFloat(raw.replace(/[,$]/g, ''))
        if (isNaN(n)) {
          reason = `Row ${index + 2}: "${raw}" is not a valid amount`
          break
        }
        mapped[field] = n
      } else if (field === 'email') {
        if (raw && !raw.includes('@')) {
          reason = `Row ${index + 2}: "${raw}" is not a valid email`
          break
        }
        mapped[field] = raw
      } else {
        mapped[field] = raw
      }
    }

    if (reason) {
      invalid.push({ row: rawRow, reason, index })
    } else {
      valid.push(mapped)
    }
  })

  return { valid, invalid }
}

The fieldMap parameter is a mapping from CSV header names to your grid's field names - which brings up the next real-world problem.

Header mapping

Users rarely export a file where the column names match your schema. Their file has Full Name, yours expects name. Their file has Invoice Total (USD), yours expects amount.

The right approach is an explicit mapping step: show the CSV headers on the left, offer a dropdown of your grid columns on the right, and auto-select when the names are close enough. For exact matches you can auto-map; for everything else let the user decide.

A minimal mapping state in Svelte 5 looks like:



{#each csvHeaders as header}
  
    {header} ->
    
  
{/each}

The normalization function (norm) handles the common case where Full Name should match fullName or full_name. Beyond that, you need human judgment, and the UI should make that easy.

Large files and the UI thread

For files under a few thousand rows, synchronous parsing is fine. For anything larger - say 50,000 rows from a data export - parsing on the main thread will freeze the browser briefly. The right fix is a Web Worker: post the raw text, get back the parsed rows.

Once the data is in the grid, virtualization handles rendering. SvGrid only renders the visible viewport regardless of how many rows exist, so 100,000 imported rows scroll the same as 100. Set virtualization={true} (it defaults on for large datasets) and you do not need to page the data client-side.

Showing a preview before committing

For any destructive or bulk operation, a preview step pays for itself in support tickets avoided. After parsing and validation, show the grid with a count of valid and invalid rows, let the user scan the data, and only then offer a "Confirm import" button. Calling api.applyTransaction({ add: validRows }) on confirm means you can also support incremental imports into an existing dataset rather than replacing the whole thing.



{#if showPreview}
  
    {validRows.length} rows will be imported, {invalidRows.length} skipped.
     { api = a }} />
    
  
{/if}

The pattern works for CSV today and for XLSX or JSON tomorrow - the grid does not care how the data arrived, only that it is an array of objects that match the column field names.

Immutable Grid Updates Without Killing Performance

Kamelia M — Mon, 03 Aug 2026 07:12:00 GMT

Cloning the entire dataset on every change is technically immutable and practically a disaster. If you have 50,000 rows and a live feed pushing updates at 60Hz, you are allocating 50,000 objects 60 times per second and handing the garbage collector a full-time job. Meanwhile, every row looks new to the grid's change detection, so everything repaints - even the rows that did not change.

There is a better model. You do not need full immutability. You need structural sharing: new references for what changed, shared references for everything else.

What the grid actually checks

SvGrid's reactivity (built on Svelte 5 signals) decides whether to repaint a row by comparing object identity. Same reference means nothing changed, skip it. New reference means something changed, update the DOM.

This is fast when it is precise. One row changed? One new reference, one repaint. But if your update strategy produces a new reference for every row regardless of what actually changed, you have traded the CPU cost of diffing for the memory cost of allocating - and you have not saved any renders.

import SvGrid from '@svgrid/grid'

// WRONG: every row is a brand-new object on every update
// The grid sees 50,000 changed rows when one cell was edited
function updateBad(i: number, field: string, value: unknown) {
  data = data.map((r) => ({ ...r }))
}

// RIGHT: new reference only for the changed row, shared ref for everything else
function updateRow(i: number, field: string, value: unknown) {
  const next = data.slice()                       // new array, O(n) but cheap
  next[i] = { ...data[i], [field]: value }        // new object only for row i
  data = next                                     // rows[j !== i] keep their references
}

The slice() call is O(n) but it only copies an array of pointers, not the objects themselves. The objects at every index except i are the same reference they always were. The grid skips them.

Hooking into the edit lifecycle

SvGrid's onCellEdit callback is where you apply these updates. The grid calls it after the user commits a change, passing you the row index, column id, and new value.

The assignment data = next triggers Svelte's reactivity. Because next is a new array reference, the grid knows something changed. But row objects at every index except rowIndex are the same references as before, so the grid skips them.

Nested objects: copy the path, not the tree

If your rows contain nested objects - say an address field with city, zip, etc. - the same principle applies, one level deeper. Copy from the root of the mutation down to the changed field, sharing everything else.

type Row = {
  id: number
  name: string
  address: { city: string; zip: string; country: string }
  metrics: { views: number; clicks: number; ctr: number }
}

function updateCity(i: number, city: string) {
  const next = data.slice()
  next[i] = {
    ...data[i],
    address: {
      ...data[i].address,  // share zip, country
      city,                // only city is new
    },
    // metrics keeps its reference - not touched
  }
  data = next
}

data[i].metrics is the same object reference before and after. If something downstream is watching metrics, it will not fire. The update is scoped exactly to the changed subtree.

Batch updates and `applyTransaction`

Surgical copies are great for single-cell edits. When you need to update, add, or remove many rows at once - say syncing a page of server results - use applyTransaction instead. It accepts add, update, and remove arrays and applies them in one pass.

import SvGrid, { type SvGridApi } from '@svgrid/grid'

let api: SvGridApi

// Called from a polling loop, WebSocket handler, or server sync
function syncFromServer(patch: {
  add: Row[]
  update: { id: number; changes: Partial }[]
  remove: number[]
}) {
  api.applyTransaction({
    add: patch.add,
    update: patch.update.map(({ id, changes }) => {
      const existing = data.find((r) => r.id === id)!
      return { ...existing, ...changes }  // surgical merge per row
    }),
    remove: patch.remove,
  })
}

applyTransaction handles the structural sharing internally. You do not need to manage array slicing yourself - just pass the minimal delta and the grid does the rest.

When to reach for Immer

If your row type is deeply nested and mutations are complex, Immer is a reasonable tool. It gives you a draft-based API that feels mutable but produces structurally-shared immutable results.

import { produce } from 'immer'

function deepUpdate(i: number, updater: (row: Row) => void) {
  data = produce(data, (draft) => {
    updater(draft[i])
  })
}

// Usage
deepUpdate(3, (row) => {
  row.address.city = 'Berlin'
  row.metrics.clicks += 1
})

Immer's overhead is small enough that it rarely matters for interactive edits. For high-frequency updates - a live trading feed pushing hundreds of updates per second - hand-written surgical copies are measurably leaner. At that point you are updating specific known fields, not navigating arbitrary nested paths, so the verbosity is manageable.

The threshold I use: if your update rate is under ~100/sec and the nesting is more than two levels deep, Immer is probably the better tradeoff. Above that rate, profile first, then optimize.

The one trap: accidental mutation

Structural sharing only works if you never mutate objects in place. If you write data[i].price = newValue directly, the object reference does not change, Svelte's reactivity does not fire, and the grid does not update. You get silent staleness.

The fix is straightforward: treat row objects as read-only once they are in the array. If you are working with TypeScript, Readonly at the type level will surface accidental mutations at compile time rather than at runtime. It is a small annotation that has saved me from debugging confusing stale-state bugs more than once.

// TypeScript will catch mutations before they reach production
const columns: ColumnDef>[] = [
  { id: 'name', field: 'name', header: 'Name', width: 200, editable: true },
  // ...
]

The grid does not care whether your type is Readonly or not - it is a compile-time guard for your own code. Pair it with the surgical-copy pattern in your event handlers and you get both safety and performance.

Immutable Data Updates in Svelte 5

Victor Vidolov — Sun, 02 Aug 2026 07:12:00 GMT

Svelte 5's deep reactivity is genuinely good news. $state proxies your arrays and objects so both mutation and reassignment trigger updates. The bad news: that flexibility makes it easy to do the right thing by accident, and the wrong thing without noticing until your grid starts repainting everything on every keystroke.

The core question when working with list data is not "will Svelte detect this?" - it will. The question is "how expensive will the re-render be, and will components that key off identity behave correctly?"

What Svelte 5 actually tracks

Svelte 4 required assignment to trigger reactivity. Svelte 5 removes that constraint with proxy-based $state:

let rows = $state([])

// All of these are tracked in Svelte 5:
rows.push(newRow)           // mutation - works
rows[0].name = 'Ada'        // deep mutation - works
rows = [...rows, newRow]    // reassignment - also works

That last form - spread into a new array - is what most "immutable updates" guides recommend. It works, but it creates a new reference for every item in the array, which has implications for anything downstream that compares by reference.

Reference identity and why grids care

A data grid maintains state keyed to rows: which row is selected, which cell is being edited, which group is expanded. It maps that state to your data using row identity - either an index or a stable ID field you provide.

When you replace an entire array with a spread, every row becomes a new object in memory. If the grid is checking oldRow === newRow to decide what changed, it sees everything as changed and repaints the full viewport. For small datasets this is invisible. At 10,000+ rows with virtualization, it shows up as a noticeable stutter.

The fix is surgical replacement: only create a new object for the row that actually changed, and leave the others untouched.

import SvGrid, { type ColumnDef, tableFeatures, rowSelectionFeature } from '@svgrid/grid'

// Updating a single field in a single row - surgical, reference-stable
function updateStatus(rowIndex: number, newStatus: string) {
  rows[rowIndex] = { ...rows[rowIndex], status: newStatus }
  // rows[rowIndex] is a new reference
  // rows[0], rows[1], ... rows[rowIndex - 1], rows[rowIndex + 1] etc. are unchanged
}

// Adding a row at the end
function addRow(row: Row) {
  rows.push(row)
  // existing references are untouched
}

// Removing a row by index
function removeRow(rowIndex: number) {
  rows.splice(rowIndex, 1)
  // in-place mutation - existing references above the splice point are stable
}

Contrast with the pattern that looks similar but kills reference stability:

// This replaces every row reference even though only one changed
rows = rows.map((r, i) => i === rowIndex ? { ...r, status: newStatus } : { ...r })
//                                                                          ^^^^^^^
//                                                                  pointless new objects

The version above is doubly wrong: it rebuilds untouched rows as new objects, and it does a full reassignment, so the grid sees every row as changed.

Updating nested fields

Nested objects need the same care. Copy along the path you're changing, not the entire tree:

type Order = {
  id: number
  customer: { name: string; email: string }
  items: { sku: string; qty: number }[]
  total: number
}

let orders = $state([])

// Change just the customer email
function updateEmail(orderIndex: number, newEmail: string) {
  orders[orderIndex] = {
    ...orders[orderIndex],
    customer: {
      ...orders[orderIndex].customer,
      email: newEmail,
    },
  }
  // orders[orderIndex].items references are preserved
  // other orders are untouched
}

// Add an item to a specific order
function addItem(orderIndex: number, item: { sku: string; qty: number }) {
  orders[orderIndex] = {
    ...orders[orderIndex],
    items: [...orders[orderIndex].items, item],
  }
}

The guiding principle: new reference only at the level you changed and every ancestor up to the root array. Siblings and unrelated branches stay the same.

Using the grid's transaction API

For bulk mutations - adding, updating, and removing multiple rows at once - the applyTransaction method is the right tool. It handles all the reference bookkeeping internally:

import SvGrid, {
  type ColumnDef,
  type SvGridApi,
  tableFeatures,
  rowSelectionFeature,
  columnFilteringFeature,
} from '@svgrid/grid'

let api: SvGridApi | null = null

const features = tableFeatures({ rowSelectionFeature, columnFilteringFeature })

const columns: ColumnDef[] = [
  { id: 'id', field: 'id', header: 'ID', width: 80 },
  { id: 'customer', field: 'customer.name', header: 'Customer', width: 200 },
  { id: 'total', field: 'total', header: 'Total', width: 120, type: 'number' },
  { id: 'status', field: 'status', header: 'Status', width: 120 },
]

// Sync result of a server action back into the grid
async function syncFromServer() {
  const diff = await fetchPendingChanges()

  api?.applyTransaction({
    add: diff.created,
    update: diff.updated,   // matched by row identity
    remove: diff.deleted,   // removes by id
  })
}

applyTransaction is designed to be called frequently - after websocket messages, polling intervals, or optimistic UI rollbacks. It processes only what changed rather than replacing the whole dataset.

Pitfalls worth knowing

Shared object references across rows. If two rows point to the same nested object and you mutate it directly, both rows appear changed. Clone when you need independence:

// If importing from an API that reuses objects across records, clone on intake
let rows = $state(apiResponse.map(r => ({ ...r, meta: { ...r.meta } })))

External non-reactive data. Arrays from props or stores are not automatically proxied. Assign them into $state to make updates trackable:

// Not reactive - changes to externalData don't propagate
let rows = externalData

// Reactive - subsequent mutations on rows are tracked
let rows = $state([...externalData])

$state.raw for large stable datasets. If you have a large array that you always replace wholesale (never mutate in place), $state.raw skips the proxy overhead and can be significantly faster. The tradeoff is that in-place mutations are not tracked at all:

// Replace the array to trigger an update; in-place mutations are invisible
let rows = $state.raw([])

function refresh(newData: Row[]) {
  rows = newData  // new reference - triggers update
  rows.push(x)   // silent - won't update
}

Use $state.raw only when your data flow is clearly replace-only - server-side pagination is the typical case.

The mental model that holds up

Think of your data as a tree. When you change a node, you need a new reference for that node and every node from it back to the root. Everything else - siblings, cousins, the other subtrees - should keep its existing reference.

That rule keeps downstream components, selection state, and the grid's own diffing from treating unrelated data as changed. Svelte 5 gives you the flexibility to mutate in place, but for list-backed state that feeds into a grid, the discipline of surgical immutable updates pays for itself quickly once your datasets grow past a few hundred rows.

How We Built Excel-Style Filters

Boyko Markov — Sat, 01 Aug 2026 07:12:00 GMT

Most grid libraries treat filtering as an afterthought - a text box above the table that does a case-insensitive String.includes. Excel-style filtering is what users actually want: per-column menus, type-specific operators, the ability to stack multiple conditions, and results that feel instant. Building that well turned out to require more architectural discipline than the filtering logic itself.

SvGrid's Excel-style column filter menu.

Filtering belongs in the row pipeline, not the renderer

The first decision was structural. Some grids bolt filtering onto rendering - they filter inside the loop that builds visible rows. That's the easy path and also the wrong one, because it makes every downstream feature (sorting, grouping, pagination, selection counts) work with stale totals.

We had already built the row model as an explicit pipeline:

data -> filter -> sort -> group -> paginate -> visible rows

Filtering as a discrete pipeline step means everything downstream sees only surviving rows. Pagination totals are correct. Group counts are correct. "Select all" selects what you see, not the full dataset. You don't get that for free if filtering is tangled with rendering.

The filter model is a map from column id to a condition object. When any entry changes, the pipeline re-derives filtered rows. Nothing else in the grid knows that filtering happened - it just sees a shorter list.

The type problem

Text and numbers look similar in a grid cell. They're completely different to filter. "Greater than 100" on a text column would sort "9" above "100" alphabetically. Dates stored as ISO strings need range handling, not substring matching.

The fix is to filter on typed values, not on display strings. Each column definition knows its value type - text, number, date, boolean - and the filter engine picks operators appropriate to that type and compares raw values:

// column definition
const columns: ColumnDef[] = [
  {
    id: 'name',
    field: 'name',
    header: 'Product',
    width: 220,
    type: 'text',
    // text operators: contains, notContains, equals, startsWith, endsWith, blank
  },
  {
    id: 'price',
    field: 'price',
    header: 'Price',
    width: 120,
    type: 'number',
    // number operators: equals, notEquals, greaterThan, lessThan, between
  },
  {
    id: 'releaseDate',
    field: 'releaseDate',
    header: 'Released',
    width: 140,
    type: 'date',
    // date operators: equals, before, after, between, blank
  },
  {
    id: 'inStock',
    field: 'inStock',
    header: 'In Stock',
    width: 100,
    type: 'boolean',
    // boolean operators: true, false
  },
]

When the user picks "between 100 and 500" on a number column, the engine compares Number(row.price) against 100 and 500. The display string might be "$100.00" - the filter never touches it.

This also means you can apply formatting independently of filtering logic. Currency symbols, date locale strings, percentage signs - none of that leaks into filter comparisons.

Two UIs, one model

Different workflows want different filter UIs. An analyst building a report wants filters always visible. An end user browsing a product list wants them tucked away until needed. We support both modes, driven by the same underlying filter model.

showFilterRow adds an always-visible input row below the headers. filterable on a column (or the grid globally) adds a funnel icon to the header that opens a per-column filter menu. Both write to the same filter model. You can use one, the other, or both at once.

The filter menu variant is the same grid, different props:

Both modes support compound conditions - AND/OR within a column. The menu exposes this as two input rows with a connector selector. The filter row exposes it through the filter menu that appears when you click the active filter indicator.

Setting filters from code

The filter model is also fully addressable through the API. This matters for building filter presets, persisting filter state to a URL, or driving the grid from external controls like a sidebar filter panel.

let api: SvGridApi

// Set a single-condition filter
api.setFilter('price', {
  operator: 'between',
  value: '100',
  valueTo: '500',
})

// Set a compound condition
api.setFilter('category', {
  operator: 'equals',
  value: 'Electronics',
  logicalOperator: 'OR',
  valueTo: 'Accessories',
  operatorTo: 'equals',
})

// Clear one column
api.clearFilter('category')

// Clear everything
api.clearAllFilters()

// Read back the current model (e.g., serialize to URL)
const state = api.getState()
// state.columnFilters is the full filter map

// Restore from URL params on mount
api.setState({ columnFilters: parsedFilters })

The state round-trip is what makes filter persistence practical. Serialize api.getState() to localStorage or URL params, restore it on mount with api.setState(), and users get their filter context back across page loads.

Server-side filtering: same model, different destination

For datasets too large to load into the browser, the filter model travels to the server instead of running in-memory. The createServerDataSource adapter receives the current filter conditions alongside pagination and sort state in each fetch call.

import { createServerDataSource } from '@svgrid/grid'

const ds = createServerDataSource({
  fetch: async ({ page, pageSize, sort, filters }) => {
    const params = new URLSearchParams({
      page: String(page),
      size: String(pageSize),
    })

    // filters is the same filter model the in-memory engine uses
    if (filters.price) {
      params.set('priceMin', filters.price.value ?? '')
      params.set('priceMax', filters.price.valueTo ?? '')
    }
    if (filters.category?.value) {
      params.set('category', filters.category.value)
    }
    if (sort.length) {
      params.set('sortField', sort[0].id)
      params.set('sortDir', sort[0].desc ? 'desc' : 'asc')
    }

    const res = await fetch(`/api/products?${params}`)
    const json = await res.json()
    return { rows: json.data, total: json.total }
  },
})

From the grid's perspective, nothing changes. The same components, the same setFilter API calls, the same filter UI - it just calls your fetch function instead of filtering in-memory. Swapping between in-memory and server-side filtering requires changing one prop, not restructuring your component.

Performance in practice

In-memory filtering on a 50,000-row dataset completes in under 10ms on a mid-range laptop. The filter function runs once per model change and the result is stored as a derived value. Virtualization handles the render side - only the rows in the visible window are ever in the DOM, regardless of how many rows survive the filter.

The one real cost is initial data ingestion. Loading 50,000 rows into $state() takes measurable time if you do it synchronously. The answer there is server-side pagination from the start if your data is that large, or lazy-loading chunks. The filter engine itself is not the bottleneck.

What the pipeline architecture gave us was a feature that plugged in without touching sorting, grouping, or pagination code. The filter step is about 300 lines. The rest of the grid doesn't know it exists - it just sees however many rows made it through.

Going AI-Native: The SvGrid MCP Server

Kamelia M — Fri, 31 Jul 2026 07:12:00 GMT

Ask any AI assistant to scaffold a Svelte data grid and watch what happens. The code looks plausible - column definitions, event handlers, props with sensible names. Then you try to run it. Half the props do not exist. The sort callback signature is wrong. The filtering API is borrowed from a different library. You spend the next twenty minutes debugging code that was never real.

This is not an edge case. It is the baseline experience with any library that is not deeply baked into an assistant's training data. The assistant interpolates from pattern-matches across dozens of grids, produces something that reads as correct, and moves on.

We decided that was not acceptable for SvGrid. The AI integration came last in the build sequence, but it was never optional.

Why AI assistants get grids wrong

The problem has a specific cause. An assistant working from training data is averaging over whatever it saw at crawl time. If you are a mature library with years of Stack Overflow answers, the average is probably close to the real API. If you are newer, or if you have changed your API significantly, the average is noise.

Data grids make this worse because they have large, interconnected APIs. Prop names, feature flag objects, imperative methods, column definition shapes - they vary substantially between libraries, and an assistant reasoning from partial information will confidently combine pieces from different ones. The result compiles visually and fails at runtime.

The only way to fix this is to give the assistant a reliable lookup path.

What `@svgrid/mcp` does

We built @svgrid/mcp as a Model Context Protocol server. MCP is a standard that lets editors like Cursor and Claude Code expose tools an assistant can call during generation. Instead of reasoning from training data alone, the assistant can call a tool, get the real current documentation or example source, and use that as the basis for its output.

For SvGrid specifically the server exposes three things: the live documentation (so feature explanations are accurate), the working example sources (so generated code copies patterns that actually run), and the typed API reference (so prop names and method signatures match what the package exports).

Wiring it in takes one config block:

{
  "mcpServers": {
    "sv-grid": { "command": "npx", "args": ["@svgrid/mcp"] }
  }
}

After that, when you ask your assistant to add server-side pagination to an existing grid, it retrieves the createServerDataSource signature and the relevant example before it writes a single line. What it produces is grounded.

What grounded output actually looks like

The difference shows up immediately when you work with features that have non-obvious shapes. Server-side data is a good test case. An assistant working from training data will typically invent a callback prop or produce an onPageChange handler pattern borrowed from a UI library. With the MCP server it retrieves the real pattern:

import { createServerDataSource } from '@svgrid/grid'
import type { SvGridOptions, ColumnDef, TableFeatures } from '@svgrid/grid'

const ds = createServerDataSource({
  fetch: async ({ page, pageSize, sort, filters }) => {
    const params = new URLSearchParams({
      page: String(page),
      size: String(pageSize),
    })

    if (sort.length) {
      params.set('sort', sort[0].id)
      params.set('dir', sort[0].desc ? 'desc' : 'asc')
    }

    for (const f of filters) {
      params.set(`filter[${f.id}]`, String(f.value))
    }

    const res = await fetch(`/api/data?${params}`)
    const json = await res.json()
    return { rows: json.data, total: json.total }
  },
})

That comes back correctly typed and ready to pass as data to . No invented props, no mismatched callback signatures.

The same holds for the imperative API. An assistant guessing at method names will often get the shape wrong - calling api.sort() instead of api.setSort(), or passing the wrong argument order. With the reference available, it calls what exists:

import SvGrid from '@svgrid/grid'
import type { SvGridApi } from '@svgrid/grid'

let api: SvGridApi | undefined

function applyWorkingFilter() {
  if (!api) return
  api.setFilter('status', { operator: 'equals', value: 'active' })
  api.setFilter('revenue', { operator: 'between', value: '10000', valueTo: '50000' })
  api.setSort('revenue', 'desc')
  api.setPage(1) // reset to first page after filter change
}

function exportCurrentView() {
  if (!api) return
  const rows = api.getDisplayedRows()
  // rows reflects current sort + filter + pagination
  downloadCsv(rows)
}

The `llms.txt` feed

Not every assistant speaks MCP. Retrieval-augmented tools, web-enabled models, and AI search engines all have their own mechanisms for indexing documentation. For those we published an llms.txt feed at the site root.

llms.txt is a simple convention, roughly the robots.txt equivalent for AI crawlers. It points to a structured, machine-readable summary of the site that a retrieval system can index cleanly rather than parsing HTML. Assistants that find SvGrid through search get documentation-grounded answers instead of best guesses.

The combination covers the two main paths: interactive coding assistants via MCP, and retrieval-based tools via the text feed.

The principle behind the decision

We did not build this as a marketing exercise. AI assistants change the actual experience of adopting a library. When generated code works on the first try, you spend your time on the actual problem. When it invents an API, you spend it debugging fiction.

The team has shipped tools that meet developers where they are since 2011 - jQuery, then Angular and React bindings, then web components, then native Svelte 5. AI-assisted development is where a large share of grid code is being written right now. Showing up there was not a stretch, it was the same move, one more time.

The technical how-to for connecting the MCP server to your editor is in Build Svelte Grids Faster with AI and the SvGrid MCP Server. That post covers editor-specific config, the tool set the server exposes, and what to do when an assistant still goes off-script.

First Light - Pointing SvGrid at 100,000 Rows

Kamelia M — Thu, 30 Jul 2026 07:12:00 GMT

The first version of SvGrid that could render data at all was pointing at an array of three rows. That proves the component tree compiles. It proves nothing about your architecture.

So we did what you have to do eventually: we generated a hundred thousand rows, dropped them in, and watched the browser profile.

SvGrid rendering with real data volumes.

The question we were actually asking

Performance at scale is a proxy question. What we were really asking was: did we make the right foundational bets? Specifically two of them.

The first bet was virtualization from day one. Not as an optimization we would add later, but as a constraint the engine was built around from the beginning. No part of the rendering path should ever assume a full-data pass.

The second bet was Svelte 5 runes as the reactivity layer, before runes were even stable. The idea was that fine-grained reactivity at the cell level would mean updates stay surgical regardless of dataset size. One cell changes, one cell repaints - not a grid-wide reconciliation triggered by a single field mutation.

Both bets were theoretical until we had a hundred thousand rows to test them on.

Setting up the test

The setup was deliberately plain. A flat array of 100,000 generated objects, realistic field types, no server side data source, no pagination. Just the component in a bounded container with a large dataset.

The height: 600px on the wrapper is not incidental. It is load-bearing. Without a bounded height, the grid cannot calculate the viewport, and without a viewport, virtualization has nothing to work with. That single omission is the most common reason someone reports that a large dataset is slow - the grid is rendering all hundred thousand rows because nothing told it what "visible" means.

What we saw

Scrolling was smooth. Frame time stayed low. The DOM node count in the Elements panel sat at roughly the same number whether we were at row 0 or row 99,999 - a few hundred nodes for the visible window plus overscan, not a hundred thousand.

That is the whole point of row virtualization: DOM size tracks viewport size, not dataset size. The engine renders what is visible, discards what leaves the window, and reuses the nodes for incoming rows rather than creating new ones. Ten rows or a hundred thousand rows, the same handful of elements do the work.

Sorting the full hundred thousand rows by value took a moment on the first trigger - you are sorting 100k objects in JavaScript, that is not free. But the sorted render came back fast, because displaying the sorted result is still just showing the viewport window.

Where runes changed the story

The virtualization result was expected. The runes result was the one that mattered more for how we would build everything else.

We triggered a mutation: a single value field on one row, deep in the dataset.



 { api = a }}
/>

On an older reactivity model - one that tracks arrays as a whole - mutating data[49999].value would signal that the entire array changed. The framework would reconcile from scratch. With a hundred thousand rows, that is expensive even with virtualization, because the derived state (sort order, filter matches, display values) all has to be recomputed.

With runes, the mutation is tracked at the property level. Only the derived state that reads data[49999].value becomes stale. The rest of the hundred thousand rows, and all their derived values, are untouched. The repaint is one cell.

The practical consequence: you can drive a live-updating grid with frequent field mutations without batching tricks, debounce wrappers, or immutable update patterns. Mutate in place, let runes sort out the rest.

Stable references and the one mistake worth avoiding

There is one pattern that defeats both of these wins at once.

Replacing the whole data reference on a polling interval is the primary way to make a large grid feel sluggish even when everything else is right. The grid sees a new array, considers all row identity lost, and rebuilds. Mutating in place costs almost nothing because runes see exactly what changed.

What the test actually validated

Running a hundred thousand rows was not a milestone to mark on a roadmap. It was a diagnostic for whether the architecture was sound enough to build the rest of the product on.

Virtualization holding at scale meant features like grouping, master-detail rows, and tree data would not break the DOM budget when the data got large. Runes staying surgical meant inline editing, live server updates, and collaborative editing would be viable without heroic optimization work.

The features in the grid today - sorting, filtering, grouping, aggregation, server-side data, pivot, cell editing, undo/redo - all stand on that architecture. None of them required revisiting the foundation because the foundation held.

That is what first light means in practice: not that the thing looks good, but that you can trust what you built on.

A Fill Handle (Drag to Fill) in SvGrid

Boyko Markov — Wed, 29 Jul 2026 07:12:00 GMT

The fill handle is the first thing spreadsheet users notice when it is missing. That tiny square in the active cell's bottom-right corner - grab it, drag it down, and the value propagates. It feels like a minor convenience but for anyone doing repetitive data entry it is the difference between a grid and a toy.

SvGrid provides cell selection, editable columns, and a mutation API. The fill handle is not a built-in because it is genuinely presentation-layer work: a DOM element inside a cell snippet, a couple of pointer event listeners, and logic to decide what gets written to the filled range. This post walks through a complete implementation, including series detection and undo integration.

Drag the corner handle to propagate a value down a column.

The architecture in one sentence

Render a handle inside the active cell snippet, track pointermove to determine the fill range, and on pointerup apply the source value to every row in that range through the normal edit commit path.

That last part - through the normal commit path - is the part most quick implementations skip, and it is what causes bugs later.

Setting up the cell snippet

SvGrid accepts a Svelte 5 snippet for cell rendering. The fill handle is a child element rendered only when the cell is active. The handle itself is just a styled positioned at the bottom-right corner via CSS.



{#snippet fillCell(p: { row: Row; rowIndex: number; field: string; value: unknown })}
  {@const isActive = activeCell?.row === p.rowIndex && activeCell?.col === p.field}
  {@const isFillTarget =
    fillFrom && fillTo !== null &&
    fillFrom.col === p.field &&
    p.rowIndex > fillFrom.row &&
    p.rowIndex <= fillTo}
   { activeCell = { row: p.rowIndex, col: p.field } }}
  >
    {p.value}
    {#if isActive}
       startFill(e, p.rowIndex, p.field, p.value)}
      >
    {/if}
  
{/snippet}

 { api = a }}
/>

The fill-target class lets you highlight the fill range visually as the user drags - a blue overlay on each candidate cell. The active cell check ensures only the selected cell shows the handle, not every cell in the column.

Tracking the drag

Pointer capture keeps the drag smooth even if the cursor leaves the grid area. The key calculation is rowIndexAt(clientY): translate a Y coordinate into a row index by querying the grid's row elements or using the virtualizer's scroll offset.

let rowHeightPx = 36 // match your rowHeight prop

function rowIndexAt(clientY: number): number {
  const gridEl = document.querySelector('.sv-grid-body') as HTMLElement
  if (!gridEl) return 0
  const rect = gridEl.getBoundingClientRect()
  const scrollTop = gridEl.scrollTop
  const relY = clientY - rect.top + scrollTop
  return Math.max(0, Math.min(rows.length - 1, Math.floor(relY / rowHeightPx)))
}

function startFill(
  e: PointerEvent,
  fromRow: number,
  fromCol: string,
  value: unknown
) {
  e.preventDefault()
  e.stopPropagation()
  ;(e.target as Element).setPointerCapture(e.pointerId)

  fillFrom = { row: fromRow, col: fromCol, value }
  fillTo = fromRow

  function onMove(ev: PointerEvent) {
    const idx = rowIndexAt(ev.clientY)
    if (idx > fromRow) fillTo = idx
  }

  function onUp() {
    commitFill()
    fillFrom = null
    fillTo = null
    window.removeEventListener('pointermove', onMove)
    window.removeEventListener('pointerup', onUp)
  }

  window.addEventListener('pointermove', onMove)
  window.addEventListener('pointerup', onUp)
}

One detail: only allow downward fills (idx > fromRow). You can add upward fills, but they are rarely needed and complicate the range indicator. Ship the common case first.

Committing the fill

This is where most implementations cut corners. Directly mutating rows[i][field] works, but it bypasses any validation and leaves undo broken. Route the fill through api.applyTransaction instead, which integrates with SvGrid's edit history.

function commitFill() {
  if (!fillFrom || fillTo === null || fillTo <= fillFrom.row) return

  const { row: fromRow, col: field, value: sourceValue } = fillFrom

  // Optional: detect numeric series (1, 2 -> 3, 4, 5...)
  const step = detectStep(field, fromRow)

  const updates: Row[] = []

  for (let r = fromRow + 1; r <= fillTo; r++) {
    const current = rows[r]
    const filled = step !== null
      ? { ...current, [field]: Number(sourceValue) + step * (r - fromRow) }
      : { ...current, [field]: sourceValue }
    updates.push(filled)
  }

  // applyTransaction keeps undo/redo working
  api?.applyTransaction({ update: updates })
}

function detectStep(field: string, fromRow: number): number | null {
  // Require at least two rows above the drag start to detect a pattern
  if (fromRow < 1) return null
  const prev = rows[fromRow - 1][field as keyof Row]
  const curr = rows[fromRow][field as keyof Row]
  if (typeof prev !== 'number' || typeof curr !== 'number') return null
  const step = curr - prev
  // Only treat as a series if the step is non-zero and reasonably small
  return step !== 0 && Math.abs(step) < 1e6 ? step : null
}

detectStep looks at the two rows immediately above the drag start. If they are both numbers with a consistent difference, the fill extrapolates rather than copying. Dates can be handled similarly by converting to timestamps, incrementing by step milliseconds, and converting back.

The CSS

Keep it minimal - a small square that appears on hover of the active cell and changes the cursor to a crosshair during drag:

.sg-cell-inner {
  position: relative;
  display: block;
  width: 100%;
  height: 100%;
  padding: 0 var(--sg-cell-px);
  line-height: var(--sg-cell-height, 36px);
}

.fill-handle {
  position: absolute;
  right: -3px;
  bottom: -3px;
  width: 7px;
  height: 7px;
  background: var(--sg-accent, #3b82f6);
  border: 1px solid #fff;
  border-radius: 1px;
  cursor: crosshair;
  z-index: 10;
}

.fill-target {
  background: color-mix(in srgb, var(--sg-accent, #3b82f6) 15%, transparent);
  outline: 1px solid var(--sg-accent, #3b82f6);
  outline-offset: -1px;
}

Using --sg-accent means the handle color will match any theme the user applies to the grid. If the user customises --sg-accent to their brand color, the fill handle follows automatically.

Column definition wiring

Attach the snippet to whichever columns should be fillable. Non-fillable columns - row numbers, action buttons - should not show the handle:

const columns: ColumnDef[] = [
  { id: 'id',       field: 'id',       header: '#',        width: 60,  editable: false },
  { id: 'qty',      field: 'qty',      header: 'Qty',      width: 100, editable: true, type: 'number', cell: fillCell },
  { id: 'price',    field: 'price',    header: 'Price',    width: 120, editable: true, type: 'number', cell: fillCell },
  { id: 'category', field: 'category', header: 'Category', width: 160, editable: true, cell: fillCell },
]

The fillCell snippet is the same one for all fillable columns - the field parameter inside it carries the column identity, so one snippet serves all columns.

Where this breaks and what to do about it

Virtualization and row height. The rowIndexAt function above uses a fixed rowHeightPx. If your grid uses variable row heights or the autoRowHeight option, you need a different approach: iterate the rendered row elements and find the one whose bounding rect contains clientY. Slower, but accurate.

Pinned columns. Pinned columns render in a separate DOM container. The fill handle's rowIndexAt call needs to account for which pane the pointer is in. If your fillable columns are all in the scrollable body, this is not an issue.

Read-only rows. If some rows are conditionally read-only, add a guard in commitFill that skips those rows rather than overwriting them.

Touch devices. PointerEvent covers both mouse and touch, but setPointerCapture behaves differently on touch. Test on mobile if your users care about it; the fill handle is fundamentally a mouse interaction and often it is acceptable to leave it mouse-only.

The fill handle is about 80 lines of logic. Most of that complexity lives in commitFill and detectStep - the actual drag tracking is straightforward. Keeping it attached to applyTransaction rather than direct mutation means undo, redo, and any server-sync logic your app has will treat fills the same as any other edit.

What Makes a Svelte Data Grid Fast (and How to Measure It)

Kamelia M — Tue, 28 Jul 2026 07:12:00 GMT

Most "fastest grid" posts are marketing. This one is not. If you need to pick a Svelte data grid and performance is on your list of requirements, here is what to measure, why naive benchmarks mislead you, and what actually separates a fast grid from a slow one.

A million-row dataset in SvGrid, kept smooth by virtualization.

The three things that actually determine speed

Grid performance comes down to three independent problems, and a grid can be good at one while being terrible at the others.

Virtualization. This is the most important one. A grid that renders 100,000 rows to the DOM is not a data grid - it is a crash waiting to happen. Real virtualization keeps the number of rendered rows constant regardless of dataset size, typically in the range of visible rows plus a small overscan buffer. Row virtualization is table stakes; column virtualization matters once you have more than ~30 columns.

Update cost. How expensive is it to change a cell value or apply a batch of updates? Virtual-DOM grids have to diff the entire rendered tree on each update. Svelte 5's fine-grained reactivity eliminates that: each cell tracks its own dependencies and only the affected cells repaint. The difference is invisible at 100 rows and dramatic at 10,000.

Pipeline overhead. Sort, filter, group - these transformations run on every state change. A well-designed grid sorts once per change and reuses the result; a poorly designed one sorts inside the render function and throws it away. With large datasets this is the thing that makes UI interactions feel laggy even when the DOM work is fast.

Setting up a meaningful benchmark

If you want to compare grids seriously, here is the minimal setup that gives you honest results.

Same data, same columns, production builds, same browser, same machine. Run on a mid-range laptop with CPU throttled to 4x in DevTools - that is where differences are visible. Average at least five runs per scenario.

The scenarios worth measuring:

Initial render: time from data load to interactive. Use the browser's Performance panel, not Date.now().
Scroll frame budget: scroll from top to bottom, check the main thread for frames over 16ms.
Live update throughput: apply 1,000 cell updates per second and measure jank.
Sort/filter latency: time from user click to repaint on a 50,000-row dataset.

Here is a minimal SvGrid setup you can use as a baseline for your own benchmark:



 { api = a }}
/>

Run that, open the Performance panel, record a sort click on a column, and look at the resulting flame chart. That tells you far more than any published benchmark.

The update scenario most benchmarks skip

Scroll and initial render get all the attention. Live updates are where production apps actually hurt.

Consider a trading dashboard or a monitoring view where hundreds of cells change per second. The naive approach - mutate the data array and let the grid re-render - forces the grid to re-evaluate every visible cell on every tick.

SvGrid handles this through applyTransaction, which accepts explicit add/update/remove lists and only repaints affected cells:

import type { SvGridApi } from '@svgrid/grid'

// Simulate a live feed applying 200 changes every 100ms
function startFeed(api: SvGridApi) {
  setInterval(() => {
    const updates = Array.from({ length: 200 }, () => ({
      id: Math.floor(Math.random() * 50_000),
      value: Math.random() * 1000,
      score: Math.round(Math.random() * 100),
    }))

    api.applyTransaction({ update: updates })
  }, 100)
}

At 200 updates per 100ms (2,000/sec), a grid without surgical update support will visibly stutter on mid-range hardware. The right thing to measure here is not "does it work" but "what is the 99th-percentile frame time under sustained load."

What conditional formatting costs you

One performance foot-gun that rarely gets benchmarked: conditional formatting functions run on every cell during render. If they are expensive, they show up everywhere.

import { type ColumnDef } from '@svgrid/grid'

// Cheap: pure value comparison
const scoreColumn: ColumnDef = {
  id: 'score',
  field: 'score',
  header: 'Score',
  width: 100,
  type: 'number',
  conditionalFormat: [
    { condition: ({ value }) => value < 40,  style: { color: 'var(--red)',   fontWeight: 'bold' } },
    { condition: ({ value }) => value >= 80, style: { color: 'var(--green)', fontWeight: 'bold' } },
  ],
}

// Expensive: avoid anything that allocates or accesses external state per cell
// Bad:
// conditionalFormat: [{ condition: ({ value, row }) => expensiveRankLookup(row), style: {...} }]

The condition function gets called for every visible cell on every render cycle. Keep it a pure value comparison. If you need something more complex, precompute a lookup when the data changes and close over it.

Server-side data and where virtualization changes

The setup above assumes client-side data. If you are loading from a server, the performance model is different: you are not virtualizing 50,000 local rows, you are paging through a server-side cursor. SvGrid's createServerDataSource handles the wiring:

import { createServerDataSource } from '@svgrid/grid'

const ds = createServerDataSource({
  fetch: async ({ page, pageSize, sort, filters }) => {
    const params = new URLSearchParams({
      page: String(page),
      size: String(pageSize),
    })

    if (sort.length > 0) {
      params.set('sortField', sort[0].id)
      params.set('sortDir', sort[0].desc ? 'desc' : 'asc')
    }

    for (const f of filters) {
      params.set(`filter_${f.id}`, JSON.stringify(f.value))
    }

    const res = await fetch(`/api/rows?${params}`)
    const json = await res.json()
    return { rows: json.data, total: json.total }
  },
})

In this mode, render performance is almost irrelevant - you are rarely showing more than a few hundred rows at once. What matters is request latency, debounce on filter input, and avoiding redundant fetches. Profile the network tab, not the flame chart.

Reading the flame chart

When you do record a Performance trace, look for these patterns:

Long tasks on sort/filter: the pipeline is not caching the sorted result.
Many small Svelte update tasks on scroll: virtualization is working but row recycling is expensive - check if custom cell snippets are doing unnecessary work.
Flat main thread during bulk updates: good sign that surgical updates are working correctly.
Paint calls on every keypress in a filter input: the grid is re-rendering on every keystroke rather than debouncing.

No grid, including SvGrid, will have a perfect flame chart on every workload. The goal is understanding where the time goes so you can decide whether it matters for your specific case.

An honest take on published benchmarks

Published "fastest grid" benchmarks are almost always produced by the grid vendor. That is not necessarily dishonest - vendors know their product and can set it up optimally - but it does mean the comparison grids are often configured suboptimally or measured in scenarios where the vendor's approach happens to shine.

The only benchmark that matters for your project is the one you run on your actual data, your actual columns, your actual update patterns, on the hardware your users have. Set that up, measure the candidates, and pick the one that wins on the metrics your app cares about.

SvGrid's approach - Svelte 5 runes for surgical cell updates, row and column virtualization on by default, and a headless pipeline that separates data transformation from rendering - is designed to be fast across all three dimensions, not just one. Test it against your workload and see where it lands.

Empty, Loading, and Error States for a Svelte Data Grid

Kamelia M — Mon, 27 Jul 2026 07:12:00 GMT

Every grid demo ships with data already loaded. Every grid in production starts empty, stalls while fetching, and occasionally breaks. Those three states are where the real UX work happens, and they are almost always the last things teams implement - if at all.

The fix is not complicated. It is mostly a matter of thinking through each state before you write the happy path instead of after.

Two empties, two messages

The single most common mistake I see in grids is conflating two distinct empty states into one. "No data" and "no matches" are different problems, and treating them the same sends the user down the wrong path.

If a user clears the search box and gets "No records found," they might think the table is broken or that no data was ever loaded. If they applied three filters and your grid says "Add your first record," that is equally confusing. You need to know which empty you are in.



{#if !loading && !error && rows.length === 0}
  
    {#if hasActiveFilters}
      No rows match the active filters.
      
    {:else}
      No records yet.
    {/if}
  
{:else if !error}
   { api = a }}
  />
{/if}

The hasActiveFilters check reads from the grid's own state rather than a manually-tracked boolean - that way it stays accurate when filters are applied programmatically, not just through the filter row.

Skeleton on first load, overlay on refetch

Spinners have two problems: they give no sense of layout, and they cause a jarring layout shift when they disappear. A skeleton that mimics the grid's row structure avoids both. Users see where the columns will land before data arrives.

The subtler problem is what to show on a refetch - when the user pages, sorts, or refreshes and the grid already has rows. Blanking the grid on every page flip feels like a bug. The better pattern is to keep the current rows visible and apply a low-opacity overlay to signal "fetching without replacing."



{#if loading}
  
  
    {#each { length: 8 } as _, i}
      
    {/each}
  
{:else}
  
    
  
{/if}

.sg-skeleton-row {
  height: 32px;
  margin-bottom: 1px;
  background: linear-gradient(
    90deg,
    var(--sg-border) 25%,
    var(--sg-bg) 50%,
    var(--sg-border) 75%
  );
  background-size: 200% 100%;
  animation: shimmer 1.4s ease-in-out var(--delay, 0ms) infinite;
  border-radius: var(--sg-radius);
}

@keyframes shimmer {
  0% { background-position: 200% 0; }
  100% { background-position: -200% 0; }
}

.sg-fetching {
  opacity: 0.6;
  pointer-events: none;
  transition: opacity 150ms ease;
}

The --delay custom property staggers the shimmer animation across rows so they do not all pulse in unison, which looks mechanical.

Error handling that does not lose the user's work

The instinct is to replace the grid with an error panel. That instinct is wrong when the grid already has data. A failed page change or refresh should not wipe the screen - the user is still looking at valid (if stale) rows.

The two cases to handle separately:

Initial load fails - nothing to show, so display the error with a retry button.
Refetch fails - keep the current rows visible and show a non-blocking error notice, probably a toast or a small banner above the grid.



{#if error}
  
    Could not load data: {error}
    
  
{:else}
  {#if fetchError}
    {fetchError}
  {/if}
  
{/if}

One detail worth getting right: role="alert" on the full-screen error triggers screen reader announcement immediately. role="status" on the non-destructive banner announces it politely without interrupting.

Putting it together in a shared component

These three states belong in a single wrapper component you drop in once and reuse across every grid in the app. The wrapper handles state logic; the grid handles data display.




{#if loading}
  
    {#each { length: 8 } as _, i}
      
    {/each}
  
{:else if error}
  
    {error}
    {#if onRetry}{/if}
  
{:else if data.length === 0}
  
    {#if hasActiveFilters}
      No rows match the active filters.
      {#if onClearFilters}{/if}
    {:else}
      {emptyMessage}
    {/if}
  
{:else}
  {#if refetchError}
    {refetchError}
  {/if}
  
    
  
{/if}

The generics annotation on the script tag keeps column type inference intact through the wrapper, so you do not lose the TypeScript benefit of typed row data.

The states worth testing explicitly

Happy-path tests are not enough here. Each state needs at least one test case where you can verify the right message appears and the right action is available. In practice that means Playwright tests or Storybook stories - one story per state, with static data stubbed for each scenario.

Three states, three stories: empty with no filters, empty with filters active, loading skeleton, initial error with retry, refetch error with stale data visible. That is the minimum bar for a grid you would call production-ready.

SvGrid Blog

Building a Real-Time Trading Grid in Svelte

Why plain mutation is not enough

The tick batcher

Wiring to SvGrid

Stable row identity and why it matters

The flash cycle

Keeping format separate from value

Scaling past 12 rows

Related reading

Reactivity with Large Arrays and Objects in Svelte 5

Why deep proxying hurts at scale

When to reach for $state.raw

Editing rows without rebuilding the world

Live updates from a WebSocket feed

Mixing $state.raw and $state in the same component

The threshold question

Related reading

Building a Project / Task Board with a Svelte Data Grid

The data model that makes everything else easier

Column definitions: what to show and how to edit it

Grouping by status gives you a lightweight board view

Subtasks as tree rows

Saving views so engineers can get back to their context

Bulk operations for fast triage

When a dedicated tool makes more sense

Related reading

Progress and Percentage Bar Cells in SvGrid

The bar lives in the snippet, the value lives in the field

Styling the track and fill

Color thresholds

When you want SvGrid's conditional formatting instead

Stacked and segmented variants

One thing to watch with virtualization

Related reading

svelte-headless-table and the Svelte 5 upgrade: your three options

What actually broke

Option 1: the maintained fork

Option 2: TanStack Table v9

Option 3: a grid that ships the renderer

Choosing

The one thing not to do

Related reading

Porting a React MUI X DataGrid Screen to Svelte

The column model, renamed

Cell renderers: JSX to snippets

Server-side data and the hooks that disappear

Editable cells

What transfers and what does not

Related reading

Paste from Excel into a Svelte Data Grid

What the clipboard actually contains

Wiring the paste handler into SvGrid

Growing the grid when the paste block overflows

Validation that surfaces errors without blocking work

A note on column ordering

Related reading

Building an Order Management Dashboard in Svelte

Columns that communicate order state

Server-side data with filters operators actually use

Line items as expandable detail

Bulk fulfillment via row selection

Status advancement and edge cases

What this approach handles well

Related reading

Optimistic UI Explained

The pessimistic default and why it costs you

Three steps, one try/catch

Making failure visible without alarming users

The reconciliation problem

When optimism is the wrong call

The performance argument is secondary

Related reading

Open-Source vs Commercial Svelte Data Grids

What "free" actually costs in practice

What you're actually buying with commercial licensing

The feature gap in Svelte specifically

Where the paid tier changes the picture

The open-core middle ground

How to make the call

When to reach for `$state.raw`

Mixing `$state.raw` and `$state` in the same component