DEV Community: Wade Thomas

Protecting Routes in TanStack Start with Zustand

Wade Thomas — Mon, 30 Mar 2026 04:54:07 +0000

Route protection in TanStack Start doesn't have a built-in auth guard out of the box, but combining a Zustand store with a layout route gives you a clean, reusable solution that works well with SSR and hydration.

Here's the full setup.

The Auth Store

First, the Zustand store. It persists the user to localStorage via the persist middleware and uses a hasHydrated flag to track when the store has been rehydrated from storage. This is critical — without it you'll get a flash of redirect on page load even for logged-in users.

import type { User } from '@/types';
import { create } from 'zustand';
import { persist } from 'zustand/middleware';
import { logoutUser } from '@/lib/directus';

interface AuthState {
  user: User | null;
  hasHydrated: boolean;
  setHasHydrated: (state: boolean) => void;
  setUser: (user: User) => void;
  logout: () => Promise<void>;
  isLoggedIn: () => boolean;
}

export const useAuthStore = create<AuthState>()(
  persist(
    (set, get) => ({
      user: null,
      hasHydrated: false,
      setHasHydrated: (state) => set({ hasHydrated: state }),
      setUser: (user) => set({ user }),
      logout: async () => {
        await logoutUser();
        set({ user: null });
      },
      isLoggedIn: () => !!get().user,
    }),
    {
      name: 'auth-storage',
      onRehydrateStorage: () => (state) => {
        state?.setHasHydrated(true);
      },
    },
  ),
);

The onRehydrateStorage callback fires once Zustand has finished reading from localStorage and sets hasHydrated to true. This is the signal your protected layout waits for before making any redirect decisions.

The User Type

The User type maps directly to the Directus user fields you need in your app.

export interface User {
  id: string;
  first_name: string;
  last_name: string;
  email: string;
  avatar: string | null;
  location?: string;
  description?: string;
}

The Protected Layout Route

TanStack Start's file-based routing lets you create layout routes that wrap child routes. The _protectedLayout route acts as an auth guard — it checks the store and redirects to login if no user is present.

import MainLayout from '@/components/layouts/MainLayout';
import { createFileRoute, useNavigate } from '@tanstack/react-router';
import { useAuthStore } from '@/store/authStore';
import { useEffect } from 'react';

export const Route = createFileRoute('/auth/_protectedLayout')({
  component: ProtectedLayout,
  notFoundComponent: () => {
    return <p>This page doesn't exist!</p>;
  },
});

function ProtectedLayout() {
  const { user, hasHydrated } = useAuthStore();
  const navigate = useNavigate();

  useEffect(() => {
    if (hasHydrated && !user) {
      navigate({ to: '/auth/login' });
    }
  }, [user, hasHydrated]);

  if (!hasHydrated) return null;
  if (!user) return null;

  return <MainLayout />;
}

The two guard conditions are important:

if (!hasHydrated) return null — waits for the store to rehydrate before rendering anything, preventing a flash of redirect
if (!user) return null — prevents rendering the layout while the redirect is in flight

Only when both conditions pass does MainLayout render.

The Main Layout

MainLayout is a standard shell component that renders your header, footer and the current route's content via Outlet.

import { Outlet } from '@tanstack/react-router';
import Header from '../Header';
import { Footer } from '../Footer';

export default function MainLayout() {
  return (
    <div>
      <Header />
      <div className="max-w-7xl mx-auto p-4">
        <Outlet />
      </div>
      <Footer />
    </div>
  );
}

Any route nested under _protectedLayout automatically gets the auth guard and the shared layout — no need to add protection logic to individual routes.

How It All Fits Together

User logs in → setUser is called → Zustand persists the user to localStorage
User revisits the app → Zustand rehydrates from localStorage → hasHydrated is set to true
Protected layout checks hasHydrated and user → renders MainLayout if both pass
User logs out → logout calls Directus, clears the user from the store → redirect to login

This pattern keeps auth logic in one place, works cleanly with SSR hydration, and scales to as many protected routes as you need without repeating any guard logic.

Have questions about the setup? Drop a comment below.

Directus Auth out of the Box — Registration, Login, Email Verification and Password Reset

Wade Thomas — Mon, 30 Mar 2026 04:37:13 +0000

