DEV Community: Sensational-DEV

I rewrote 3 useEffects to use() in React 19. Here's the one I shouldn't have.

Sensational-DEV — Mon, 08 Jun 2026 06:53:41 +0000

The first time use() clicked for me, I closed the tab on the React docs and immediately went through my codebase looking for useEffect calls to delete.

Three rewrites later, I reverted one. Here's what I learned about when use() is the right tool — and when reaching for it is the wrong instinct.

The setup

use() in React 19 lets you read the value of a promise inside a component. The component suspends while the promise resolves, and React handles the rest:

function UserCard({ userPromise }: { userPromise: Promise<User> }) {
  const user = use(userPromise);
  return <div>{user.name}</div>;
}

No useEffect. No useState. No if (loading) return <Spinner />. The component reads the value as if it were synchronous, and Suspense handles the loading state from a parent boundary.

It's beautiful. It's also not a drop-in replacement for every useEffect you've written.

Rewrite 1: the obvious win

This was the kind of pattern use() was designed for. A server component fetches data, passes the promise (not the awaited value) to a client component, and that component reads it:

// app/users/[id]/page.tsx (server component)
export default async function Page({ params }) {
  const userPromise = fetchUser(params.id); // not awaited
  return <UserCard userPromise={userPromise} />;
}

// UserCard.tsx (client component)
'use client';
import { use } from 'react';

export function UserCard({ userPromise }) {
  const user = use(userPromise);
  return <h1>{user.name}</h1>;
}

The parent server component starts the fetch and ships the promise. The client component reads it. There's a Suspense boundary somewhere above that handles the loading state.

The entire useState + useEffect + setUser dance I'd written for the old version evaporated. 18 lines down to 4. Lossless.

Rewrite 2: the slightly less obvious win

The second was for a config object that came from a context provider. The context's value was itself a promise (resolved lazily so the bundle didn't ship a megabyte of config), and consumers had been awkwardly awaiting it inside useEffect:

// Before
function Feature() {
  const configPromise = useContext(ConfigContext);
  const [config, setConfig] = useState<Config | null>(null);

  useEffect(() => {
    configPromise.then(setConfig);
  }, [configPromise]);

  if (!config) return null;
  return <RealFeature config={config} />;
}

// After
function Feature() {
  const configPromise = useContext(ConfigContext);
  const config = use(configPromise);
  return <RealFeature config={config} />;
}

use() works seamlessly with context — pass a promise through context, read the value with use() anywhere downstream. The component naturally suspends until the promise resolves.

Four lines. The if (!config) return null early return is gone, which means downstream types stop being Config | null and start being Config. Type-level win on top of the code-level win.

Rewrite 3: the one I reverted

Flush with confidence, I went after a useEffect that polled a status endpoint every 5 seconds:

// Before
function JobStatus({ jobId }) {
  const [status, setStatus] = useState<Status>('pending');

  useEffect(() => {
    let cancelled = false;
    const tick = async () => {
      const next = await fetchJobStatus(jobId);
      if (!cancelled) setStatus(next);
      if (!cancelled && next === 'pending') {
        setTimeout(tick, 5000);
      }
    };
    tick();
    return () => { cancelled = true; };
  }, [jobId]);

  return <StatusPill status={status} />;
}

My first attempt was to wrap each poll in a promise and read it with use(). It "worked" for the first fetch. Then I needed to re-poll. And cancel on unmount. And re-trigger when jobId changed.

Within 20 minutes I had reinvented useEffect poorly — a custom hook that kept track of the current promise, swapped it for a new one on each interval, and tore everything down on unmount. The code was longer, less readable, and had subtle bugs around the cleanup path.

I reverted. The useEffect version was correct and obvious.

The rule I derived

use() is for promises that resolve once and don't need cancellation.

That's it. That's the rule.

