DEV Community: rogasper

How to Deploy TanStack Start with Docker and Bun

rogasper — Wed, 07 Jan 2026 02:45:04 +0000

Tanstack Start is quickly becoming the go to framework for developers who want the power of Tanstack Router with full stack capabilities. It's bleeding edge, it's fast, and the DX is incredible.
But let's be real: moving from npm run dev on your laptop to a robust, containerized production environment is where the headaches usually start.
In this guide, we aren't just going to "make it run". We are going to build a high performance deployment pipeline using Docker and Bun. We will implement a custom asset server that caches files in RAM, handles compression, and serves your app at lightning speeds.

0. The Prerequisite (Don't Skip This!)

Before we touch a single Dockerfile, there is one crucial requirement.
According to the official Tanstack Start documentation, deploying with Bun currently requires React 19. If your project is still on React 18, the server might crash or behave unpredictably.
Make sure to upgrade your dependencies first:

bun install react@19 react-dom@19

Ready? Let's build.

1. The Foundation: Vite Configuration

First, we need to make sure Vite is ready for production. We want to ensure our path aliases (like @/components) work correctly and that we strip out console logs so our production logs stay clean.
Here is the vite.config.ts setup:

// vite.config.ts
import { defineConfig } from "vite";
import { devtools } from "@tanstack/devtools-vite";
import { tanstackStart } from "@tanstack/react-start/plugin/vite";
import viteReact from "@vitejs/plugin-react";
import viteTsConfigPaths from "vite-tsconfig-paths";
import tailwindcss from "@tailwindcss/vite";
import { fileURLToPath, URL } from "node:url";

export default defineConfig({
  esbuild: {
    // Clean up logs in production
    drop: ["console", "debugger"],
  },
  server: {
    port: 3058,
  },
  plugins: [
    devtools(),
    // This plugin is vital for resolving paths like "@/lib/utils"
    viteTsConfigPaths({
      projects: ["./tsconfig.json"],
    }),
    tailwindcss(),
    tanstackStart(),
    viteReact(),
  ],
  resolve: {
    alias: {
      "@": fileURLToPath(new URL("./src", import.meta.url)),
    },
  },
});

2. The Secret Sauce: A Custom Bun Server

This is the cool part. We aren't just going to run node server.js. We are going to use a custom script that leverages Bun's native speed.
This script (based on the official reference implementation) acts as a smart asset server. it loads samll files (like icons, CSS, and small JS chunks) directly into memory (RAM).
Why?

Speed: RAM is faster than disk
Compression: It handles Gzip automatically.
Efficiency: It generates ETags so browsers cache things perfectly Create a file named server.ts in your project root and paste this in:

// server.ts
import path from 'node:path'

// --- Configuration ---
const SERVER_PORT = Number(process.env.PORT ?? 3000)
const CLIENT_DIRECTORY = './dist/client'
const SERVER_ENTRY_POINT = './dist/server/server.js'

// Simple Logging Utility
const log = {
    info: (msg: string) => console.log(`[INFO] ${msg}`),
    error: (msg: string) => console.error(`[ERROR] ${msg}`),
    success: (msg: string) => console.log(`[SUCCESS] ${msg}`),
}

// --- Asset Preloading Logic ---
// 5MB limit for in-memory files
const MAX_PRELOAD_BYTES = Number(process.env.ASSET_PRELOAD_MAX_SIZE ?? 5 * 1024 * 1024)

// (Helper functions for ETag, Gzip, and Glob patterns omitted for brevity 
// but ensure you include the full logic from the source provided earlier!)

/**
 * The Main Server Initializer
 */
async function initializeServer() {
    log.info('Starting Production Server...')

    // 1. Load the TanStack Start Handler
    let handler: { fetch: (request: Request) => Response | Promise<Response> }
    try {
        const serverModule = (await import(SERVER_ENTRY_POINT)) as any
        handler = serverModule.default
        log.success('TanStack Start handler initialized')
    } catch (error) {
        log.error(`Failed to load handler: ${String(error)}`)
        process.exit(1)
    }

    // 2. Initialize Static Routes (This scans ./dist/client)
    // Note: In your full file, ensure you include the initializeStaticRoutes function!
    const { routes } = await initializeStaticRoutes(CLIENT_DIRECTORY)

    // 3. Start Bun Server
    const server = Bun.serve({
        port: SERVER_PORT,
        routes: {
            // Serve cached assets first
            ...routes,

            // Fallback to the App Handler for everything else
            '/*': (req: Request) => {
                return handler.fetch(req)
            },
        },
    })

    log.success(`Server listening on http://localhost:${String(server.port)}`)
}

initializeServer().catch((err) => {
    log.error(String(err))
})

// ... (Paste the rest of the helper functions: initializeStaticRoutes, etc here)

(Make sure to use the full server.ts code provided in the materials section to get the full caching benefits!)

3. The Dockerfile: Small & Efficient

We will use a Multi-Stage Build. This keeps our final Docker image tiny because we don't include all the build tools (like Typescript or Vite) in the final container, only what's needed to run the app.
Key Technical Detail: Pay attention to the ARG section. Vite needs environment variables (like your API URL) available during the build process to "bake" them into the client-side Javascript.

# syntax=docker/dockerfile:1

# =============================================
# Stage 1: Builder
# =============================================
FROM oven/bun:1-alpine AS builder
WORKDIR /app

# Install dependencies (cached layer)
COPY package.json bun.lock ./
RUN bun install --frozen-lockfile

# Copy the source code
COPY . .

# --- IMPORTANT ---
# Vite needs these variables AT BUILD TIME to replace import.meta.env values
ARG VITE_API_URL
ARG VITE_BETTER_AUTH_URL
ENV VITE_API_URL=${VITE_API_URL}
ENV VITE_BETTER_AUTH_URL=${VITE_BETTER_AUTH_URL}

# Build the app
RUN bun run build


# =============================================
# Stage 2: Runner (Production)
# =============================================
FROM oven/bun:1-alpine AS runner
WORKDIR /app
ENV NODE_ENV=production

# Install curl for healthchecks
RUN apk add --no-cache curl

# Copy package files
COPY package.json bun.lock ./

# Install ONLY production deps (react, etc.)
RUN bun install --production

# Copy the build artifacts from the Builder stage
COPY --from=builder --chown=bun:bun /app/dist ./dist
COPY --from=builder --chown=bun:bun /app/server.ts ./server.ts

USER bun

# The port is dynamic via Env Vars
ENV PORT=3058
EXPOSE 3058

# Start the Custom Bun Server
CMD ["bun", "server.ts"]

4. Orchestration: Docker Compose

Finally, let's tie it all together. Using Docker Compose makes it easy to manage environment variables and ports.
We also added a healthcheck. This ensures that if the server crashes or hangs, Docker knows about it and can restart it automatically.

version: '3.8'

services:
  app:
    build:
      context: .
      dockerfile: Dockerfile
      args:
        # Pass these to the Builder stage!
        VITE_BETTER_AUTH_URL: ${VITE_BETTER_AUTH_URL}

    environment:
      # Runtime config for the Server
      NODE_ENV: production
      PORT: ${PORT:-3058}

      # App Secrets & Configs
      VITE_API_URL: ${VITE_API_URL}
      DATABASE_URL: ${DATABASE_URL}
      BETTER_AUTH_SECRET: ${BETTER_AUTH_SECRET}

      # SMTP / Email Config
      HOST_EMAIL: ${HOST_EMAIL}
      HOST_PORT: ${HOST_PORT}
      HOST_AUTH_USER: ${HOST_AUTH_USER}
      HOST_AUTH_PASS: ${HOST_AUTH_PASS}

    ports:
      # Map host port to container port
      - '${PORT:-3058}:${PORT:-3058}'

    restart: always

    healthcheck:
      # Ping the server to ensure it's alive
      test: ['CMD-SHELL', 'curl -fsS http://localhost:${PORT:-3058} || exit 1']
      interval: 10s
      timeout: 5s
      retries: 5

Conclusion

And there you have it. You aren't just running a development server in a container. You have a highly optimized, memory-caching, Bun-powered production environment.

Quick Recap:

React 19: Mandatory for Bun Development
Server.ts: Provides advanced caching and Gzip compression.
Dockerfile: Uses multi-stage builds to handle build-time env vars correctlyDocker
Compose: Orchestrates the runtime with health checks Now, just create your .env file, run docker compose up --build -d, and watch your Tanstack Start app fly!

for more information you can visit my blog

How to Build a Secure Forgot Password Flow with OTP in Better Auth

rogasper — Sun, 04 Jan 2026 07:45:04 +0000

In our previous guide, we set up Better Auth with Nodemailer to handle email verification and invites. Today, we are tackling a critical feature for any production app: The "Forgot Password" flow.
While Magic Links (links that log you in or reset your password immediately) are popular, they force the user to leave your app, open their email, and click a link that opens a new tab.
Sometimes, you want to keep the user right where they are. In this guide, we will build an OTP (One-Time Password) reset flow. The user enters their email, receives a 6-digit code, and resets their password without ever closing your tab.

The Backend Config

Good news: If you followed the previous guide, your backend is already ready.
The emailOTP plugin we installed previously handles the forget-password type automatically. When we call the forgot password function from the client, Better Auth will trigger the sendVerificationOTP hook we defined in auth.ts with the type set to "forget-password".
Just ensure your email.ts template handles the subject line dynamically (or generic enough) for password resets.

The Client-Side Implementation

We need to handle two distinct stages in our UI:

Request Stage: User enters email -> System sends OTP.
Reset Stage: User enters OTP + New Password -> System updates credentials.

1. The Logic Hooks

Instead of dumping 200 lines of UI code, let's look at the core functions using authClient.

import { authClient } from "@/lib/auth-client";
import { useState } from "react";

export const usePasswordReset = () => {
  const [stage, setStage] = useState<"request" | "reset">("request");
  const [isLoading, setIsLoading] = useState(false);
  const [error, setError] = useState<string | null>(null);

  // Step 1: Send the OTP
  const sendResetOtp = async (email: string) => {
    setIsLoading(true);
    setError(null);

    const { error } = await authClient.forgetPassword.emailOtp({
        email, 
        redirectTo: "/dashboard", // Optional: strictly for flow control
    });

    setIsLoading(false);

    if (error) {
      setError(error.message);
      return false;
    }

    setStage("reset"); // Move to next UI stage
    return true;
  };

  // Step 2: Validate OTP and Set New Password
  const resetPassword = async (email: string, otp: string, password: string) => {
    setIsLoading(true);
    setError(null);

    const { error } = await authClient.emailOtp.resetPassword({
      email,
      otp,
      password,
    });

    setIsLoading(false);

    if (error) {
      setError(error.message);
      return false;
    }

    return true; // Success!
  };

  return { stage, setStage, isLoading, error, sendResetOtp, resetPassword };
};

2. The UI Implementation

Here is how we compose the UI. I've simplified the styling to focus on the structure, but you can keep your Tailwind gradients for that premium feel.
The Request Form (Stage 1):

if (stage === "request") {
  return (
    <div className="container">
      <h1>Forgot Password</h1>
      <p>Enter your email to receive a verification code.</p>

      <Input 
        type="email" 
        value={email} 
        onChange={(e) => setEmail(e.target.value)} 
        placeholder="name@example.com"
      />

      <Button 
        onClick={() => sendResetOtp(email)} 
        disabled={isLoading || !email}
      >
        {isLoading ? "Sending Code..." : "Send OTP"}
      </Button>

      {error && <p className="text-red-500">{error}</p>}
    </div>
  );
}

The Reset Form (Stage 2):

if (stage === "reset") {
  return (
    <div className="container">
      <h1>Reset Password</h1>
      <p>Code sent to <span className="font-bold">{email}</span></p>

      {/* OTP Input - limit to 6 numbers */}
      <Label>OTP Code</Label>
      <Input 
        value={otp} 
        onChange={(e) => setOtp(e.target.value.replace(/\D/g, "").slice(0, 6))}
        className="tracking-widest text-center text-lg"
        placeholder="000000"
      />

      <Label>New Password</Label>
      <Input 
        type="password" 
        value={newPassword}
        onChange={(e) => setNewPassword(e.target.value)} 
      />

      <Label>Confirm Password</Label>
      <Input 
        type="password" 
        value={confirmPassword}
        onChange={(e) => setConfirmPassword(e.target.value)} 
      />

      <Button 
        onClick={() => {
           if (newPassword === confirmPassword) {
             resetPassword(email, otp, newPassword);
           }
        }}
        disabled={isLoading}
      >
        {isLoading ? "Resetting..." : "Set New Password"}
      </Button>

       {/* Resend Logic */}
      <button onClick={() => sendResetOtp(email)} className="text-sm underline mt-4">
        Resend Code
      </button>
    </div>
  );
}

Magic Link vs. OTP: Which one should you choose?

I chose OTP for implementation, but Better Auth support both. Here is a quick breakdown to help you decide which fits your app better.

The OTP Approach (This Guide)

Pros:

Seamless Context: The user never leaves your application tab. This reduces "drop-off" rates.
Mobile Friendly: Great for mobile apps where handling deep links (Universal Links) can be buggy or complex to set up.
Perceived Security: Users are accustomed to 2FA codes; it feels secure to enter a code.

Cons:

Friction: The user has to manually copy and paste (or type) a code.
Typos: Users might mistype the code or the password, requiring error handling.

The Magic Link Approach

Pros:

Zero Friction: One click and they are done.
Simple: No need for the user to understand what a "code" is.

Cons:

Context Switching: Forces the user to open a new browser window/tab.
Email Scanners: aggresive enterprise email scanners sometimes "click" links to check for malware, which can accidentally invalidate one-time tokens before the user sees them.

Conclusion

By using the emailOTP plugin in Better Auth, we've created a password reset flow that keeps users engaged within our application. It's a small UX detail, but keeping users inside your app ecosystem always leads to higher conversion and retention.

for more info you can blog.

How to Setup Email Verification & Organization Invites with Better Auth and Nodemailer

rogasper — Sat, 27 Dec 2025 14:20:25 +0000

Authentication today goes beyond just "username and password." To build a secure and collaborative application, you almost cretainly need two things: Email Verification (to ensure users are real) and Organization Invites (to let users collaborate).
Better Auth is fantastic because it's modular. Instead of forcing a specific email provider on you, it provides the logic and lets you handle the delivery.
In this guide, we will implement OTP Verification and Team Invitations using Better Auth and Nodemailer. We chose Nodemailer because it gives you total freedom, you can use Gmail, AWS SES, Resend, or any SMTP server you want.

Step 1: Installation

First, let's get the necessary packages installed. We need the core auth library and the mailer transport.

npm install nodemailer better-auth
npm install -D @types/nodemailer

Step 2: Setting Up the Email Transporter

Before touching the auth logic, we need a helper file to handle the actual sending of emails. We will create a transporter (the postman) and defining our HTML templates (the letters).
Create a file at src/lib/email.ts:

// src/lib/email.ts
import nodemailer from 'nodemailer'

// 1. Setup Transporter
const smtpPort = Number(process.env.HOST_PORT) || 587;

const transporter = nodemailer.createTransport({
    host: process.env.HOST_EMAIL,
    port: smtpPort,
    secure: smtpPort === 465, // true for 465, false for other ports
    auth: {
        user: process.env.HOST_AUTH_USER,
        pass: process.env.HOST_AUTH_PASS,
    },
});

// 2. OTP Verification Template
type VerificationProps = {
    email: string,
    otp: string,
    type: "sign-in" | "email-verification" | "forget-password";
}

export const verificationEmailTemplate = ({ email, otp, type }: VerificationProps) => {
    return {
        from: `"My App" <${process.env.HOST_ALIAS_EMAIL}>`,
        to: email,
        subject: "Your Verification Code",
        html: `
            <div style="font-family: sans-serif; padding: 20px;">
              <h2>Verification Code</h2>
              <p>Please use the following code to complete your action:</p>
              <div style="background: #f3f4f6; padding: 20px; text-align: center; font-size: 32px; font-weight: bold; letter-spacing: 5px;">
                ${otp}
              </div>
              <p>This code expires in 5 minutes.</p>
            </div>
        `,
    }
}

// 3. Organization Invitation Template
type InvitationProps = {
    email: string;
    inviterName: string;
    inviterEmail: string;
    organizationName: string;
    inviteLink: string;
    role: string;
}

export const invitationEmailTemplate = (data: InvitationProps) => {
    return {
        from: `"My App" <${process.env.HOST_ALIAS_EMAIL}>`,
        to: data.email,
        subject: `You've been invited to ${data.organizationName}`,
        html: `
            <div style="font-family: sans-serif; padding: 20px;">
              <h2>You're Invited!</h2>
              <p><strong>${data.inviterName}</strong> has invited you to join <strong>${data.organizationName}</strong>.</p>
              <br />
              <a href="${data.inviteLink}" style="background: #007bff; color: white; padding: 12px 24px; text-decoration: none; border-radius: 5px; font-weight: bold;">
                Accept Invitation
              </a>
              <p style="margin-top: 20px; font-size: 12px; color: #666;">Or copy this link: ${data.inviteLink}</p>
            </div>
        `,
    }
}

export default transporter

Step 3: Configurating the Better Auth Server

Now, we hook everything into Better Auth. We will use two plugins:

emailOTP: Handles the logic for generating and validating one-time passwords.
organization: Handles team management and intivations tokens. In your main config file (usually src/lib/auth.ts), inject the Nodemailer functions:

// src/lib/auth.ts
import { betterAuth } from "better-auth";
import { organization, emailOTP } from "better-auth/plugins";
import transporter, { verificationEmailTemplate, invitationEmailTemplate } from "./email";
// ... other imports (db, adapters, etc)

export const auth = betterAuth({
  // ... your database and adapter config here

  plugins: [
    // 1. Organization Plugin (For Invites)
    organization({
        async sendInvitationEmail(data) {
            // Construct the acceptance link (frontend route)
            const inviteLink = `${process.env.VITE_APP_URL}/accept-invitation/${data.id}`;

            // Send the email
            await transporter.sendMail(invitationEmailTemplate({
                email: data.email,
                inviterName: data.inviter.user.name || "A user",
                inviterEmail: data.inviter.user.email,
                organizationName: data.organization.name,
                inviteLink,
                role: data.role,
            }));
        },
    }),

    // 2. Email OTP Plugin (For Verification)
    emailOTP({
        async sendVerificationOTP({ email, otp, type }) {
            // Send the OTP
            await transporter.sendMail(verificationEmailTemplate({ email, otp, type }));
        },
        otpLength: 6,
        expiresIn: 300, // 5 minutes
    }),
  ]
});

Step 4: Environment Variables

Security is key. Never hardcode your SMTP credentials. Set these up in your .env file.
Pro Tip: For local development, use a service like Mailtrap or Ethereal to catch emails without spamming real users.

# SMTP Configuration
HOST_EMAIL=smtp.gmail.com
HOST_PORT=587
HOST_AUTH_USER=your-email@gmail.com
HOST_AUTH_PASS=your-app-password
HOST_ALIAS_EMAIL=no-reply@yourdomain.com

# Frontend URL
VITE_APP_URL=http://localhost:3000

Step 5: Frontend Implementation (Client Side)

Now that the backend is ready, here is how you trigger these actions from your frontend (React Example).

Sign Up (Triggering Verification)

When a user signs up using the emailOTP method, Better Auth will automatically trigger the sendVerificationOTP function we defined earlier.

import { authClient } from "@/lib/auth-client";

const handleSignUp = async () => {
    await authClient.signUp.email({
        email: "newuser@example.com",
        password: "securepassword",
        name: "John Doe",
        callbackURL: "/dashboard"
    });

    // Redirect user to an OTP input page
};

Sending an Invitation

This is usually done by an Admin inside their dashboard settings.

import { authClient } from "@/lib/auth-client";

const inviteMember = async () => {
    await authClient.organization.inviteMember({
        email: "colleague@example.com",
        role: "member", // or 'admin', 'owner'
    });
    // This triggers the 'sendInvitationEmail' function on the server
};

Accepting an Invitation

When the user clicks the link in their email (e.g., http://localhost:3000/accept-invitation/invitation-id-123), you handle it on this page:

// On your /accept-invitation/[id] page
import { useParams } from "react-router-dom"; // or your router of choice
import { authClient } from "@/lib/auth-client";

const AcceptPage = () => {
    const { id } = useParams();

    const handleAccept = async () => {
        const { error } = await authClient.organization.acceptInvitation({
            invitationId: id
        });

        if (!error) {
            // Redirect to organization dashboard
        }
    };

    return <button onClick={handleAccept}>Join Organization</button>;
}

Why This Architecture Works

Flexibility: By using Nodemailer, you aren't locked into a specific provider. You can start with Gmail for free, then switch to AWS SES or SendGrid as you scale, without changing your auth logic.
Full Control: You have 100% control over the HTML templates. You can brand them, style them, and adjust the wording exactly how you want.
Security: Your credentials stay on the server. The Client simply request an action (like "invite user"), and the secure server handles the email delivery. Integrating email verification and invites makes your app feel professional and secure. With Better Auth and Nodemailer, it's surprisingly easy to implement.

for more information you can check my website

Prevent React Native Timers from Stopping in Background: A Complete Guide

rogasper — Fri, 26 Dec 2025 03:06:41 +0000

Building a habit tracking app is a fun challenge. For my latest project, I decided to gamify the experience with a UI inspired by dating apps, swipe left to skip a habit, swipe right to complete it.
It was all smooth sailing until I implemented "Duration Habits" (e.g., "Medidate for 20 minutes"). The UI looked great, but I immediately hit a classic React Native roadblock:

The moment the user locked their phone or switched to another app, the Javascript thread paused, and my timer stopped dead.

For a meditation or workout timer, this is broken functionality. The user expects the timer to alert them when they are done, regardless of whether the app is open.

In this post, I'll walk through how I solved this using Android Foreground Services via react-native-background-actions, and crucially, how I synchronized that background process with my modern state management solution, Zustand.

The Challenge: React Native vs. The OS

Mobile operating systems are aggresive about saving battery. When an app moves to the background, iOS and Android will suspend its Javascript execution thread almost immediately.
To keep code running, we need a special permit from the OS. On Android, this called a Foreground Service. It tells the OS, "Hey, I'm doing something important that the user is aware of, please don't kill me." This requires showing a persistent notification in the status bar so the user knows the app is still active.
The Stack

React Native Expo (Dev Client) or bare workflow.
State Management: Zustand (This is important later).
The Hero Library: react-native-background-actions

Step 1: Setup and Configuration

first, get the library installed:

npm install react-native-background-actions

Android Configuration is Mandatory

You cannot skip this step. You need to declare the necessary permission and the service itself in your android/app/src/main/AndroidManifest.xml file. Without this, the app will crash when you try to start the background task.
Open AndroidManifest.xml and add these lines inside the <manifest> tag and <application> tag respectively:

<manifest ...>
    <uses-permission android:name="android.permission.FOREGROUND_SERVICE" />
    <uses-permission android:name="android.permission.WAKE_LOCK" />

    <application ...>
        <service android:name="com.asterinet.react.bgactions.RNBackgroundActionsTask" />
    </application>
</manifest>

Step 2: The State Synchronization Problem

This is where most developers get stuck.
A background task created by this library runs in a Javascript context that is separate from your React Component lifecyle.
Crucial realization: You cannot use standard React Hooks like useState, useEffect, or custom Zustand hooks like useHabitStore() inside the background task loop. They won't update or react as you expect.

The Solution: Imperative State Access

Since we are using Zustand, we have an escape hatch. Instead of using reactive hook inside the background loop, we will access the store directly and imperatively using useHabitStore.getState().

Step 3: The Background Task Function

This is the heart of the operation. This function defines what happens while the app is in the background. It's essentially an infinite loop that only breaks when the timer finishes or the user pauses it in the UI.
Here is the real-world code adapted for a timer:

import BackgroundService from 'react-native-background-actions';
import { useHabitStore } from './store/habitStore'; // Import your Zustand store directly

// Helper sleep function to prevent CPU overload
const sleep = (time: number) => new Promise<void>((resolve) => setTimeout(() => resolve(), time));

// The task function must be defined outside of your React components
export const timerBackgroundTask = async (taskDataArguments?: {
  targetSeconds?: number;
  habitName?: string;
}): Promise<void> => {
  const target = taskDataArguments?.targetSeconds || 0;
  const habitName = taskDataArguments?.habitName || "Timer";

  await new Promise(async (resolve) => {
    // The loop runs as long as the service is active
    while (BackgroundService.isRunning()) {
      // 1. IMPERATIVE STATE ACCESS (No Hooks allowed here!)
      const state = useHabitStore.getState();

      // 2. Check Logic Stop condition
      // If the user paused manually in the UI, break the loop.
      if (!state.timerIsRunning || state.timerIsCompleted) {
        break;
      }

      // 3. Timer Logic utilizing Date.now() for robustness
      const currentTime = Date.now();
      const startTime = state.timerStartTime;

      // Initialize start time if missing
      if (!startTime) {
        useHabitStore.getState().setTimerStartTime(currentTime);
        await sleep(1000);
        continue;
      }

      const elapsed = Math.floor((currentTime - startTime) / 1000);

      // 4. Check if Target Reached
      if (target > 0 && elapsed >= target) {
        // Update State via getState()
        useHabitStore.getState().setTimerIsCompleted(true);
        useHabitStore.getState().setTimerIsRunning(false);
        useHabitStore.getState().setTimerTimeElapsed(target);

        // Update Final Notification
        await BackgroundService.updateNotification({
          taskTitle: habitName,
          taskDesc: "Timer finished!",
          progressBar: { // Fill the bar completely
            max: target,
            value: target,
            indeterminate: false,
        },
        });
        // Break the loop to finish the task naturally
        break;
      } else {
        // Standard Tick Update
        useHabitStore.getState().setTimerTimeElapsed(elapsed);

        // Update the native notification with a progress bar!
        const remaining = Math.max(0, target - elapsed);
        await BackgroundService.updateNotification({
          taskTitle: habitName,
          // Assuming a helper function formatTime exists
          taskDesc: `Remaining: ${formatTime(remaining)}`, 
          progressBar: {
            max: target,
            value: elapsed,
            indeterminate: false,
          },
        });
      }

      // 5. IMPORTANT: Sleep to save battery and CPU
      await sleep(1000);
    }

    // When the loop breaks, the task ends.
    resolve(undefined);
  });
};

Step 4: Triggering the Service from the UI

Now we need to connect our React Native UI to this background task. When the user taps "Start Timer" on a habit card, the service should spin up. When they tap "Pause", it should tear down.
We use useEffect within our timer component to monitor changes in our Zustand state and react accordingly.

import { useEffect } from 'react';
import BackgroundService from 'react-native-background-actions';
import { useHabitStore } from './store/habitStore';
import { timerBackgroundTask } from './backgroundTasks'; // Import the function above
import { COLORS } from './theme';

// Inside your TimerComponent...
const { 
  timerIsRunning, 
  timerIsCompleted, 
  selectedHabit, 
  targetSeconds 
} = useHabitStore();

useEffect(() => {
  const manageBackgroundService = async () => {
    // Condition to START: Timer is running, not finished, and a habit is selected
    if (timerIsRunning && !timerIsCompleted && selectedHabit) {

      // Options for the native notification
      const options = {
        taskName: "Habit Timer Task",
        taskTitle: selectedHabit.name,
        taskDesc: "Timer Running...",
        taskIcon: {
          name: "ic_launcher", // Ensure this icon exists in android/app/src/main/res/mipmap-*
          type: "mipmap",
        },
        color: COLORS.primary,
        parameters: { // Pass initial data to the background task arguments
          targetSeconds,
          habitName: selectedHabit.name,
        },
      };

      try {
        // Only start if it's not already running
        if (!BackgroundService.isRunning()) {
          await BackgroundService.start(timerBackgroundTask, options);
          console.log('Background service started successfully');
        } 
        // Optional: else { BackgroundService.updateNotification(...) } if needed just for UI updates
      } catch (error) {
        console.error("Background Service Start failed:", error);
      }
    } else {
      // Logic to STOP: If timer is paused in UI or completed
      if (BackgroundService.isRunning()) {
        console.log('Stopping background service...');
        await BackgroundService.stop(); // This initiates the teardown of the while loop
      }
    }
  };

  manageBackgroundService();

  // Re-run this logic whenever the timer state changes
}, [timerIsRunning, timerIsCompleted, selectedHabit, targetSeconds]);

Key Takeaways for Implementation

If you are implementing this in your own app, keep these lessons in mind:

State Management Paradox: Remember, the background task is just a standard JS function, not a React component. You cannot use hooks. If you use Redux or Zustand, you must use their imperative APIs (like store.getState() and store.dispatch()) to read and write data inside the background loop.
The Notification Loop: The BackgroundService.updateNotification allows you to make the notification feel "alive." Updating the progress bar and timer text every second assures the user that the app hasn't crashed while in their pocket.
Clean Up is Vital: The useEffect dependency array is crucial. When timerIsRunning flips to false in your UI, you must call BackgroundService.stop(). Otherwise, you'll leave "ghost processes" running that drain battery and annoy users.
Robuts Timing: Notive in the background task I used Date.now() subtraction rather than just incrementing a counter like elapsed++. Using system time differences ensures that even if the OS briefly pauses execution, the timer calculation remains accurate when it wakes back up. This approach provided the robust "set it and forget it" experience my habit tracker needed, matching the sleekness of the swipe-based UI.

for more information about development web or mobile you can visit my website

Bridging the Gap: Implementing Better Auth with Non-Node Backends

rogasper — Thu, 25 Dec 2025 14:02:35 +0000

If you've seen the recent Dreams of Code article, you know the hype is real. Better Auth is arguably the best authentication solution for the Typescript ecosystem right now. It is type-safe, extensible, and incredibly easy to set up.
However, there is a catch: Better Auth is designed to run on a Javascript runtime (Node/Bun/Deno).

So, what happens if your backend logic lives in Go (Fiber), but you want the DX of Better Auth for your TanStack Start frontend?

In this post, I'll show you how to architect a "Proxy Pattern" using Tanstack Start to handle authentication in Node, while securely passing authorization contexts to a Go Fiber backend.

The Architecture

Since Better Auth cannot run inside Go, we run it inside our Tanstack Start server (which runs on Node/Bun). We then use a JWT Strategy to communicate with the Go backend.
Here is the flow:

Tanstack Start handles the login/signup and issues a Session Cookie
Client request hit a specific route in Tanstack Start (e.g., /api/external).
Tanstack Start acts as a proxy: it decrypts the cookie, retrieves a JWT, and forwards the request to Go.
Go Fiber validates the JWT and serves the resource.

Step 1: Configuring Better Auth (The Frontend)

First, we need to enable the JWT plugin. This is crucial because standard session cookies are opaque to the Go backend. We need a token that Go can cryptographically verify.

// lib/auth.ts
import { betterAuth } from "better-auth";
import { drizzleAdapter } from "better-auth/adapters/drizzle";
import { jwt } from "better-auth/plugins";

export const auth = betterAuth({
  advanced: {
    cookiePrefix: "your-app", // Custom prefix for cookies
  },
  baseURL: process.env.VITE_BETTER_AUTH_URL || "http://localhost:3000",
  database: drizzleAdapter(db, {
    provider: "pg",
  }),
  emailAndPassword: {
    enabled: true,
    autoSignIn: true,
  },
  plugins: [
    // The JWT plugin is essential for external backends
    jwt(), 
  ],
});

On the client side, the setup remains standard:

import { createAuthClient } from "better-auth/react";
import { jwtClient } from "better-auth/client/plugins";

export const authClient = createAuthClient({
    baseURL: import.meta.env.VITE_BETTER_AUTH_URL || "http://localhost:3000",
    plugins: [
        jwtClient(),
    ]
})

Step 2: The Proxy (Tanstack Start)

This is the secret sauce. Instead of the browser hitting the Go backend directly (which would require complex CORS and cookie sharing), we create a "Catch-All" route in Tanstack Start (routes/api/external/$.ts).
This route intercepts the request, grabs the valid token using auth.api.getToken, and forwards the request to Go with a standard Authorization: Bearer <token> header.

//routes/api/external/$.ts
import { createServerFn } from "@tanstack/react-start";
import { auth } from "../../../lib/auth";
import { createFileRoute } from "@tanstack/react-router";
import { getRequestHeaders } from "@tanstack/react-start/server";

// 1. Helper to fetch the raw token server-side
const getTokenFn = createServerFn().handler(async () => {
  const headers = getRequestHeaders();
  const { token } = await auth.api.getToken({
    headers: headers,
  });
  return token;
});

const handleRequest = async (request: Request) => {
  const isBodyAllowed = request.method !== "GET" && request.method !== "HEAD";

  // 2. Get the JWT intended for the external API
  const token = await getTokenFn();

  // 3. Strip the proxy prefix so Go receives a clean path
  const url = request.url.split("api/external")[1]; 

  // Check for file uploads
  const contentType = request.headers.get("content-type") || "";
  const isFormData = contentType.includes("multipart/form-data");

  let requestBody: BodyInit | undefined;
  if (isBodyAllowed) {
    if (isFormData) {
      requestBody = await request.arrayBuffer();
    } else {
      const text = await request.text();
      requestBody = text || undefined;
    }
  }

  // 4. Attach the Token to the new headers
  const headers: Record<string, string> = {
    Authorization: `Bearer ${token}`,
  };

  if (isFormData) {
     headers["content-type"] = contentType; // Preserve boundary for files
  } else {
    const originalContentType = request.headers.get("content-type");
    if (originalContentType) headers["content-type"] = originalContentType;
  }

  // 5. Forward request to Go
  const response = await fetch(`${process.env.NEXT_PUBLIC_API_URL}${url}`, {
    method: request.method,
    headers,
    ...(isBodyAllowed && requestBody ? { body: requestBody } : {}),
  });

  // 6. Return Go's response back to the browser
  return new Response(response.body, {
    status: response.status,
    statusText: response.statusText,
    headers: response.headers,
  });
};

export const Route = createFileRoute("/api/external/$")({
  server: {
    handlers: {
      GET: async ({ request }) => handleRequest(request),
      POST: async ({ request }) => handleRequest(request),
      PUT: async ({ request }) => handleRequest(request),
      DELETE: async ({ request }) => handleRequest(request),
      PATCH: async ({ request }) => handleRequest(request),
    },
  },
});

Step 3: Authorization in Go Fiber

Now that the Go server is receiving a standard Bearer token, we need a middleware to validate it.Unlike Node, Go doesn't have direct access to the Better Auth code. However, because Better Auth creates a standard JWK (JSON Web Key), Go can validate the signature cryptographically without hitting the database.

func UserFromRequest() fiber.Handler {
    return func(c *fiber.Ctx) error {
        // 1. Extract the Bearer Token
        authHeader := c.Get("Authorization")
        tokenStr := strings.TrimSpace(strings.TrimPrefix(authHeader, "Bearer "))

        if tokenStr == "" {
            return fiber.NewError(fiber.StatusUnauthorized, "Missing Token")
        }

        // 2. Fetch JWKS (Public Keys) from Better Auth
        // Note: You should implement caching for getJWKS() to avoid 
        // fetching keys on every request.
        keySet, err := getJWKS() 
        if err != nil {
            return fiber.NewError(fiber.StatusInternalServerError, "Key error")
        }

        // 3. Parse and Verify the Token
        token, err := jwt.Parse([]byte(tokenStr), jwt.WithKeySet(keySet))
        if err != nil {
            return fiber.NewError(fiber.StatusUnauthorized, "Invalid Token")
        }

        // 4. Extract User Claims
        userID := token.Subject()
        email, _ := token.Get("email")
        name, _ := token.Get("name")

        if email == nil || name == nil {
             return fiber.NewError(fiber.StatusUnauthorized, "Invalid Claims")
        }

        // 5. Store in Context for the Route Handlers
        c.Locals("user", &model.UserJwt{
            ID:    userID,
            Email: email.(string),
            Name:  name.(string),
        })

        return c.Next()
    }
}

Using it in the Router:

// router/router.go
func SetupRoutes(app *fiber.App) {
    // Apply middleware to protected groups
    orgs := app.Group("/orgs", middleware.UserFromRequest())

    orgs.Get("/", func(c *fiber.Ctx) error {
        user := c.Locals("user").(*model.UserJwt)
        return c.JSON(fiber.Map{
            "message": "Hello " + user.Name,
        })
    })
}

Why This Architecture Works

Merging a Node-based meta-framework with a Go backend often feels clunky, but this specific setup solves three major headaches:

CORS & Cookie Hell: By using a proxy (/api/external), your browser only ever talks to the Tanstack Start server (Same-Origin). You don't need to configure complex CORS rules or worry about SameSite cookie issues between your frontend and backend domains.
Stateless Go Backend: The Go server doesn't need to check a database for every request to validate a session. It simply verifies the JWT signature using the public key. This is incredibly fast and keeps your Go services stateless and scalable.
Best-in-Class DX: You get to use the extensive plugin ecosystem of Better Auth (Two Factor, Passkeys, Organization management) without having to re-implement complex auth logic in Go.

Trade-offs to Consider

No architecture is perfect. Here is what you are "paying" for this convenience:

The "Double Hop" Latency: Every request to your API travels: Client -> Tanstack Start (Node) -> Go Fiber -> Database. While the internal network speed between Node and Go is usually negligible (especially in Kubernetes or same-network deployments), it is technically an extra hop compared to a monolith.
Infrastructure Complexity: You are maintaining two runtimes. If the Node server goes down, your Auth goes down. If the Go server goes down, your data goes down. You need monitoring for both.
Proxying Complexity: The code snippet above handles JSON and Multipart forms, but if you need to support WebSockets or Server-Sent Events (SSE), the proxy logic in routes/api/external/$.ts will need to be significantly more robust to handle streaming connections.

The Bottom Line

If you are a solo developer or a small team, this pattern is a productivity multiplier.
It allows you to treat authentication as "solved" by the Typescript ecosystem, while letting you write your high-performance business logic in Go. You don't have to switch languages completely you just have to let them play to their respective strengths.

Conclusion

You don't have to rewrite your entire backend in Node just to use Better Auth. By leveraging the JWT Plugin and Tanstack Start server functions, you can keep your robust Go architecture while enjoying the modern authentication experience that Better Auth provides.
This setup gives you the best of both worlds:

Frontend: A unified, type-safe auth client.
Backend: High-performance Go services that are stateless and secure.

Safeguarding Your React Native App: Protecting Screens for Unauthorized Users

rogasper — Sat, 13 Dec 2025 06:09:24 +0000

Developing a mobile application often involves managing user authentication and ensuring that sensitive parts of your app are only accessible to logged-in users. In this blog post, we'll dive into how to protect your screens in a React Native application, preventing unauthorized access, as demonstrated in my video How to Protected Your Screen in React Native

My application, Dowell - Do Everything Well, is a habit tracker. A key requirement was to ensure that users who are not logged in cannot access the core functionalities within the app's protected sections. This isn't about writing code together, but rather understanding the core logic and workflow behind screen protection in React Native.

The Core Concept: Authorization Management

The fundamental idea is to manage user sessions and authentication state. If a user is not authenticated, they should be redirected to a login screen. If they are logged in, they should be able to access the main application.

Step 1: The Root Layout and Session Provider

The main core logic resides in your layout file [01:07]. Here, you'll prepare your components. In my setup, I use a QueryClientProvider for data fetching, but the most crucial part for screen protection is creating a Session Provider [01:21].

Step 2: Session Provider for State Management

This SessionProvider is essentially a state management system that keeps track of whether a user is authenticated or not. The core of this concept relies on a state variable, for example, isAuthenticated [01:49]. If the user is authenticated, this value will be true.

Step 3: Implementing Protected Routes within the Root Navigator

Inside your RootNavigator, you'll use the useSession hook to access the isAuthenticated state [02:39]. This is where the magic of screen protection happens.

If the user is authenticated (isAuthenticated is true): You will display your main application screens. As shown in the video, I wrap my app's internal screens (e.g., from the app folder) within a stack navigator [02:49].
If the user is NOT authenticated (isAuthenticated is false): They will be redirected to the sign-in page [03:18]. The most important part of protecting your screen is achieved by conditionally rendering stacks. You can wrap your screens with a "protected stack" and use a conditional check [03:30]. This check determines:
If isAuthenticated is true, the user is redirected to the main app screens.
If isAuthenticated is false, the user is redirected to the signIn page [03:57].

Demonstration of the Workflow

As I demonstrate in the video, when an unauthorized user tries to open the application, they are immediately redirected to the sign-in page [04:07]. Once they successfully log in, they are then directed to the main application screens [04:39].
The application also intelligently checks the authentication status when reopened. If you close the app and open it again, it will verify if you are authenticated. If you are, it will redirect you to the main app screen; otherwise, it will send you back to the sign-in page [05:14].

Conclusion

Implementing screen protection is a crucial aspect of building secure and user-friendly React Native applications. By leveraging a SessionProvider and conditionally rendering your navigation stacks based on the user's authentication status, you can ensure that only authorized users can access the protected parts of your application. This simple yet powerful logic helps in maintaining the integrity and security of your mobile app.

You can check my application in this link DOWELL

Customizing Expo Router Tabs: Styling, Icons, and Hiding Screens

rogasper — Fri, 12 Dec 2025 13:57:32 +0000

When moving a web application to React Native, one of the first challenges is recreating a familiar, polished navigation experience. On the web, a bottom navigation bar is common, but how do you build a fully custom, stylish, and functional tab bar for a mobile app?

As I've been transforming my web app into a mobile app, I dived deep into Expo Router and its powerful file-based navigation system. In this guide, I'll walk you through the exact process I used to customize the default tab bar into a "floating" navigation bar with custom icons and specific active states, just like in my video.

We'll cover how to style the tab bar globally, set custom icons for each screen, and even hide specific screens from the tab bar.

The Foundation: Understanding Expo Router's Layouts

First, it's crucial to understand how Expo Router's file-based routing works. It's very similar to Next.js. Your file structure is your navigation.
My app has a protected route setup:

app/_layout.tsx: This is the root layout. It manages the main authentication state.
app/(app)/_layout.tsx: This is a Stack Navigator layout for all my authenticated screens. I use a Stack here to create a single, persistent custom header that appears on all screens inside this group.
app/(app)/(tabs)/_layout.tsx: This is the most important file for this guide. It's a nested layout file that creates the Tab Navigator. Any file inside the tab (tabs) directory (like index.tsx, history.tsx, etc.) will automatically become a tab.

Step 1: Global Tab Bar Styling with `screenOptions`

To change the look of the entire tab bar, you'll work inside app/(app)/(tabs)/_layout.tsx and add the screenOptions prop to the <Tabs> component.
Here's how I achieved the floating, icon-only look:

headerShown: false : Since I already have a custom header from my (app) Stack layout, I must hide the default header for the Tabs layout. This prevents a "double header" from appearing. `
tabBarShowLabel: false : This hides the default text labels under the icons, giving us a cleaner, icon-only navigation bar.
tabBarStyle: This prop lets you pass in a style object, just like in standard React Native. This is where I created the floating effect. Here's a conceptual look ath the tabBarStyle props:

`typescript
// In app/(app)/(tabs)/_layout.tsx
import { Tabs } from 'expo-router';

export default function TabsLayout() {
return (
screenOptions={{
headerShown: false,
tabBarShowLabel: false,
tabBarStyle: {
position: 'absolute', // Makes the tab bar float
bottom: 16,
left: 16,
right: 16,
borderRadius: 16,
height: 60,
backgroundColor: '#fff',
// Add box shadow or other styles
},
}}>
{/* Your components go here */}

);
}
`

Step 2: Customizing Individual Tab Screens (Icons & Titles)

Now that the bar is styled, we need to customize each button. You do this by adding the options prop to each <Tabs.Screen> component within your Tabs layout.
The most important option is tabBarIcon. This prop accepts a function that gives you properties like focused, color, and size.
Here's how you can render a custom icon and even change its style when it's focused (active):

`typescript
// In app/(app)/(tabs)/_layout.tsx
// ...inside the component

name="index" // This matches the file name index.tsx
options={{
title: 'Habit', // Sets the title (for accessibility, etc.)
tabBarIcon: ({ focused, size })Opening a new realm of possibilities with your smart device. }) => (
// Change background when focused
backgroundColor: focused ? '#your_highlight_color' : 'transparent',
padding: 8,
borderRadius: 10,
}}>
name="your-icon-name"
size={size}
color={focused ? '#fff' : '#000'}
/>

),
}}
/>
`
By using the focused prop, you get full control over the activate state of your tab icons, allowing for unique designs like a larger button for an "add" screen, as shown in the video.

Step 3: How to Hide a Screen from the Tab Bar

What if you have a screen inside your (tabs) directory that you need to navigate to, but you don't want it to appear in the tab bar? (For example, an "Edit Habit" screen).
Expo Router makes this simple. On the <Tabs.Screen> component for that file, you need to set the href option to null.

`typescript
// In app/(app)/(tabs)/_layout.tsx
// ...inside the component