One of the things I appreciate most about Directus is that authentication is built in. Registration, login, email verification, and password reset — all handled without reaching for a third party auth service like Auth0 or Clerk.

Here's how I implement the full auth flow in a TanStack Start app using the Directus SDK.

User Registration

The SDK's registerUser function handles registration. You pass the email, password and any additional fields. The verification_url tells Directus where to redirect the user after they click the link in their email — Directus appends the token to that URL automatically.

export async function registerUser(
  email: string,
  password: string,
  firstName: string,
  lastName: string,
) {
  const options = {
    first_name: firstName,
    last_name: lastName,
    verification_url: `${import.meta.env.VITE_TANSTACK_URL}/auth/verify-email`,
  };
  return await directus.request(
    registerUserDirectus(email, password, options),
  );
}

Directus sends the verification email automatically via your configured SMTP provider. I use Resend — SMTP is configured directly in the Docker Compose file via environment variables and the whole setup takes just a few minutes.

EMAIL_TRANSPORT: smtp
EMAIL_SMTP_HOST: smtp.resend.com
EMAIL_SMTP_PORT: 465
EMAIL_SMTP_USER: resend
EMAIL_SMTP_PASSWORD: your_resend_api_key
EMAIL_FROM: noreply@yourdomain.com

Login

Logging in is a single call on the Directus client. Session cookies are handled automatically thanks to the credentials: 'include' config set up on the client.

export async function loginUser(email: string, password: string) {
  return await directus.login({ email, password });
}

Clean, no token management, no localStorage juggling. The session is maintained via cookie.

Email Verification

When the user clicks the link in their verification email, they land on your /auth/verify-email route with a token in the query string. You take that token and hit Directus's verify endpoint directly.

function VerifyEmailComponent() {
  const { token } = Route.useSearch();
  const [status, setStatus] = useState<
    'verifying' | 'success' | 'error' | 'pending'
  >('pending');

  useEffect(() => {
    if (!token) return;

    async function verify() {
      setStatus('verifying');
      try {
        const response = await fetch(
          `${import.meta.env.VITE_DIRECTUS_URL}/users/register/verify-email?token=${token}`,
          { method: 'GET' },
        );
        if (response.ok) {
          setStatus('success');
        } else {
          setStatus('error');
        }
      } catch (err) {
        setStatus('error');
      }
    }
    verify();
  }, [token]);
}

The status state drives your UI — show a spinner while verifying, a success message on completion, or an error state if the token is invalid or expired.

Password Reset

The password reset flow works the same way — Directus emails the user a reset link with a token, they land on your reset page, and you POST the new password along with the token to Directus's reset endpoint.

const handleSubmit = async (e: React.FormEvent) => {
  e.preventDefault();
  if (password !== confirm) {
    setError('Passwords do not match.');
    return;
  }
  setLoading(true);
  setError(null);

  try {
    const response = await fetch(
      `${import.meta.env.VITE_DIRECTUS_URL}/auth/password/reset`,
      {
        method: 'POST',
        headers: { 'Content-Type': 'application/json' },
        body: JSON.stringify({ token, password }),
      },
    );

    if (response.ok || response.status === 204) {
      navigate({ to: '/auth/login' });
    } else {
      setError('Failed to reset password. The link may have expired.');
    }
  } catch {
    setError('Something went wrong. Please try again.');
  } finally {
    setLoading(false);
  }
};

A 204 response means success — redirect the user to login. Handle expired tokens gracefully with a clear error message.

What Directus Handles For You

✅ Sending the verification email — via your SMTP provider configured in Docker Compose
✅ Generating and validating tokens
✅ Sending the password reset email
✅ Session management via cookies
✅ Secure password storage

All you need is your SMTP credentials added to your Docker Compose file. I use Resend for email delivery — it's straightforward to set up and works reliably. Everything else is handled by Directus out of the box.

This is the auth setup I use across all my TanStack Start projects. Combined with Directus roles and permissions, it covers everything a production app needs without adding a separate auth service to your stack.

Have questions about the setup? Drop a comment below.

Why I Switched to a VPS with Coolify for Hosting My Full Stack Apps

Wade Thomas — Mon, 30 Mar 2026 04:22:24 +0000

There are plenty of great hosting options out there — Netlify, Vercel, Railway and more. I've tried a few of them and they all have their place. But after going through a few different setups, I landed on a VPS managed with Coolify and it's been the best experience for my workflow.

