A good toast system in the Next.js App Router comes down to four pieces: a small client-side store, a viewport that animates entries and exits, a swipe gesture that decides when a toast is gone, and a clean way to turn Server Action results into toasts. You can build all of it with 

 (currently 14.6.0) in about 200 lines, and your layout and pages stay Server Components.

This guide builds it step by step. Each step runs on its own, and I'll point out the spots where people usually get stuck.

Step 1: Install Motion and put the provider in your root layout

Motion's React API is imported from motion/react (

). Every file that renders motion.* components or calls Motion hooks needs "use client".

The store is a React context holding an array of toasts. Two choices matter here. First, toast() takes an optional id, and if a toast with that id already exists it gets replaced instead of added again. That is how we stop duplicate toasts later. Second, the stack is capped at three. When a fourth toast arrives, the oldest one leaves with its exit animation instead of piling up off-screen.

Where people get stuck: a lot of developers assume that wrapping children in a client provider turns the whole tree into client code. It doesn't. children is rendered on the server and passed through as a prop. The mistake that actually costs you is importing a client component into a Server Component and then also importing server-only modules into that client file. Keep the provider, the viewport and anything that calls useToast in client files. Everything else can stay on the server.

Step 2: Build the viewport with AnimatePresence and layout animations

Exit animations are the whole reason to use AnimatePresence. It keeps removed children mounted until their exit animation finishes. The stacking behaviour comes from mode="popLayout". In that mode, exiting elements are taken out of the page layout so the toasts around them can reflow right away, and the docs say it 

pairs especially well with the layout prop

 so the remaining toasts animate to their new positions. See the 

Here's a first version of the viewport with no drag yet. It's fully working: toasts animate in, auto-dismiss, and the stack reflows smoothly.

The flex-col-reverse on the list puts the newest toast (index 0) at the bottom, nearest the corner, and pushes older ones up.

There are three traps here, and all three come straight from Motion's troubleshooting docs:

Keys must be stable and unique. The docs specifically warn that using index as a key 

AnimatePresence must stay mounted. If you write toasts.length > 0 && <AnimatePresence>…, the last toast vanishes with no animation, because the component that runs exits has already unmounted. Put the condition inside it, not around it.

The parent needs position: relative. popLayout pulls exiting elements out using absolute positioning. The docs say the animating parent should have a 

 or exiting toasts will jump. That's why the ol has the relative class.

There's also a fourth trap. With popLayout, any direct child of AnimatePresence that is a custom component has to 

 to the DOM node. Next.js 16 runs on React 19, where ref is an ordinary prop on function components, so you don't need forwardRef. You do still need to accept ref and pass it to the motion.li. If you forget, exiting toasts won't pop out of the layout.

Step 3: Add swipe-to-dismiss with drag gestures

 gives you drag="x" and an onDragEnd(event, info) callback, where info carries offset and velocity. Count it as a swipe if the toast has moved far enough or was flicked fast enough. Testing only distance feels sluggish on phones, and testing only velocity misses slow, deliberate drags.

The part most implementations get wrong is the exit direction. A swiped toast should keep going the way it was thrown. But once a component is removed, AnimatePresence only has its last-rendered exit props, so trying to compute a direction-aware exit at dismissal time doesn't work reliably. The simpler approach: animate the toast off-screen yourself with animate() on a 

, and only call onDismiss once that's finished. After that, the exit animation just has to fade out something that's already off-screen.

Some details in that code exist for a reason:

dragMomentum={false} and the manual snap-back. With momentum switched on, Motion starts its own inertia animation on x when you release. That races with your animate() call. Turning it off means you decide what happens after release every time, which makes the behaviour predictable.

The fade is on the inner div. animate already drives opacity on the li. If you also bind style={{ opacity }} to a motion value on the same element, the two fight. Fading the content with 

