ENGINEERING GUIDE · JAVASCRIPT + REACT

Build a seating chart in JavaScript—then make it safe for live sales.

Rendering selectable seats is a frontend task. Selling them is a distributed state problem: authoritative inventory, atomic holds, expiry, real-time updates, trusted pricing, idempotent booking, and recovery.

Build the browser prototype See the production gap

Scope: the working example below is intentionally browser-local. It teaches interaction—not double-booking prevention.

THE SEATING STACKOne visual layer. Six production responsibilities.

01
Render + navigateDOM · SVG · Canvas · WebGL
02
Express buyer intentselected seat IDs
03
Acquire a server holdatomic conflict decision
04
Keep every buyer currentsnapshot + inventory deltas
05
Book idempotentlystable commerce reference
06
Reconcile operationswebhooks · reports · staff tools

STEP 1 · A USEFUL BROWSER PROTOTYPE

Start with semantic seats and explicit local state.

Each available seat is a button with a stable ID and an aria-pressed state. A JavaScript Set tracks the current browser selection. Sold seats are disabled.

LOCAL DEMOStudio Theatre · Row A–D

BROWSER ONLY

JavaScript has not started. The guide remains readable.

STEP 2 · THE MINIMUM JAVASCRIPT

The selected set is buyer intent—not inventory.

This pattern is appropriate for learning, a static plan, or a narrow internal tool. It deliberately never labels local selection as a reservation.

// HTML: <button data-seat="A-1" aria-pressed="false">A1</button>
const selected = new Set();

document.querySelectorAll('[data-seat]').forEach((seat) => {
  seat.addEventListener('click', () => {
    const id = seat.dataset.seat;
    const active = !selected.has(id);

    active ? selected.add(id) : selected.delete(id);
    seat.setAttribute('aria-pressed', String(active));
    renderSummary([...selected]);
  });
});

function renderSummary(ids) {
  summary.textContent = ids.length
    ? `Selected locally: ${ids.join(', ')}`
    : 'No seats selected.';
}

STEP 3 · CHOOSE A RENDERER

Choose the render layer by interaction cost—not fashion.

A renderer solves pixels, hit testing, and navigation. It does not decide who owns a seat when buyers compete.

Layer	Useful when	Work you still own
DOM buttons	Small maps, direct semantics, simple layouts	Spatial navigation, dense-scene performance, venue geometry
SVG	Vector geometry, labels, inspectable seat nodes	Pan/zoom, large node counts, semantic focus model
Canvas	Dense 2D scenes and custom hit testing	Accessible equivalent, focus, text, selection semantics
WebGL	Very dense or spatially rich scenes	Rendering pipeline, picking, fallbacks, accessibility, device variance

Primary implementation references reviewed 10 Aug 2026: Konva's React canvas reservation example, an open React/Konva seating editor, and the package documentation surfaced for react-seat-charts, seat-picker, and @seatsio/seatsio-react. Package status and APIs can change; confirm them at evaluation time.

STEP 4 · THE PRODUCTION GAP

A sellable seat map is nine systems around the renderer.

The browser can request a change. Only the authoritative backend can decide whether that transition succeeds.

Venue document

Stable seat, row, section, floor, category, label, accessibility, and geometry identifiers.

Authoritative inventory

Free, held, booked, blocked, and released state owned outside the browser.

Atomic holds

One decision point for competing requests; failure returns a conflict, not a second success.

Expiry

Temporary ownership ends predictably and returns inventory without relying on an open tab.

Real-time updates

Each buyer begins with a snapshot and applies later inventory deltas.

Trusted commerce

Your server reads fresh held items and applies pricing, payment, customer, and order rules.

Idempotent booking

A stable booking reference makes retry safe when a response is lost or delayed.

Reconciliation

Signed webhooks, history, and reports recover outcomes beyond the request lifecycle.

Operations + access

Staff controls, blocked seats, accessibility filters, responsive behavior, and scoped authorization.

STEP 5 · STATE OWNERSHIP

Selection becomes trustworthy only after the server agrees.

A client may optimistically highlight a seat, but the durable transition belongs to one event state owner.

BROWSERSelected locallyintent only

→