Here's how I got there.

Where I Started

I started with Netlify. It's beginner friendly, deployment is simple and it works well for frontend projects. I then tried Vercel and that was also a solid experience — great DX, fast deploys, good defaults.

Both are genuinely good platforms. But as my projects grew more complex — running a frontend, a Directus instance, a database — the platform costs and constraints started to feel limiting.

The Raw VPS Experiment

I decided to try self-hosting on an Ubuntu VPS with Nginx as my web server and reverse proxy. Manually configuring everything — SSL, domains, process management, deployments. It was a solid learning experience and I'd recommend it to anyone who wants to understand how hosting actually works under the hood.

But it wasn't the ideal long-term setup. Too much manual work, too much that could go wrong quietly.

Discovering Coolify

Coolify changed things. It's a self-hosted platform that sits on top of your VPS and gives you:

Automatic deployments — push code and your frontend deploys automatically via Git integration
Docker Compose support — I manage my Directus instance and PostgreSQL database through Coolify using Docker Compose, which keeps everything clean and reproducible
Reverse proxy handled for you — no more manually writing Nginx configs
SSL out of the box — certificates are handled automatically
No hidden fees — you pay for the VPS, that's it. Coolify itself is free to self-host

Full Control, Your Way

With a VPS you decide how it's configured. You're not subject to platform pricing changes, compute limits, or vendor lock-in. Everything runs on infrastructure you control.

The tradeoff is responsibility — you manage the server, handle updates, and own any issues that come up. It's not the right fit for everyone.

Is It Worth It?

If you're comfortable with a bit of server management and want a flexible, cost-effective setup for running full stack apps, a VPS with Coolify is hard to beat. It's the sweet spot between the ease of a managed platform and the control of raw infrastructure.

For my stack — TanStack Start on the frontend, Directus as the backend, PostgreSQL as the database — it handles everything cleanly in one place.

Have questions about the setup or want to know if it's a good fit for your project? Drop a comment below.

Why I Use Directus as My Backend — Flexible, Self-Hosted and Production Ready

Wade Thomas — Mon, 30 Mar 2026 04:15:39 +0000

If you're looking for a backend that's flexible, affordable and genuinely enjoyable to work with, Directus is worth a serious look.

Here's why it's become my default choice for full stack projects.

Free to Self-Host (With a Sensible Threshold)

Directus uses a BSL 1.1 license. If your organization has less than $5M in total annual income — revenue and funding combined — you can self-host it for free across all your projects, including production and commercial ones. No feature paywalls, no artificial limits.

Once you're past that threshold, a commercial license is required. But for the vast majority of indie developers, freelancers, startups and small teams, it's completely free.

Works with Any SQL Database

Directus sits on top of your existing database rather than replacing it. It supports PostgreSQL, MySQL, SQLite, MariaDB and more. My preference is PostgreSQL — pair them together and you get a rock solid data layer with Directus handling the API, auth, and admin UI on top.

Flexible Data Structures

Whether you're building a simple blog, an e-commerce store, or a complex multi-tenant app, Directus adapts to your data model. You define your collections and fields, and Directus generates a full REST and GraphQL API automatically. No rigid schema to fight against.

Built-In Features That Scale With You

Starting small? Directus is simple enough to get up and running fast. Ready to grow? It has you covered:

Authentication — built in, with session and token support
Roles and Permissions — granular access control per collection and field
Automation — flows and webhooks for backend logic without extra services
Dashboard — a full admin UI out of the box for managing your data
File Management — upload, transform and serve assets directly

Actively Maintained

Directus is backed by a strong team of developers and an active open source community. It's regularly updated, well documented, and not going anywhere. That matters when you're building something you plan to maintain long term.

Who It's For

Startups — get a full backend running quickly without over-engineering
Freelancers — one backend you can reuse across different client projects
Growing products — the feature set scales as your requirements do
Developers who want control — self-host it, own your data, no vendor lock-in

I use Directus with TanStack Start on the frontend and the Directus SDK for all data fetching. If you're exploring it for your next project and want to see how the integration works in practice, I've covered the SDK setup and data fetching patterns in previous posts on my profile.

Have a project in mind and want to know if Directus is the right fit? Drop a comment and I'm happy to help.

TanStack Start: Metadata, Data Loading and Loading Skeletons in One Route File