The close button is required. WCAG 2.2's 

 asks for a single-pointer alternative to any drag action. Swipe is a nice extra, and the button is what actually makes dismissing accessible. Escape covers keyboard users who tab into the toast.

The timer pauses on hover and focus. If a toast disappears while someone is reading it or reaching for its button, they lose the message. This version restarts the full duration when the pointer leaves. Tracking the remaining time is possible, but in practice you won't notice the difference.

Step 4: Turn Server Action results into toasts

A Server Action runs on the server, so it can't call toast(). What it can do is return a result that a client component reacts to. React 19's 

 is the right tool for this. It gives you the action's latest return value plus a pending flag. Next.js documents the pattern in its 

app/settings/page.tsx can stay a Server Component that fetches data and renders <ProfileForm />.

The nonce solves two problems. In development, Strict Mode runs effects twice, and the fixed id means the second toast() call replaces the first instead of stacking a copy. It also handles the case where a user submits the same invalid value twice in a row. Each submission returns a new object with a new nonce, so the effect runs again and a fresh toast appears.

Don't fire the toast during render, for example by calling toast() in the component body when state changes. That updates the provider's state while React is rendering the form, and React will warn about it. Keep it in an effect.

Look at the inline role="alert" error, too. I'd keep validation errors next to the field even when you also show a toast. A toast is temporary and sits in a corner away from the form, and the live region on the viewport is polite, so screen readers may announce it late. The toast confirms what happened, and the inline message is the one users can rely on.

Where people get stuck: if your action calls redirect(), nothing gets returned, so there's no result for the client to read. For "saved, now go to the list" flows, set a short-lived cookie in the action, read it in the destination page (a Server Component), and pass it to a small client component that calls toast() once on mount.

Step 5: Respect prefers-reduced-motion everywhere, including the imperative bits

<MotionConfig reducedMotion="user"> in the viewport makes Motion follow the operating system setting. When reduced motion is on, the 

 say transform and layout animations are disabled, while opacity and other non-transform values still animate. Your toasts still fade in and out, but they no longer slide, scale or reflow with motion. The 

MotionConfig covers declarative props like animate, exit and layout. Imperative animate() calls are a different code path, so for those the component reads 

The swipe-out uses duration: 0 when reduced motion is on, so a swiped toast disappears immediately instead of flying across the screen.

The scale-down on older toasts is turned off, so the stack is a plain list.

Swiping still works with reduced motion. The toast follows your finger, since that movement comes directly from the user and isn't animation playing by itself. Only the motion added after you let go is removed.

To test it, turn on "Reduce motion" in macOS Accessibility settings, or open the Rendering panel in Chrome DevTools and emulate prefers-reduced-motion: reduce. Then submit the form a few times and swipe a toast.

You now have a stack that animates in, reflows when toasts leave, can be swiped in either direction, pauses while being read, works with keyboard and screen readers, and gets its data from Server Actions without moving any page into client code. If you also need promise-based toasts that show loading and then success, add an update(id, patch) method to the provider. Since each toast is matched by key, updating its content in place won't trigger an exit and re-entry.

Next.js Toast Notifications with Motion: Swipe, Stack, A11y

To build a customizable dashboard in the Next.js 16 App Router, load the user's saved layout in a Server Component and pass it to a client component. That component renders react-grid-layout 2.3, and only after it has measured its container. That one decision avoids most hydration errors. The other decisions in this tutorial (saving through a Server Action, putting Motion on an inner element, deferring removal until the exit animation finishes) handle the rest of the usual problems.

We'll build it in five steps, and each step leaves you with something that runs. The versions are 

Install the packages and know what changed in v2

If you've used react-grid-layout before, v2 is a TypeScript rewrite with a different API. The WidthProvider HOC is gone from the main entry point. The 

 now requires a width prop and recommends getting it from the useContainerWidth hook. That hook returns width, containerRef and a mounted flag. Old v1 code still works if you import from react-grid-layout/legacy. Most blog posts and Stack Overflow answers about Next.js still show the v1 WidthProvider(Responsive) pattern, so check which API a snippet uses before you copy it.

