Salut !
Bienvenue dans ce deuxième numéro de React Radar.
On a pas mal de choses à voir cette semaine : React continue de simplifier l’intégration des Server Components, React Router prépare la suite, Vite avance sur Rolldown, Vitest 5 commence à montrer ce qu’il faudra migrer, et TanStack pousse encore son modèle multi-framework.
Alors, commençons sans plus attendre !
React 19 continue de stabiliser les Server Components
Plusieurs patchs ont été publiés sur les branches 19.0, 19.1 et 19.2; et le plus intéressant c’est côté typage et performance des Server Components.
Si vous utilisez déjà Next.js avec RSC ou des Server Actions, ces patchs méritent d’être suivis.
Dans ce modèle, React se concentre sur la frontière serveur/client, la sérialisation des données, l’exécution côté serveur et le streaming.
Par exemple :
export default async function ProductPage() {
const product = await getProduct()
return <ProductDetails product={product} />
}
Ce code paraît simple. Pourtant, React doit décider de ce qui reste sur le serveur, ce qui est transmis au client, comment les props sont sérialisées, et comment le rendu est envoyé au navigateur.
Concrètement, les patchs autour des Server Components améliorent surtout les types et certains chemins d’exécution.
React Router 7.15.0 prépare la suite
React Router 7.15.0 est sorti cette semaine. La release continue le travail de stabilisation avant la v8, avec des ajustements sur les APIs et des optimisations autour du route matching dans les modes Framework et Data.
C’est intéressant parce que React Router ne se limite plus à associer une URL à un composant. Dans les derniers modes, il porte une partie du modèle applicatif : chargement de données, mutations, erreurs, états de navigation et structure des routes.
Par exemple :
export async function loader({ params }) {
return getInvoice(params.invoiceId)
}
export default function InvoicePage({ loaderData }) {
return <InvoiceDetails invoice={loaderData} />
}
La route, en plus de faire apparaître une page, décrit comment la donnée arrive à l’écran.
Ce changement est important. Quand le router gère le data loading et les transitions, il devient une vraie décision d’architecture. Il influence l’organisation des fichiers, le découpage des features, la gestion d’erreur, et parfois même la façon dont on pense les mutations.
Si vous utilisez React Router 7 en mode Framework ou Data, lisez le changelog avant l’upgrade. Si votre app tourne sur Next.js App Router, le sujet reste intéressant pour comprendre ce qui se construit hors Next.
Vite 8.0.11 avance encore sur Rolldown
Vite 8.0.11 est sorti avec une mise à jour de Rolldown.
Le point à suivre ici, c’est la trajectoire du build. Vite continue de préparer son futur moteur, et ce mouvement concerne beaucoup plus que les apps Vite directes.
Aujourd’hui, Vite est dans énormément de stacks : apps React, Vue, Svelte, Vitest, Storybook, starters internes, libs partagées, design systems. Quand Vite modifie son socle de build, l’impact finit souvent par remonter dans les plugins, les monorepos et les intégrations custom.
Exemple classique :
export default defineConfig({
plugins: [
react(),
myInternalPlugin(),
],
resolve: {
alias: {
"@app": "/src",
"@ui": "/packages/ui/src",
},
},
})
Ce genre de config repose sur plusieurs couches : résolution d’aliases, plugins, transformation de modules, ordre d’exécution, compatibilité avec le bundler.
Pour une app simple, il n’y a rien à changer. Pour une stack avec plugins internes, monorepo, alias complexes ou build partagé entre plusieurs packages, les prochaines releases Vite méritent d’être suivies.
Vitest 5 commence à montrer les migrations à venir
Vitest 5.0.0-beta.2 est sorti avec plusieurs breaking changes.
Les changements touchent notamment les attachments, la suppression d’APIs dépréciées, et certains ajustements sur l’exécution des tests. C’est exactement le type de release à lire tôt si Vitest est central dans votre stack.
Une migration de test runner reste rarement uniquement côté config, et remonte très vite dans les helpers de test, les mocks globaux, les setups partagés et les conventions installées dans le projet.
Par exemple :
export function renderWithProviders(ui) {
return render(
<QueryClientProvider client={client}>
<MemoryRouter>
{ui}
</MemoryRouter>
</QueryClientProvider>
)
}
Ce genre de helper finit souvent utilisé partout : tests de pages, composants, hooks, providers, flows métiers. Quand le runner change son comportement d’exécution, les fichiers comme celui-ci deviennent les premiers endroits à vérifier.
Même chose pour les mocks globaux :
vi.mock("@/services/api", () => ({
getUser: vi.fn(),
updateUser: vi.fn(),
}))
Si votre suite dépend beaucoup de mocks partagés, de setup files ou de conventions, les breaking changes de Vitest 5 méritent d’être lus pour éviter de découvrir le sujet le jour où la stable arrive.
En général, pour une petite suite de tests, on s’en tient à la version stable. Mais pour des gros tests Vitest, mieux vaut anticiper en listant les APIs dépréciées et les helpers à vérifier.
TanStack Table v9 alpha continue son chemin
TanStack Table 9 avance encore en alpha. Le point intéressant cette semaine, c’est le support d’un external reactivity binding.
L’idée derrière est claire : TanStack continue de construire ses libs comme des moteurs indépendants, avec des bindings adaptés à chaque framework.
Le cœur reste générique : React, Solid, Vue ou d’autres frameworks branchent ensuite leur propre modèle de réactivité.
Mentalement, ça ressemble à ça :
const table = createTable({
data,
columns,
state,
})
Puis le framework s’occupe de connecter ce moteur à son système de rendu : hooks côté React, signals côté Solid, réactivité côté Vue.
Pour une app React classique, la v8 reste le choix stable. Pour une équipe qui construit des composants internes, un design system ou une lib de table partagée, cette direction est importante.
Pour décider, il faut se poser la bonne question : est-ce que votre table est un composant React, ou est-ce que c’est un moteur métier affiché avec React ?
Dans une table simple, la question ne change pas grand-chose. Dans une grille avec colonnes dynamiques, filtres persistés, sélection massive, virtualisation, édition inline et permissions métier, ça change tout !
Si vous utilisez TanStack Table v8 en prod, restez sur v8. Par contre, si vous avez des tables complexes ou des besoins multi-framework, gardez un œil sur la v9.
Bonus : shadcn CLI
L’outil de la semaine, c’est shadcn CLI !
shadcn continue de devenir bien plus qu’une collection de composants copiables. Le CLI prend de plus en plus de place : presets, inspection, génération, standardisation du setup.
C’est intéressant parce que le problème côté UI React est très concret. Les équipes veulent aller vite, garder la main sur le code, éviter les composants incompréhensibles, et arrêter de reconstruire les mêmes briques à chaque projet.
Exemple :
npx shadcn@latest add button dialog input
Après cette commande, les composants arrivent dans votre repo. Vous pouvez les modifier, les relire, les versionner, les aligner avec vos conventions.
C’est différent d’une lib de composants classique dans le sens où vous récupérez tout le code et vous en devenez les propriétaires. C’est très utile si vous souhaitez garder le contrôle du code ou si vous voulez apporter des modifications.
Ce modèle est très pratique pour lancer une app React ou Next rapidement. Il demande aussi un minimum de discipline : conventions de variants, structure des composants, règles d’accessibilité, revue UI, cohérence avec le design system.
Bien utilisé, ça peut aider à monter l’UX et le code au niveau supérieur.
Résumé
React 19 continue de stabiliser les Server Components, surtout côté typage, performance et frontière serveur/client.
React Router 7.15.0 prépare la suite avec des ajustements utiles autour des modes Framework et Data.
Vite 8.0.11 avance encore sur Rolldown, ce qui concerne surtout les projets avec plugins, monorepos ou builds custom.
Vitest 5.0.0-beta.2 commence à afficher les migrations à venir, surtout pour les grosses suites avec helpers et mocks partagés.
TanStack Table v9 alpha continue de pousser l’approche multi-framework avec des bindings de réactivité externes.
shadcn CLI confirme son rôle d’accélérateur UI pour les apps React et Next qui veulent garder le contrôle du code.
À lundi prochain,
Maxime