Wade Thomas — Mon, 30 Mar 2026 04:11:22 +0000

TanStack Start has become my go-to for full stack React apps. One of the things I enjoy most about it is how cleanly it handles three things that are usually spread across multiple files and libraries — metadata, data fetching, and loading UI — all colocated in a single route.

Here's how I use head, loader, and pendingComponent together.

head — Per-Route Metadata

head lets you define document-level metadata per route. Page title, meta description, open graph tags — all scoped to that route without a global workaround or a third party head manager.

head: () => ({
  meta: [
    { title: 'All Articles — Big Cats' },
    { name: 'description', content: 'Every story, every species.' },
  ],
}),

Each route owns its own SEO info. No context providers, no helmet libraries, no prop drilling.

loader — Data Fetching Before Render

loader is where you fetch everything your route needs. It runs on the server or client depending on your SSR config, and the data it returns is available in your component via useLoaderData. Parallel fetches with Promise.all are the standard pattern here.

loader: async () => {
  const [posts, categories] = await Promise.all([
    getPosts(),
    getCategories()
  ])
  return { posts, categories }
},

Both fetches run in parallel — no waterfall, no useEffect, no loading state management in the component. The data is just there when the component renders.

pendingComponent — Skeleton While the Loader Resolves

pendingComponent renders while the loader is still resolving. It's the right place for skeletons or placeholder UI. The pendingMs and pendingMinMs options give you timing control — useful for avoiding a skeleton flash on fast connections while still showing it on slow ones.

pendingComponent: () => (
  <main className="min-h-screen bg-black text-white">
    <section className="border-b border-white/10 px-6 py-16 text-center">
      <h1 className="text-4xl font-bold tracking-tight md:text-6xl">
        All Articles
      </h1>
      <p className="mt-3 text-white/50">Every story, every species.</p>
    </section>
    <section className="mx-auto max-w-6xl px-6 py-16">
      <PostGridSkeleton />
    </section>
  </main>
),

The layout and headings render immediately while PostGridSkeleton holds the place for the actual content. The page feels instant even on slower connections.

All Together in One Route

What I appreciate most is that all three live in the same route file. The metadata, the data fetching, and the loading UI are colocated — no jumping between files to understand what a route does.

export const Route = createFileRoute('/articles')({
  head: () => ({
    meta: [
      { title: 'All Articles — Big Cats' },
      { name: 'description', content: 'Every story, every species.' },
    ],
  }),
  loader: async () => {
    const [posts, categories] = await Promise.all([
      getPosts(),
      getCategories()
    ])
    return { posts, categories }
  },
  pendingComponent: () => (
    <main className="min-h-screen bg-black text-white">
      <section className="border-b border-white/10 px-6 py-16 text-center">
        <h1 className="text-4xl font-bold tracking-tight md:text-6xl">
          All Articles
        </h1>
        <p className="mt-3 text-white/50">Every story, every species.</p>
      </section>
      <section className="mx-auto max-w-6xl px-6 py-16">
        <PostGridSkeleton />
      </section>
    </main>
  ),
})

If you're evaluating TanStack Start for your next full stack project, this colocation pattern alone is worth the look. Everything your route needs — SEO, data, loading UI — in one place.

I pair this with Directus as my CMS and Tailwind CSS v4 for styling. The getPosts() and getCategories() calls come from a single directus.ts file using the Directus SDK — I covered that setup in a previous post if you want to see how that layer is structured.

Rendering Rich Text Safely in TanStack Start with Directus, DOMPurify & Tailwind Typography

Wade Thomas — Mon, 30 Mar 2026 04:04:31 +0000

If you're using Directus as a headless CMS, the built-in WYSIWYG editor outputs raw HTML. The challenge is rendering it in React safely, with proper styling, and without reaching for dangerouslySetInnerHTML.

Here's how to solve it with three packages working together.

The Stack

DOMPurify — sanitizes HTML, stripping XSS vectors before they touch the DOM
html-react-parser — converts sanitized HTML into React elements
Tailwind CSS v4 Typography — styles everything automatically with the prose class

Installing the Packages

npm install dompurify html-react-parser
npm install @tailwindcss/typography

Step 1 — Sanitize the HTML

Create a reusable utility function that runs DOMPurify on any HTML string coming from Directus. The typeof window === 'undefined' guard handles SSR — DOMPurify is browser-only.