SERVERHold requestedatomic decision

→

EVENT STATEHeld or conflictone authoritative result

→

TRUSTED SERVERBooked or releasedidempotent finalization

BUYER AHold C-14SUCCESS

C-14one state owner

BUYER BHold C-14CONFLICT

The diagram explains the contract, not a universal throughput claim. SeatLayer's released evidence includes one scoped 30-way race for one contested seat: one hold succeeded and the other requests received conflicts.

STEP 6 · BUILD OR INTEGRATE

Build the parts that differentiate your product.

DIY is a valid choice when the scope is deliberately narrow. An SDK is useful when the seating layer itself is becoming a product programme.

KEEP BUILDING

A focused local component may be enough.

Static or rarely changing map
One user or internal workflow
No concurrent sale or temporary hold
Your team wants to own rendering and venue authoring
Custom interaction is the differentiator

EVALUATE AN SDK

The seating layer needs its own maintained platform.

Reusable venue charts across events
Multiple buyers and real-time inventory
Atomic holds, expiry, booking, and webhooks
Buyer, organizer, and staff surfaces
Framework, server, mobile, and operational support

THE SEATLAYER PATH

Install the picker. Keep your commerce boundary.

SeatPicker renders the complete buyer surface and hands your server an opaque holdId. Your server inspects fresh held items, applies pricing and payment, and confirms inventory with a stable booking reference.

npm install @seatlayer/js

import { SeatPicker } from '@seatlayer/js';

const picker = new SeatPicker({
  container: '#seat-picker',
  event: 'ev_9f3a',
  onCheckout: async (_, __, handoff) => {
    await fetch('/api/checkout', {
      method: 'POST',
      body: JSON.stringify({ holdId: handoff.holdId }),
    });
  },
});

picker.render();

RELEASED WEB PATH

JavaScript, TypeScript, React, Vue 3, and Angular 17+.

Use the complete picker or the headless chart. Server SDKs and REST/OpenAPI cover the trusted side.

Review the complete developer platform →Open the quickstart docs ↗Inspect the web SDK on GitHub ↗View @seatlayer/js on npm ↗

JAVASCRIPT SEATING CHART QUESTIONS

Separate the visual choice from the inventory promise.

Can I build a seating chart with plain JavaScript?

Yes. Plain JavaScript can render semantic seat buttons, track a local selected set, and update a summary. That is enough for a prototype or static internal tool. Selling seats also requires authoritative server inventory, atomic holds, expiry, booking, synchronization, and recovery.

Should a seating chart use DOM, SVG, Canvas, or WebGL?

There is no universal winner. DOM and SVG expose useful semantics and are straightforward for smaller maps. Canvas and WebGL can reduce DOM pressure for denser scenes but require more work for hit testing, focus, labels, and accessible equivalents. Test with your real venue and interaction requirements.

How do I prevent two buyers from selecting the same seat?

A frontend selected flag cannot prevent a double sale. The server must own seat state and serialize competing transitions. Selection should request an atomic hold; only one competing request can succeed, and every client must receive the resulting state change.

Does a React seating chart still need a backend?

Yes, when seats are being sold or reserved by multiple buyers. React can render the interface and manage local intent, but trusted inventory, hold expiry, pricing, booking, idempotency, and reconciliation belong on the server.

What makes a JavaScript seating chart accessible?

Seat controls need keyboard operation, visible focus, meaningful names, programmatic selected and unavailable states, a readable selection summary, and a non-canvas path to the same decision. Zoom, pan, color, and pointer gestures cannot be the only way to understand or choose a seat.

When should I use a seating chart SDK instead of building?

Build when the job is a small static map, an internal tool, or a deliberately narrow custom interaction and your team wants to own every layer. Evaluate an SDK when you need reusable venue authoring, multi-buyer live inventory, holds, expiry, booking, webhooks, operational tools, and framework support as one maintained seating layer.

MOVE FROM LOCAL SELECTION TO TEST MODE

Prove the hold and booking boundary before you build more UI.

Create test credentials and run one event through render, hold, trusted inspection, booking, and signed webhook verification. Prefer to inspect first? Open the released buyer demo.

Create test credentials Try the released buyer demo