Step 1: Define the dashboard shape and a per-user store

Keep the widget list and the layouts as separate pieces of state. Widgets describe what to render. Layouts describe where each widget sits at each breakpoint, and the two are linked by the layout item's i key.

Next, the persistence layer. To keep this runnable without a database, it writes one JSON file per user. Swap the two fs calls for your ORM when you move it into a real app.

 in current Next.js, so you have to await it. Second, a page that uses no request-time API can be prerendered at build time. Then every visitor gets the same frozen layout, and you'll waste an hour trying to work out why saves don't seem to stick. Reading a cookie or session prevents that. Also keep in mind that 

 are public POST endpoints, so validate the payload and never accept a user ID from the client.

The page is a plain async Server Component:

This is why the layout lives on the server and not in localStorage. If the client component read localStorage during its first render, the server HTML (default layout) and the client's first render (saved layout) would differ, and React would report a hydration mismatch. When the server passes in the saved layout, both renders start from the same data. If you really need localStorage, for example for anonymous users, read it in a useEffect and accept a brief flash of the default layout.

Step 3: Render the responsive grid only after measuring

Here's the client component with drag, resize and breakpoints, but without saving or animations yet:

"use client" doesn't mean "client only." Client components still render on the server. Without a measured width, the grid would compute pixel positions for some guessed width, and the layout would jump once it hydrated. Gating on mounted means the server and the client's first render both output the same placeholder. The grid renders only after useContainerWidth has measured the real container. Give the placeholder roughly the height of the dashboard so the page doesn't shift.

Import both stylesheets. If items stack on top of each other or the resize handles don't appear, a missing CSS import is usually the cause. In the App Router you can import global CSS from a client component.

Use a drag handle. Without handle, the whole card is draggable, which makes text selection, inputs and charts inside widgets frustrating to use. The cancel selector covers the remove button we add in Step 5. Without it, pressing a button inside the handle starts a drag and the click never fires. v2 groups these options into gridConfig, dragConfig and resizeConfig objects. If you're coming from v1's flat rowHeight and draggableHandle props, the README's Hooks and config sections list every field.

Keep breakpoint names consistent. The keys in breakpoints, cols and layouts have to match. Only define lg at first and let the grid derive md through xxs. onLayoutChange reports every layout it knows about, so derived breakpoints get added to your state as the user visits them. Once a user adjusts the sm layout on their phone, that layout is saved separately from lg.

Step 4: Persist layout changes without hammering the server

onLayoutChange fires a lot. It runs once when the grid mounts, again on breakpoint changes, and after every drag and resize. Debounce the save and skip the first effect run, so loading the page doesn't immediately write the same data back.

Add this inside the component and change const [widgets] = useState(...) to const [widgets, setWidgets] = useState(...):

If you'd rather save only on deliberate user actions, use onDragStop and onResizeStop. That avoids saves caused by window resizes, but you'll also need to save on add and remove. For most dashboards, the debounced effect is simpler and good enough.

Step 5: Add and remove widgets with Motion animations

Trap one: don't make the grid item a motion.div. react-grid-layout positions each direct child by writing a CSS transform to its style. Motion also animates transform when you use scale, x or y. If both write to the same element, one overwrites the other and items end up in the wrong place. Keep the grid item as a plain div and animate a motion.div inside it.

Trap two: AnimatePresence can't wrap grid children. The grid has to own its direct children, and a widget that's removed from state also disappears from the layout straight away. The reliable approach is to mark a widget as exiting, play the exit animation, and remove it from state in onAnimationComplete. The 

 cover the initial, animate and transition props used here.

initial={false} for widgets that were there on page load. Without it, every card would fade in each time the page loads, which gets annoying fast. Only widgets added in this session get the enter animation.