name="edit-habit" // Matches edit-habit.tsx
options={{
// This is the key!
href: null,
}}
/>
`
Now, the edit-habit screen exists and can be navigated to (e.g., router.push('/edit-habit')), but it is completely hidden from the bottom tab bar.

Conclusion

Expo Router's file-based system is incredibly powerful once you understand its layout components. By using the screenOptions prop on <Tabs> for global styling and the options prop on <Tabs.Screen> for individual icon rendering and visibility, you can transform the default navigation into a fully custom, professional-looking tab bar that perfectly matches your app's design.

How to Create a Smooth, Infinite Tinder-Style Swipe Deck in React Native

rogasper — Fri, 12 Dec 2025 13:44:07 +0000

The Tinder-style swipe card UI is an iconic and intuitive pattern for mobile apps. Whether you're building a habit tracker, a to-do list, or social app, giving users the ability to "swipe" through items is incredibly engaging.
But while many libraries can help you create a basic swipe deck, two major problems quickly appear:

How do you make the deck infinite, so the cards loop back around?
How do you do it without lag or janky animations?

In this guide, based on my video Make Swipe Card like Tinder/Bumble Deck in React Native, I'll show you exact method I used to solve these problems using the rn-swiper-list library and a clever setTimeout trick.

The Stack: What We're Using

React Native
rn-swiper-list: The core library for the swipe deck.
React Query: for fetching our data (e..g., our list of habits).
Zustand: For simple state management.

The "Infinite Loop" Challenge

The first challenge is creating an infinite deck. When a user swipes the last card, we want the first card to reappear.
The logic I implemented is simple:

Our data is an array of habits, stored in a state.
When a card is swipped (e.g., onSwipedRight or onSwipedLeft), it's not removed.
Instead, we call a function (let's call it moveToEnd) that simply takes the first item in the array and moves it to the end of the array.
By passing a key prop to the swiper component (based on the data), this state update forces React to rerender the deck, effectively "looping" the cards.

The "Lag" Problem: Why Your Animation is Janky

Here's where 90% of developers get stuck.
You set up the logic above, and it works... but it looks terible. When you swipe, there's a noticeable lag or jank [09:00].
Why does this happen? The swipe animation itself has a duration. The rn-swiper-list library defaults to an animation of about 500ms [09:12]. Your code, however, is updating the state (moving the card in the array) immediately.
You are forcing a state update and rerender while the card's exit animation is still playing. The two are fighting each other, resulting in a laggy, unprofessional-looking animation.

The Solution: The 500ms `setTimeout` Trick

The fix is surprisingly simple, but critical for a smooth user experience.Do not update the state immediately. Wait for the animation to finish first.
Since we know the animation duration is 500ms, we wrap our state update function (moveToEnd) inside a setTimeout call with a 500ms delay.

const onSwipe = () => {
  // Don't do this:
  // moveToNextCard(); // THIS CAUSES LAG

  // DO THIS:
  setTimeout(() => {
    moveToNextCard(); // Or your state update
  }, 500); // 500ms matches the animation duration
};

return (
  <Swiper
    cards={habits}
    renderCard={(card) => <HabitCard card={card} />}
    onSwipedLeft={onSwipe}
    onSwipedRight={onSwipe}
    // ...other props
  />
);

By doing this [09:25], we let the card swipe off-screen completely. The animation finishes, and then the state updates silently in the background. The next card slides in, and the user experiences a perfectly smooth, seamless, and infinite loop.

Bonus Tip: Triggering Swipes from Inside the Card

What if you don't want external like or nope buttons? In my app, I wanted buttons inside the card itself to trigger the swipe.
You can achieve this by using a ref:

Create a ref in your component: const swiperRef = useRef(null);
Pass the ref to the swiper component: <Swiper ref={swiperRef} ../>
Pass the ref down to your child card component: <HabitCard card={card} swiperRef={swiperRef} />
Inside your HabitCard component, you can now add a Pressable button that calls the swiper's built-in methods:

// Inside your HabitCard component
<Pressable onPress={() => swiperRef.current.swipeLeft()}>
  <Text>Nope</Text>
</Pressable>

This gives you full control over the swipe deck, allowing you to build complex, custom UIs just like Tinder or Bumble.

How to Handle Media Queries in React Logic with a Custom Hook

rogasper — Thu, 11 Dec 2025 01:05:29 +0000

CSS Media Queries are fantastic for styling changing font sizes, padding, or grid layouts based on screen width.

But what happens when you need to change the logic or the structure of your application?

For example, on a Desktop, you might want a persistent Sidebar on the left. But on Mobile, that same sidebar needs to be a Sheet or a Modal that slides in when a button is clicked. You can't easily achieve this with just CSS display: none because the components function differently.

This is where we need Javascript Media Queries.

In this post, I'll share a lightweight custom hook, useMediaQuery, that allows you to detect screen sizes directly inside your React components.

The Problem with "CSS-Only" Hiding

A common mistake is rendering both the Mobile and Desktop components and hiding one using CSS.

{/* This is bad for performance! */}
<div className="hidden md:block"><DesktopSidebar /></div>
<div className="block md:hidden"><MobileSheet /></div>

This approach bloats your DOM because React still renders both components, running their effects and logic, even if the user can't see them.

The Solution: `useMediaQuery` Hook

By using the native window.matchMedia API inside a React hook, we can track the screen state efficiently.

Here is the hook code:

import { useEffect, useState } from "react";

export function useMediaQuery(query: string): boolean {
  const [matches, setMatches] = useState(false);

  useEffect(() => {
    const media = window.matchMedia(query);

    // Update state immediately if it doesn't match
    if (media.matches !== matches) {
      setMatches(media.matches);
    }

    // Listener for subsequent changes
    const listener = () => setMatches(media.matches);

    // Modern browsers use addEventListener for matchMedia
    media.addEventListener("change", listener);

    // Clean up the listener on unmount
    return () => media.removeEventListener("change", listener);
  }, [matches, query]);

  return matches;
}

How it works:

window.matchMedia(query): This browser API checks if the document matches the media query string (e.g., (max-width: 768px)).
useState: We store the result (true or false) in local state.
Event Listener: We listen for the change event. If the user resizes their browser window, the state updates automatically.

Real-World Example: Sidebar vs. Sheet

Now, let's look at how to use this hook to solve the "Sidebar vs. Sheet" problem. We want to render a completely different UI Structure depending on the device.

import { useMediaQuery } from "./hooks/use-media-query";

export function CourseSidebar({
  course,
  currentLessonId,
  onLessonSelect,
  collapsed = false,
  onToggle,
}: Props) {
  const [isSheetOpen, setIsSheetOpen] = useState(false);

  // Define your breakpoint here
  const isMobile = useMediaQuery("(max-width: 768px)");

  // 1. Render Mobile View (Sheet/Modal)
  if (isMobile) {
    return (
      <Sheet open={isSheetOpen} onOpenChange={setIsSheetOpen}>
        <SheetTrigger>
           <Button>Menu</Button>
        </SheetTrigger>
        <SheetContent>
           {/* Your Menu Items */}
        </SheetContent>
      </Sheet>
    );
  }

  // 2. Render Desktop View (Standard Sidebar)
  return (
    <div className={`border-r bg-gray-100 ${collapsed ? "w-16" : "w-64"}`}>
       {/* Your Menu Items */}
    </div>
  );
}

Why this is better

By using if (isMobile), we are performing Conditional Rendering.

If the user is on mobile, the Desktop div is never rendered to the DOM
If the user is on desktop, the Mobile Sheet code is ignored This keeps your application lighter and faster, and it prevents weird bugs where mobile event listeners might fire while in desktop view.

Summary

CSS is for styling; Javascript is for logic. When you need to change what is rendered based on the viewport, reach for window.matchMedia.
This simple useMediaQuery hook bridges the gap between your CSS breakpoints and your React component logic.

for more information you can visit my website

Fixing Better Auth in TanStack Start: How to Pass Headers in Server Functions

rogasper — Wed, 10 Dec 2025 13:35:59 +0000

If you are building a modern web application using TanStack Start and Better Auth, you might have hit a specific, frustrating wall.

You have your authentication set up, the client-side an active organization or updating a profile, the request fails or acts as if the user isn't logged in.

I recently spent hours debugging this exact issue while trying to implement an organization switcher. The solution is simple, but not immediately obvious if you are new to TanStack's server utilities: You need to manually forward the request headers.

The Problem: Missing Context

When you use Better Auth (or many other auth libraries), the server needs to know who is making the request. Usually, this information (session tokens or cookies) lives in the HTTP headeres.

In a standard client-side fetch, the browser handless cookies automatically. However, when you use a TanStack Start Server Function (createServerFn), you are running logic in an isolated server environment. If you make a call to your auth API from there without passing the original request's context, Better Auth sees an anonymous request.

The Solution: `getRequest`

To fix this, TanStack Start provides a utility called getRequest from @tanstack/react-start/server.
This allows you to access the incoming request object, extract the headers, and pass them along to Better Auth.

Here is the practical example that solved it for me. I wanted to create a server function to switch the user's active organization:

The code

import { getRequest } from "@tanstack/react-start/server";
import { createServerFn } from "@tanstack/start";
import { z } from "zod";
import { auth } from "./auth"; // Your Better Auth instance

export const switchOrganization = createServerFn().inputValidator(z.object({
    organizationId: z.string().min(1),
})).handler(async ({data}) => {
    // 1. Get the current request context
    const request = getRequest();

    // 2. Pass the headers to Better Auth
    const organization = await auth.api.setActiveOrganization({
        body: {
            organizationId: data.organizationId
        },
        // This is the magic line that makes auth work:
        headers: request.headers,
    })
    return organization;
})

Why This Works

getRequest(): This function retrives the standard Request object for the current server execution.
headers: request.headers: By passing these headers into the auth.api.setActiveOrganization configuration, you are forwading the user's session cookies. Better Auth can now read those cookies, validate the session, and confirm that the user actually has permission to switch organizations.

Summary

When working with Server Functions (RPCs) in TanStack Start, never assume the context is passed automatically to third-party libraries.If you are getting "Unauthorized" erros or weird behaviors on server-side mutations, check if you are forwading the headers. It's a small addition to your code, but it's the bridge that makes TanStack Start and Better Auth work seamlessly together.

for more information you can visit my website

DEV Community: rogasper

How to Deploy TanStack Start with Docker and Bun

0. The Prerequisite (Don't Skip This!)

1. The Foundation: Vite Configuration

2. The Secret Sauce: A Custom Bun Server

3. The Dockerfile: Small & Efficient

4. Orchestration: Docker Compose

Conclusion

Quick Recap:

How to Build a Secure Forgot Password Flow with OTP in Better Auth

The Backend Config

The Client-Side Implementation

1. The Logic Hooks

2. The UI Implementation

Magic Link vs. OTP: Which one should you choose?

The OTP Approach (This Guide)

The Magic Link Approach

Conclusion

How to Setup Email Verification & Organization Invites with Better Auth and Nodemailer

Step 1: Installation

Step 2: Setting Up the Email Transporter

Step 3: Configurating the Better Auth Server

Step 4: Environment Variables

Step 5: Frontend Implementation (Client Side)

Sign Up (Triggering Verification)

Sending an Invitation

Accepting an Invitation

Why This Architecture Works

Prevent React Native Timers from Stopping in Background: A Complete Guide

The Challenge: React Native vs. The OS

Step 1: Setup and Configuration

Android Configuration is Mandatory

Step 2: The State Synchronization Problem

The Solution: Imperative State Access

Step 3: The Background Task Function

Step 4: Triggering the Service from the UI

Key Takeaways for Implementation

Bridging the Gap: Implementing Better Auth with Non-Node Backends

So, what happens if your backend logic lives in Go (Fiber), but you want the DX of Better Auth for your TanStack Start frontend?

The Architecture

Step 1: Configuring Better Auth (The Frontend)

Step 2: The Proxy (Tanstack Start)

Step 3: Authorization in Go Fiber

Why This Architecture Works

Trade-offs to Consider

The Bottom Line

Conclusion

Safeguarding Your React Native App: Protecting Screens for Unauthorized Users

The Core Concept: Authorization Management

Step 1: The Root Layout and Session Provider

Step 2: Session Provider for State Management

Step 3: Implementing Protected Routes within the Root Navigator

Demonstration of the Workflow

Conclusion

Customizing Expo Router Tabs: Styling, Icons, and Hiding Screens

The Foundation: Understanding Expo Router's Layouts

Step 1: Global Tab Bar Styling with screenOptions

Step 2: Customizing Individual Tab Screens (Icons & Titles)

Step 3: How to Hide a Screen from the Tab Bar

Conclusion

How to Create a Smooth, Infinite Tinder-Style Swipe Deck in React Native

The Stack: What We're Using

The "Infinite Loop" Challenge

The "Lag" Problem: Why Your Animation is Janky

The Solution: The 500ms setTimeout Trick

Bonus Tip: Triggering Swipes from Inside the Card

How to Handle Media Queries in React Logic with a Custom Hook

The Problem with "CSS-Only" Hiding

The Solution: useMediaQuery Hook

How it works:

Real-World Example: Sidebar vs. Sheet

Why this is better

Summary

Fixing Better Auth in TanStack Start: How to Pass Headers in Server Functions

The Problem: Missing Context

The Solution: getRequest

The code

Why This Works

Summary

Step 1: Global Tab Bar Styling with `screenOptions`

The Solution: The 500ms `setTimeout` Trick

The Solution: `useMediaQuery` Hook

The Solution: `getRequest`