Server-component-to-client-component data handoff: one resolution, never cancelled. ✅
Lazy context value: one resolution, never cancelled. ✅
Polling, websockets, subscriptions, debounced search: multiple resolutions, may need cancellation. ❌

The ones in the ❌ column still want useEffect — or a purpose-built hook like SWR or TanStack Query for the network-y ones. use() doesn't have a cancellation API because it isn't trying to be one. It's a primitive for reading, not for managing.

The meta lesson

New React features land and they look like silver bullets for ten minutes. They're not. They're sharp tools with narrow blades.

The time to reach for use() is when you have a single promise sitting in the right place at the right time and you're tired of writing 18 lines of state-and-effect glue to read it. The time to not reach for use() is when you've got lifecycle work — polling, subscriptions, cancellation, anything that lives over time.

Learn the shape of each new primitive. Don't refactor at scale until you've shipped one example end-to-end. And keep a git revert in your pocket — you'll need it the day after you discover something new.

If this helped, you can buy me a coffee. It keeps the writing coming.

3 TypeScript patterns I keep stealing from open-source codebases

Sensational-DEV — Mon, 08 Jun 2026 05:53:04 +0000

Every few months I find a TypeScript pattern in someone's open-source repo that I instantly bring back to my own code. It's the cheapest form of getting better — read code that's been read by hundreds of contributors and find the patterns that survived.

Here are three I keep reaching for in 2026.

1. `satisfies` for catch-typos-at-compile-time configs

You know the routine — a config object that holds, say, all your route paths, or all your event names. You want autocomplete when you reference one, but you also want TS to scream if you fat-finger a key.

The old way:

type RouteKey = 'home' | 'blog' | 'profile';
type Routes = Record<RouteKey, string>;

export const routes: Routes = {
  home: '/',
  blog: '/blog',
  profile: '/profile',
};

routes.home; // type is `string` — autocomplete works, but you lose the literal

The satisfies way:

export const routes = {
  home: '/',
  blog: '/blog',
  profile: '/profile',
} satisfies Record<string, string>;

routes.home; // type is the literal '/', not just string

satisfies checks the shape but preserves the specific inferred types of every key and value. If I refer to routes.home, TS knows the value is '/', not just string. Useful when those literals drive other types downstream:

type Path = (typeof routes)[keyof typeof routes];
// Path is '/' | '/blog' | '/profile' — not string

I stole this from a Remix codebase last year. It's in every project I touch now.

2. Branded types to stop ID confusion

Ever passed userId where postId was expected? TypeScript won't catch it, because both are strings.

function getUser(id: string) { /* ... */ }
function getPost(id: string) { /* ... */ }

const userId = 'u_abc';
const postId = 'p_xyz';

getUser(postId); // no error — the bug ships

Brand them and the bug becomes unrepresentable:

type Brand<T, B> = T & { __brand: B };

type UserId = Brand<string, 'UserId'>;
type PostId = Brand<string, 'PostId'>;

function asUserId(s: string): UserId { return s as UserId; }
function asPostId(s: string): PostId { return s as PostId; }

function getUser(id: UserId) { /* ... */ }
function getPost(id: PostId) { /* ... */ }

const userId = asUserId('u_abc');
const postId = asPostId('p_xyz');

getUser(postId); // Error: 'PostId' is not assignable to 'UserId'

The branding is a zero-cost lie — UserId is really just string at runtime — but the compiler treats them as different types. The asUserId helper is the only blessed entry point, so all the unsafe casting happens in one place you can audit.

I picked this up from a fintech repo where mixing up OrderId and TradeId would have been a five-figure mistake. For a side project it's overkill. For anything touching money or user data, I reach for it instantly.

3. Discriminated unions with a `kind` field

This isn't new, but I use it more than any other pattern on this list, so it belongs.

State that can be in one of several modes — loading / success / error, draft / published / archived, free / pro / enterprise — should be a discriminated union, not three optional booleans.

The painful way:

interface FetchState<T> {
  data?: T;
  error?: string;
  isLoading?: boolean;
}

if (state.data) {
  // might still be loading? unclear
  // might have a stale error? also unclear
}

The clean way:

type FetchState<T> =
  | { kind: 'idle' }
  | { kind: 'loading' }
  | { kind: 'success'; data: T }
  | { kind: 'error'; error: string };

function render(state: FetchState<User>) {
  switch (state.kind) {
    case 'idle':    return null;
    case 'loading': return <Spinner />;
    case 'success': return <Profile user={state.data} />;     // data is typed
    case 'error':   return <ErrorMessage msg={state.error} />; // error is typed
  }
}

Inside each case block, TS narrows the type for you. state.data exists in 'success' and nowhere else. You can't accidentally read it from 'loading' because it isn't on that variant.

The kind field name is convention. Some teams use type, some use status. Pick one, use it everywhere — switching the discriminator name across files makes every code review harder than it needs to be.

What I'd skip

Decorator-heavy patterns. Stage-3 decorators are stable in TS 5+, but every project I've used them in eventually hit a corner where they didn't compose well with the framework's lifecycle. I've gone back to plain functions and higher-order helpers and never missed the magic.

The meta lesson

Reading open-source isn't just for inspiration. It's professional development without the bootcamp tuition. Every pattern in this list survived hundreds of contributors making small calls — that's a stronger filter than my own taste alone.

If you haven't already, pick one TypeScript codebase you admire and read 30 minutes of source this week. Try to spot a pattern you don't already use. Steal it. Use it on Monday.

That's how you get better — one stolen pattern at a time.

If this helped, you can buy me a coffee. It keeps the writing coming.

5 Tailwind v4 features I wish I'd known earlier

Sensational-DEV — Sat, 06 Jun 2026 16:41:24 +0000

I migrated a project to Tailwind v4 last week. The first hour was disorienting — half of what I knew didn't apply. Two days in, I'm faster than I was on v3.

These are the five features that made the difference.

1. `@theme` is the new config

In v3, every theme value lived in a JavaScript object inside tailwind.config.js. Custom colors, fonts, radii — all there.

In v4, the config moved into your CSS:

@import "tailwindcss";

@theme {
  --color-background: #0a0a0a;
  --color-foreground: #fafafa;
  --color-accent: #06b6d4;
  --font-sans: "Inter", system-ui, sans-serif;
}

These become real CSS custom properties. --color-accent works in two places at once: in raw CSS (color: var(--color-accent)) and in Tailwind classes (bg-accent, text-accent).

I don't miss tailwind.config.js.

2. `@custom-variant` for class-based dark mode

Built-in dark mode in v4 keys off the prefers-color-scheme media query. If you want class-based dark mode (so users can toggle themes manually), v3 had a config option. V4 wants this:

@custom-variant dark (&:where(.dark, .dark *));

Then everywhere in your code, dark:bg-card activates when .dark class is on <html>. Pair it with a CSS override block:

.dark {
  --color-background: #0a0a0a;
  --color-foreground: #fafafa;
}

Toggle by adding/removing the class. No more config-file dance.

3. `color-mix()` for accent-aware effects

This isn't strictly a Tailwind feature — it's CSS — but Tailwind v4 made it feel native by encouraging CSS-first variables.

The use case: a glow effect that tracks your accent color, regardless of theme.

.glow {
  box-shadow:
    0 6px 20px -6px color-mix(in srgb, var(--color-accent) 55%, transparent);
}

Change --color-accent, the glow color follows. Change theme (dark to light), the glow stays accent-aware. One declaration, two-mode behavior.

I use this everywhere — buttons, cards, focus rings. It's a tiny detail that polishes a whole UI.

4. Container queries without a plugin

In v3, @tailwindcss/container-queries was a plugin you installed. In v4, container queries are built in.

<div className="@container">
  <div className="grid grid-cols-1 @md:grid-cols-2 @lg:grid-cols-3">
    {/* responds to container width, not viewport */}
  </div>