export const sanitizeHtml = (html: string) => {
  if (typeof window === 'undefined') return html;
  return DOMPurify.sanitize(html);
};

Step 2 — Parse and Render

Pass the sanitized HTML through html-react-parser to convert it into React elements. Wrap it in a prose div and Tailwind Typography handles all the styling.

import parse from 'html-react-parser';
import { sanitizeHtml } from '@/utils/sanitizeHtml';

<div className="prose dark:prose-invert prose-ul:text-foreground
  prose-li:marker:text-foreground prose-strong:text-foreground max-w-none">
  {parse(sanitizeHtml(product.description))}
</div>

What You Get

✅ XSS safe — DOMPurify strips malicious scripts before rendering
✅ No dangerouslySetInnerHTML — html-react-parser converts to React elements directly
✅ Dark mode ready — prose-invert handles the color flip automatically
✅ Design system aware — prose-strong:text-foreground and prose-ul:text-foreground pull from your CSS variables so text always matches your theme
✅ Headings, lists, bold, spacing — all styled automatically by Tailwind Typography

Why Not Just Use dangerouslySetInnerHTML?

dangerouslySetInnerHTML renders raw HTML with no sanitization. If your CMS content ever contains injected scripts — whether from a compromised editor, a bad import, or a malicious user — it executes directly in the browser. DOMPurify + html-react-parser gives you the same rendered output with none of the risk.

This pattern works with any headless CMS that outputs HTML from a rich text editor — Directus, Payload, Strapi, or Contentful. One utility function and a prose wrapper is all it takes.

Connecting TanStack Start to Directus with the SDK — Type-Safe Data Fetching in One File

Wade Thomas — Mon, 30 Mar 2026 03:45:05 +0000

If you're using Directus as your headless CMS and TanStack Start for your frontend, you don't need to write manual fetch calls or build your own auth headers. The Directus SDK handles all of it cleanly.

Here's how I structure a single directus.ts file that covers authentication, typed data fetching, filtering, CRUD operations and file uploads.

Installing the SDK

npm install @directus/sdk

Setting Up the Client

Create the client once and export it. Passing your schema type as a generic is what unlocks end-to-end type safety across every request.

import type { Product, Navigation, CartItem, Order } from '@/types';
import {
  authentication,
  createDirectus,
  rest,
  readItems,
  createItem,
  updateItem,
  deleteItem,
  readMe,
  updateMe,
  deleteUser,
  uploadFiles,
  registerUser as registerUserDirectus,
} from '@directus/sdk';

const directusUrl =
  import.meta.env.VITE_DIRECTUS_URL ??
  process.env.VITE_DIRECTUS_URL ??
  'https://your-directus-url.com';

const directus = createDirectus(directusUrl)
  .with(authentication('session', { credentials: 'include' }))
  .with(rest({ credentials: 'include' }));

Using authentication('session') with credentials: 'include' means cookies are handled automatically — no manual token management needed.

Fetching Data with Full Type Safety

Each collection gets its own exported async function with a typed return value.

export async function getProducts(): Promise<Product[]> {
  const items = await directus.request(readItems('products'));
  return items as Product[];
}

Filtering is First-Class

The SDK's filter syntax maps directly to Directus's query engine — no raw query strings, no URL building.

export async function getProductsByCategory(
  category: string
): Promise<Product[]> {
  const items = await directus.request(
    readItems('products', {
      filter: { category: { _eq: category } },
    })
  );
  return items as Product[];
}

What Else is Covered

The same client and pattern covers the full CRUD surface:

readItems — fetch collections
createItem — insert records
updateItem — update records
deleteItem — delete records
uploadFiles — handle file uploads
readMe / updateMe / deleteUser — user profile management
registerUser — user registration

All importable directly from @directus/sdk — the SDK provides typed functions and you bring your own collection types for end-to-end type safety.

Using it in a TanStack Start Loader

TanStack Start's file-based routing and loader pattern pairs perfectly with this setup. Data is fetched server-side and ready before the component renders.

export const Route = createFileRoute('/products')({
  loader: () => getProducts()
});

No boilerplate, no custom wrappers, no type assertions. One file, full coverage.

If you're evaluating Directus as a headless CMS for a TanStack Start project this setup gets you up and running quickly with a clean, maintainable data layer from day one.