Add the new item to every existing breakpoint layout. If you only add it to the current breakpoint, the grid has to make up a position when the user resizes the window, and the result is usually a 1×1 box. The code maps over the breakpoints already in state. That's important: if you created an md entry that held only the new item, the grid would stop deriving md from lg, and every other widget would lose its position there.

y: Infinity is the standard way to say "put it at the bottom." The vertical compactor moves the item up to the first free row, and the next onLayoutChange replaces Infinity with a real number before the debounced save runs. JSON.stringify would turn Infinity into null, which is one more reason the debounce matters.

The gap closes after the animation, not during it. While a card fades out, its grid cell stays reserved. Once finishRemoval runs, the compactor moves the cards below it up. The grid's built-in CSS transitions animate that movement, so you don't need extra Motion code to make it look smooth.

If you want enter animations without the extra state, you could drop Motion and use a CSS @keyframes animation on .widget-shell > *. You'd lose the exit animation, though, and the exit is the part users notice most. Removing a widget with no transition and watching the cards below jump up is the main reason to add Motion here at all.

The structure handles a few extensions well. To give each widget type its own minimum size, add minW and minH to the layout items you create in addWidget. The grid enforces them during resize. To make a widget fixed, set static: true on its layout item. For a "reset layout" button, call setWidgets(DEFAULT_DASHBOARD.widgets) and setLayouts(DEFAULT_DASHBOARD.layouts), and the debounced effect saves the result. If you add a database, store widgets and layouts together in one JSON column. They're always read and written together, and normalizing grid coordinates into rows is extra work you won't get anything back for.

react-grid-layout in Next.js 16: Draggable, Resizable Dashboard

Real-time collaborative forms represent a significant UX challenge in modern web applications. Whether building survey tools, CRM systems, or administrative dashboards, developers need solutions that handle concurrent edits without data loss while maintaining acceptable performance. PartyKit provides a WebSocket infrastructure that integrates cleanly with Next.js 15's server components and streaming capabilities.

PartyKit operates as a hosted WebSocket server with built-in room management and connection handling. Unlike traditional WebSocket implementations that require custom infrastructure, PartyKit provides a serverless approach where each "party" (room) maintains its own isolated state and connection pool.

The key architectural benefit: PartyKit rooms are stateful and durable. When a client connects, the room's state persists across connections, making it ideal for collaborative features where multiple users interact with shared data. The server-side room logic runs on Cloudflare's edge network, reducing latency for global users.

For form collaboration specifically, PartyKit handles the complexity of operational transformation (OT) or conflict-free replicated data types (CRDTs) through its message broadcasting system. Developers can implement their preferred conflict resolution strategy while PartyKit manages the transport layer.

Setting Up the Next.js 15 Project Structure

Next.js 15's App Router provides an optimal foundation for real-time features through its support for streaming and server components. The project structure should separate concerns between the PartyKit server logic and Next.js client components.

The PartyKit server runs separately from the Next.js application but can be deployed alongside it. This separation allows the WebSocket server to scale independently from the HTTP server handling page requests.

Implementing the Client-Side Form Component

The client component manages WebSocket connections, local state, and optimistic updates. Next.js 15's use client directive clearly separates this interactive component from server components.

Handling Conflict Resolution and Data Persistence

Real-time collaboration introduces race conditions when multiple users edit the same field simultaneously. The implementation above uses a last-write-wins strategy, which works for many use cases but may cause data loss in high-conflict scenarios.

For production applications, consider implementing operational transformation or using a CRDT library like Yjs. Yjs integrates well with PartyKit and provides automatic conflict resolution:

Data persistence requires integration with a database. PartyKit rooms can connect to external storage through their onConnect and onClose hooks:

WebSocket connections consume server resources differently than HTTP requests. Each active connection maintains an open socket, which limits the number of concurrent users per PartyKit room. For most form applications, this limit (around 1000-2000 concurrent users per room) provides adequate capacity.

Throttling message broadcasts prevents performance degradation during rapid updates. Debouncing field changes on the client side reduces network traffic:

For applications requiring presence indicators across thousands of forms, implement room sharding or use PartyKit's built-in connection limits to prevent resource exhaustion. Monitor connection counts and implement graceful degradation when approaching capacity limits.

The combination of Next.js 15's streaming capabilities and PartyKit's edge deployment creates a responsive collaborative experience. Server components can pre-render static form structure while client components handle real-time updates, minimizing initial bundle size and improving time-to-interactive metrics.

Real-Time Forms in Next.js 15 with PartyKit

Multi-tenant SaaS applications require careful architectural decisions around data isolation, user experience, and route management. Next.js 15's parallel routes feature provides an elegant solution for building complex dashboard layouts where different sections need to load independently while sharing common UI elements.

Understanding Parallel Routes in Multi-Tenant Contexts

Parallel routes allow multiple pages to render simultaneously in the same layout, each with independent loading states and error boundaries. For SaaS dashboards serving multiple tenants, this architecture enables granular control over how different dashboard sections load and handle errors without affecting the entire page.

The key distinction from traditional nested routes lies in how parallel routes handle navigation. Each parallel route maintains its own navigation state and can be updated independently. This becomes particularly valuable when building dashboards where tenant-specific data, analytics, and settings need to load at different rates or handle failures gracefully.

Setting Up the Base Multi-Tenant Structure

The foundation of a multi-tenant dashboard requires a route structure that identifies tenants and organizes parallel sections effectively. Next.js 15 uses the @folder convention to define parallel route slots.

The directory structure follows this pattern:

Implementing Tenant-Specific Data Fetching

Each parallel route can fetch data independently using React Server Components. This approach allows the dashboard to stream content as it becomes available, improving perceived performance for tenants with varying data volumes.

The cache function ensures that if multiple components request the same tenant data during a single request, only one database query executes. This becomes critical in multi-tenant scenarios where the same tenant context is used across multiple parallel routes.

Handling Modal Intercepting Routes for Settings

Parallel routes shine when combined with intercepting routes for modal workflows. Settings panels can render as modals when navigated to from the dashboard, but as full pages when accessed directly or refreshed.

The (..) syntax intercepts routes at the parent level. When a user clicks a settings link from the dashboard, the modal version renders. Refreshing the page or accessing the URL directly shows the full page version. This pattern maintains URL integrity while providing an enhanced UX for in-app navigation.

Parallel routes require default fallbacks for when a slot doesn't match the current URL. This becomes essential in multi-tenant dashboards where not all tenants have access to all features.

Error boundaries in parallel routes isolate failures. If the activity feed fails to load due to a database timeout or permission issue, the analytics and main content sections continue functioning normally. This isolation is crucial for maintaining dashboard availability across different tenant configurations and data access patterns.

Performance Considerations and Trade-offs

Parallel routes introduce complexity that requires careful consideration. Each parallel route creates an additional server component boundary, which can increase initial bundle size if not managed properly. The streaming benefits are most apparent when routes have significantly different data fetching times.

For tenants with small datasets where all sections load quickly (under 100ms), the overhead of multiple parallel routes may not justify the complexity. A simpler approach using a single server component with Promise.all for parallel data fetching might suffice. The parallel routes architecture provides the most value when dealing with varied data volumes across tenants or when independent error handling is critical.

Route caching behavior also changes with parallel routes. Each slot maintains its own cache key, which can lead to increased memory usage in applications with many tenants and frequent navigation. Implementing proper revalidation strategies and monitoring cache hit rates becomes more important than with traditional nested routes.

The mental model shift for developers is significant. Understanding how navigation affects which parallel routes render and how to structure default slots requires practice. Teams need clear conventions around when to use parallel routes versus simpler alternatives like client-side tabs or server component composition.

Successful multi-tenant dashboards with parallel routes follow several patterns. Tenant context should be established at the layout level and provided through React context or props drilling, ensuring all parallel routes have access to tenant identification. Data fetching should leverage React's cache function to deduplicate requests across parallel boundaries.