</div>

The grid switches columns based on the parent's width, not the window. If you've ever built a dashboard widget that's used at different sizes in different layouts, this is the cleanest solution I've found.

5. CSS-first config means less plumbing

I had a folder for Tailwind plugin configs in v3 projects. In v4 it doesn't exist.

Want a custom utility?

@utility container-tight {
  max-width: 36rem;
  margin-inline: auto;
}

Use it: <div className="container-tight">.

Want a custom variant?

@custom-variant hocus (&:hover, &:focus);

Use it: <button className="hocus:bg-accent">.

No more plugin(function({ addUtilities, addVariant }) { … }). The mental model collapses into "CSS with extra rules", which is what Tailwind probably should have been all along.

What I'd skip

Honestly, the @apply directive. It exists, it works, but I find that with CSS variables driving everything, I reach for it less. Direct class composition wins for clarity 80% of the time, and the other 20% I reach for @layer components { … }.

Migration tip

The official upgrade tool (npx @tailwindcss/upgrade@latest) handles 90% of the rewrite. The 10% it doesn't: dark-mode setup (you have to choose: media query or class), and any custom plugins (rewrite them as @utility or @custom-variant).

I spent 30 minutes on the upgrade tool, then another 90 minutes on manual cleanup. Net result: less code, the same UI, and a project that's easier to onboard.

If you've been holding off because v3 works fine — try v4 on a small project first. The mental shift is real, but it's a one-time cost and the daily ergonomics are worth it.

One last thing

The biggest win I didn't expect: @theme makes design tokens visible. In v3 they lived inside a JS object that nobody on the team looked at. In v4 they're at the top of your globals.css, next to the imports. New contributors find them in their first 30 seconds in the file.

That's not a Tailwind feature. That's a CSS architecture decision that v4 quietly forces on you. And it's a good one.

If this helped, you can buy me a coffee. It keeps the writing coming.

I gave Claude an API to post to my dev blog (and the bcrypt hash broke in 2 different places)

Sensational-DEV — Fri, 05 Jun 2026 10:05:14 +0000

It started with a side project: a personal blog. I wanted somewhere to write that wasn't a hosted platform, with the dark-mode-by-default and the URL structure and the editor I'd been craving.

Then halfway through building it, a thought:

What if I could just tell Claude "publish a post about X" and it actually shows up on my blog?

48 hours later, here we are.

The mental model

There are two ways to write on the blog:

Web admin — a split-view markdown editor with live preview, behind HTTP Basic Auth
API endpoint — POST /api/ai/posts with an X-API-Key header

Path #2 is the new thing. The key idea: every Claude Code session I run from the terminal already has the API key in my env. So I can just do:

curl -X POST http://localhost:3210/api/ai/posts \
  -H "X-API-Key: $BLOG_AI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"title":"...","body_markdown":"...","status":"draft"}'

And a draft (or published post) appears on the blog. No browser. No copy-paste.

The stack

Next.js 16 (App Router) + React 19 + TypeScript
Tailwind v4 (dark-first)
File-based JSON store (will swap to Postgres later)
Bcrypt for the API key
Zod for input validation

I'm intentionally not using a database yet. A .data/posts.json file works fine while I'm the only writer. Trading 30 lines of complexity for "I'll migrate when it matters."

The endpoint

The handler lives at app/api/ai/posts/route.ts. It exports four functions for four verbs:

export async function GET(req)    { /* list */ }
export async function POST(req)   { /* create */ }
export async function PUT(req)    { /* update */ }
export async function DELETE(req) { /* delete */ }

The shared first step in each is auth:

async function requireAuth(req: NextRequest) {
  if (!apiKeyConfigured()) {
    return jsonError(503, "API key not configured");
  }
  const ok = await verifyApiKey(req.headers.get("x-api-key"));
  if (!ok) return jsonError(401, "Invalid or missing X-API-Key");
  return null;
}

