<ForrigeUke uke="36" år="2026" />
Slutt på hydreringsfeil, agent-vennlig styling og kjærlighet mellom TanStack og Vercel - i denne ukas ForrigeUke.
Dette var uka for kraftig komprimering og trafikklys-drevet-utvikling - og 1108 ting som skjedde i frontendverdenen!
«<ForrigeUke /> er en artikkelserie som oppsummerer hva som skjedde i frontend-verden i uka som var.»
Nytt API i React: browser ✨
I kommende React-versjon 19.3 kommer et nytt API som lar deg markere en komponent som browser-only. Dette er nyttig ved server-rendring, hvor du kjører kode først på serveren og så i nettleser.
Server-rendring kan være utfordrende når du vil kjøre funksjoner som bare fungerer i nettleser, som localStorage.getItem(). Gamlemåten har vært å sjekke for om window eksisterer. Om window ikke fins, vet du at du er på serveren, og unngår å kjøre nettleser-kode på serveren.
Men nå kommer altså React med en mer eksplisitt funksjon:
import { use, useState } from 'react';
import { browser } from 'react-dom';
export function SavedDraft() {
// 👇 Komponenten blir ikke vist utenfor en nettleser
use(browser('The saved draft is stored in localStorage.'));
const [draft] = useState(() => localStorage.getItem('draft') ?? '');
return <DraftEditor initialDraft={draft} />;
}For å bruke browser-API-et må komponenten være en klientkomponent innen en Suspense-grense. Det er use(), som vi ser over, som leser av verdien og aktiverer Suspense-grensen.
Ved å bruke en Suspense-grense har vi også fordelen av å vise en fallback frem til komponenten er klar i nettleseren:
// SavedDraft.tsx
'use client';
// ☝️ Marker komponenten som klientkomponent
export function SavedDraft() {
//...
}
// App.tsx
export function App() {
return (
{/*
👇 Komponenten må være inni en Suspense-grense
*/}
<Suspense fallback={<p>Loading draft...</p>}>
<SavedDraft />
</Suspense>
);
}browser-API-et er fortsatt i eksperimentell versjon (canary), men snart får vi kanskje mer forutsigbarhet mellom klient og server:

AI-vennlig alternativ til CSS 🎨
Idet jeg trodde styling-diskusjonen var død, har et annet CSS-verktøy dukket opp: Meta sitt StyleX. Det har fått fart nå etter Cursor skrev om fra Tailwind til StyleX og at Meta selv har opensourcet designsystemet Astryx. StyleX legger enda tydeligere begrensninger på hvordan styling skrives, noe som kan gjøre at kodeagentene forstår koden bedre.
La oss sammenligne med noen kodeeksempler, først med Tailwind:
<button
className="rounded-full bg-emerald-700 px-4 py-2
text-white hover:bg-emerald-800
sm:px-5"
>
Lagre
</button>Og her med StyleX, hvor du definerer et stil-objekt:
const styles = stylex.create({
button: {
borderRadius: 999,
backgroundColor: {
default: '#0f8b6d',
':hover': '#0b6b54',
},
paddingInline: {
default: 16,
'@media (min-width: 40rem)': 20,
},
paddingBlock: 8,
color: 'white',
},
})
<button {...stylex.props(styles.button)}>
Lagre
</button>StyleX skiller seg ut fra andre stylingverktøy. CSS Modules, som har vært min preferanse, har en deilig enkelhet og nærhet til vanlig CSS, bare med klassenavn som er lokale til CSS-filen. Tailwind, som fikk medvind etter at agent-produsert kode kom på banen, har en stylingmodell med forhåndsdefinerte klasser som har stort sett samme spesifisitet.
StyleX strammer inn stylingen ytterligere ved å definere stylingen som JavaScript-objekter. Objektformatet og kompileringen gjør konflikter mer forutsigbare, i stedet for at CSS-kaskader fra andre deler av appen plutselig blander seg inn.
Innstrammingen skal være en fordel i større applikasjoner og designsystemer, men skal også være nyttig når du jobber med agenter. En agent kan lettere forholde seg til eksplisitt styling og JavaScript-logikk i én komponent enn til CSS-regler som er spredt rundt i applikasjonen. Lovordene er fristende, så det blir spennende å se om StyleX blir det neste store stylingverktøyet vi blir å bruke.
Om du er nysgjerrig på hvordan StyleX egentlig fungerer, ta en titt på dypdykket i denne bloggposten:

A deep dive into StyleX
Learn how StyleX turns JavaScript style objects into regular CSS classes at build time, with React and Astro setup, variants, themes, and ...
TanStack + Vercel = sant ❤️
Jeg må visst slutte å kalle TanStack Start “konkurrenten” til Next.js, for nå har nemlig Vercel gått inn som gullpartner for TanStack.
Dette har de feira ved å lage en guide for hvordan du kan deploye TanStack Start til Vercel:

How to Deploy a TanStack Start app to Vercel | Vercel Knowledge Base
Deploy a TanStack Start app to Vercel with the Nitro Vite plugin. Covers Git and CLI deployment, Fluid compute defaults, and framework detection ...
Med en gratisplan som har vært nok for meg, har Vercel vært min go-to plattform å deploye til når det kommer til hobbyprosjekter. Samtidig har jeg hørt det har vært trøblete for annet enn Next.js-applikasjoner. Dermed er det gledelig at Vercel nå skal gi et førsteklasses hjem for TanStack Start.
Det er nå få steg som skal til for å deploye TanStack Start til Vercel. Du trenger stort sett bare å legge til Nitro Vite-plugin, som gir Vite-appen serverfunksjonaliteten den trenger, som SSR og middleware:
// vite.config.ts
import { nitro } from "nitro/vite";
export default defineConfig({
plugins: [tanstackStart(), nitro(), viteReact()],
});For fem år siden ansatte Vercel Svelte-skaper Rich Harris, slik at han kunne jobbe fulltid med Svelte. Forhåpentligvis gir partnerskapet med TanStack den samme effekten: mindre tid på sponsorjakt og mer tid til å videreutvikle verktøyene. TanStack Start, også etter partnerskapet, fortsetter å være et alternativ til Next.js. Men TanStack har også en hel haug med andre verktøy som begge parter kan dra nytte av.

👋 Det var alt for denne gang. Ha en riktig fin uke!