Loading states work best when implemented per-slot using loading.tsx files rather than a single loading state for the entire dashboard. This granular approach lets users interact with loaded sections while others are still streaming. Error boundaries should be specific to each parallel route, providing targeted recovery options rather than failing the entire dashboard.

Navigation between tenant dashboards requires careful URL construction to maintain the current parallel route state. Using Next.js's Link component with proper href construction ensures smooth transitions without losing the user's position in the dashboard layout.

Building Multi-Tenant SaaS Dashboards with Next.js 15

Real-time collaborative editing has become a standard feature in modern web applications. Yjs provides a robust CRDT (Conflict-free Replicated Data Type) implementation that handles the complex synchronization logic, while Next.js 15 offers the perfect foundation for building performant full-stack applications. This combination enables developers to create production-ready collaborative editors with minimal infrastructure complexity.

Yjs implements CRDTs to enable conflict-free merging of concurrent edits from multiple users. Unlike operational transformation (OT), which requires a central server to resolve conflicts, CRDTs allow each client to independently merge changes without coordination. This architecture provides better offline support and reduces server load.

The library works by tracking changes at a granular level—individual character insertions, deletions, and formatting changes. When multiple users edit the same document simultaneously, Yjs automatically resolves conflicts using its CRDT algorithms. The result is eventual consistency across all connected clients without requiring complex server-side logic.

Next.js 15 introduces several improvements for real-time applications, including enhanced Server Actions and improved WebSocket support. The architecture requires both client-side collaborative editing and server-side state synchronization.

For the WebSocket server, Next.js custom server setup works well with the y-websocket provider:

Building the Collaborative Editor Component

ProseMirror provides a solid foundation for rich text editing. The integration with Yjs happens through the y-prosemirror binding, which synchronizes ProseMirror's document state with Yjs's shared type.

Implementing Persistence with Server Actions

Next.js 15 Server Actions provide a clean way to persist document snapshots. While Yjs handles real-time synchronization, periodic snapshots ensure data durability and faster initial loads for new clients.

The WebSocket server can be enhanced to load initial state and periodically save snapshots:

Handling Offline Support and Conflict Resolution

One significant advantage of Yjs is built-in offline support. The library automatically queues changes made while disconnected and merges them when connection resumes. However, developers should implement proper UI feedback for offline states.

The y-indexeddb provider enables local persistence:

For applications requiring strict ordering or validation, consider implementing a middleware layer that validates changes before broadcasting. This adds latency but prevents invalid states:

Yjs performs well for documents up to several thousand concurrent operations. For larger documents, consider implementing document sharding—splitting content into multiple Yjs documents based on logical sections.

Memory usage scales with document history. The garbage collection option (gc: true) removes tombstones from deleted content, but this prevents clients from syncing if they've been offline for extended periods. The trade-off depends on the application's requirements:

- Enable GC for applications where users rarely work offline for extended periods

- Disable GC for applications requiring full history preservation or frequent offline work

WebSocket connection limits become relevant at scale. A single Node.js process handles approximately 10,000-15,000 concurrent WebSocket connections. Beyond this threshold, implement horizontal scaling with a message broker like Redis:

The combination of Next.js 15 and Yjs provides a robust foundation for collaborative editing. The CRDT approach eliminates complex server-side conflict resolution while maintaining strong consistency guarantees. For production deployments, implement proper monitoring for WebSocket connections, document size metrics, and sync latency to identify bottlenecks early.

Tutorials

Next.js Toast Notifications with Motion: Swipe, Stack, A11y

react-grid-layout in Next.js 16: Draggable, Resizable Dashboard

Real-Time Forms in Next.js 15 with PartyKit

Building Multi-Tenant SaaS Dashboards with Next.js 15

Building Real-Time Collab Editors with Next.js 15 & Yjs