Then the verb-specific logic does the obvious thing — parse JSON, validate with zod, call the store, return JSON back.

The clever bit is in the store: when Claude POSTs a new post, the slug is auto-generated from the title. If that slug is taken, it appends -2, -3, etc. So Claude can call POST repeatedly with similar titles without worrying about collisions.

The bcrypt gotcha (and the second one I didn't see coming)

This took me 30 minutes to figure out and I want it documented somewhere so I never fall for it again.

I generated an API key, hashed it with bcryptjs, dropped both into .env.local:

BLOG_AI_API_KEY_HASH="$2b$10$yNATBgF..."

Restarted the server. Called the endpoint. Got 503: API key not configured.

That's the error I throw when process.env.BLOG_AI_API_KEY_HASH is undefined.

But the env file has it. What gives?

Turns out Next.js's @next/env loader does variable expansion inside double-quoted values. Bcrypt hashes start with $2b$10$ and contain more $ characters. The loader sees $2b, $10 — those look like variable references to it. They don't exist as actual env vars, so they expand to empty strings, and your hash collapses to garbage.

I tried single quotes:

BLOG_AI_API_KEY_HASH='$2b$10$yNATBgF...'

Same problem. Next.js's loader doesn't respect single-quoting the same way standard dotenv does — that's the second gotcha. In a vanilla dotenv.config() call, single quotes prevent expansion. In Next.js they don't.

Two fixes that actually work:

Escape the dollars: BLOG_AI_API_KEY_HASH="\$2b\$10\$..."
Skip the hash for local dev: store the raw key in BLOG_AI_API_KEY, do a constant-time string compare. The .env.local is gitignored anyway.

I went with option 2 locally and option 1 (via Vercel's env-var UI, which doesn't interpret $) in production. The verifier is bilingual:

export async function verifyApiKey(rawKey: string | null) {
  if (!rawKey) return false;
  const hash = process.env.BLOG_AI_API_KEY_HASH;
  if (hash) return bcrypt.compare(rawKey, hash);
  const raw = process.env.BLOG_AI_API_KEY;
  if (raw) return timingSafeEqual(rawKey, raw);
  return false;
}

Prefers the hash. Falls back to raw. Works everywhere.

How I actually use it

Honestly, the most common use case so far is during the writing loop itself. I'll be in the terminal with Claude Code, talking through an idea. When it's good, I ask Claude to draft it and POST it as a draft. Then I open the admin in my browser and finish it in the split-view editor.

That's the whole thing: AI handles the rough cut, I handle the edit. Same as code review, but for prose.

The other surprisingly nice flow is updates. Halfway through writing a post I'll realize I want a fourth section. I describe it. Claude PUTs the update. I refresh the editor — there it is. The AI is operating inside my draft, not next to it.

What's next

Dev.to cross-posting: a button in the editor that POSTs to Dev.to with canonical_url pointing back to my blog. SEO win.
Migrating to Postgres: when the file store becomes annoying — probably around 50 posts.
An /api/ai/profile endpoint: so I can update the about page from Claude too. Right now I have to edit a JSON file or use the UI.
Image upload via API: so Claude can attach a cover image without me having to upload it separately.

Try it yourself

The architecture is uncomplicated enough to lift in an afternoon:

Next.js 16 API route with zod validation
Bcrypt-or-raw key check (mind the dollar signs)
JSON file or DB on the back

If you build something similar — or if you've found a saner way to handle bcrypt hashes in .env — I want to hear about it. The comments are open.

If this helped, you can buy me a coffee. It keeps the writing coming.

5 AI Tools I Use Every Day as a Developer in 2026 (And 3 I Quit)

Sensational-DEV — Thu, 04 Jun 2026 16:28:28 +0000

It's 2026, and if you're still coding the way you did in 2023, you're working twice as hard for half the output.

I'm a frontend developer, and over the past year I've tested over 30 AI tools. Some saved me 10+ hours a week. Others were just hype.

Here's my honest stack — what stayed, what got cut, and why.

✅ The 5 I Use Every Single Day

1. Claude Code (Anthropic)

This is my main driver. Not ChatGPT, not Copilot — Claude Code.

Why? It actually understands my codebase. I can say "refactor this component to use the new design system" and it reads the right files, makes the changes, runs the tests. No copy-paste loop.

Best for: Real refactoring, multi-file changes, debugging gnarly bugs.

2. Cursor

When I need to stay in an IDE with full visual control, Cursor is still king. The Tab autocomplete alone is worth the $20/month.

I use Cursor for quick edits, Claude Code for big tasks. They're not competitors — they're a combo.

3. v0 by Vercel

I stopped designing UI in Figma for prototypes. Type a prompt → get a working React component with shadcn/ui. Ship to production in minutes.

Best for: Landing pages, dashboards, internal tools.

4. Perplexity

Google is dead to me for technical research. Perplexity gives me sourced answers with citations. When I'm debugging a library issue, this finds the GitHub issue + Stack Overflow thread + docs in one shot.

5. Raycast AI

A keystroke away from anywhere on macOS. I use it for quick translations, regex generation, and rubber-duck conversations while coding.

❌ The 3 I Quit

1. GitHub Copilot

Once Cursor's Tab model launched, Copilot felt slow and dumb. I cancelled my subscription 4 months ago and haven't missed it once.

2. ChatGPT (for coding)

Still great for writing, but for code? Claude 4.7 is on another level. Better at long context, fewer hallucinated APIs.

3. Generic "AI website builders"

Tools like Framer AI, Wix AI — they look magical for 5 minutes, then you hit a wall. Real projects need real code. Stick to v0 + Cursor.

The Real Lesson

The winner of 2026 isn't the developer who knows the most frameworks. It's the developer who builds the best workflow around AI.

Pick 2-3 tools. Get fast with them. Ignore the rest.

What's in your stack? Drop it in the comments — I'm always looking to optimize.

If this helped, follow me for more honest dev tool reviews. No sponsorships, just what actually works.

If this helped, you can buy me a coffee. It keeps the writing coming.

DEV Community: Sensational-DEV

I rewrote 3 useEffects to use() in React 19. Here's the one I shouldn't have.

The setup

Rewrite 1: the obvious win

Rewrite 2: the slightly less obvious win

Rewrite 3: the one I reverted

The rule I derived

The meta lesson

3 TypeScript patterns I keep stealing from open-source codebases

1. satisfies for catch-typos-at-compile-time configs

2. Branded types to stop ID confusion

3. Discriminated unions with a kind field

What I'd skip

The meta lesson

5 Tailwind v4 features I wish I'd known earlier

1. @theme is the new config

2. @custom-variant for class-based dark mode

3. color-mix() for accent-aware effects

4. Container queries without a plugin

5. CSS-first config means less plumbing

What I'd skip

Migration tip

One last thing

I gave Claude an API to post to my dev blog (and the bcrypt hash broke in 2 different places)

The mental model

The stack

The endpoint

The bcrypt gotcha (and the second one I didn't see coming)

How I actually use it

What's next

Try it yourself

5 AI Tools I Use Every Day as a Developer in 2026 (And 3 I Quit)

✅ The 5 I Use Every Single Day

1. Claude Code (Anthropic)

2. Cursor

3. v0 by Vercel

4. Perplexity

5. Raycast AI

❌ The 3 I Quit

1. GitHub Copilot

2. ChatGPT (for coding)

3. Generic "AI website builders"

The Real Lesson

1. `satisfies` for catch-typos-at-compile-time configs

3. Discriminated unions with a `kind` field

1. `@theme` is the new config

2. `@custom-variant` for class-based dark mode

3. `color-mix()` for accent-aware effects