La semaine dernière a été plutôt calme. Pas de grosse sortie.

Au sommaire aujourd’hui :

TanStack Router a corrigé plusieurs points côté SSR et génération
React Hook Form ajoute une API assez pratique pour mettre à jour plusieurs champs d’un coup
Zod continue de stabiliser sa v4.
TypeScript a aussi eu plusieurs tickets intéressants cette semaine, surtout sur des cas avancés : refactor JSX, types récursifs, alias de paths et comportements limites du compilateur.

TanStack Router

Plusieurs releases ont été publiées le 30 avril. Parmi tous les changements, deux ressortent particulièrement.

Le premier corrige la collecte des imports pour ignorer les imports et re-exports purement typés.

Le problème derrière ce genre de fix est assez simple : en TypeScript, tout ce qui est importé n’existe pas forcément au runtime.

import type { User } from "./types"

export type { LoaderData } from "./loader"

Par exemple, ces imports ne servent qu’au compilateur (et pas au js exécuté). Si un outil de build ou un plugin les traite comme de vrais imports runtime, il peut se retrouver à chercher un module, une valeur ou une dépendance qui n’existe pas vraiment une fois le code compilé.

Le deuxième fix important trie les entrées du manifest des server functions pour rendre le build déterministe.

Un build déterministe, ça veut dire qu’à code identique, la sortie générée reste identique.

C’est plus important que ça en a l’air. Si l’ordre d’un manifest change d’un build à l’autre, même sans changement de code, ça peut avoir pas mal de conséquences.

Imaginons que :

Build local → manifest 1
Build CI → manifest 2
Build serveur → manifest 3

Alors on pourrait avoir des problèmes d’infra tels que : du cache invalidé pour rien, un diff de build illisible, des artefacts qui changent sans raison.

Si jamais vous utilisez TanStack Start ou TanStack Router avec du SSR, je vous conseille de regarder les releases du 30 avril avant le prochain déploiement.

React Hook Form

React Hook Form ajoute setValues.

L’idée est simple : mettre à jour plusieurs valeurs du formulaire en une fois.

Avant, sur un écran d’édition, on se retrouvait souvent avec :

setValue("firstName", user.firstName);
setValue("lastName", user.lastName);
setValue("email", user.email);
setValue("role", user.role);
setValue("company", user.company);
setValue("timezone", user.timezone);

Pas très pratique… dès que le formulaire grossit, on se retrouve avec du code de synchronisation partout.

Avec setValues :

setValues({
  firstName: user.firstName,
  lastName: user.lastName,
  email: user.email,
  role: user.role,
  company: user.company,
  timezone: user.timezone,
});

Et si on veut garder une partie de l’état courant :

setValues((current) => ({
  ...current,
  email: user.email,
  role: user.role,
}));

Zod et les tuples

Zod continue de stabiliser sa v4. Récemment, un fix a corrigé le comportement des defaults dans les tuples.

Un tuple, c’est une structure de données dans laquelle la position porte le sens :

const Row = z.tuple([
  z.string(),
  z.number(),
  z.boolean(),
]);

Ici, on attend exactement :

["test", 123, true]

Le problème, c’est que les tuples sont plus fragiles que les objets nommés.

Avec un objet, une donnée invalide est souvent visible :

const User = z.object({
  name: z.string(),
  age: z.number(),
  active: z.boolean(),
});

Si age manque, on sait ce qui manque.

Avec un tuple, une valeur absente ou mal placée peut être plus difficile à voir :

["test", true]

Ici, la position porte toute l’information. La validation doit savoir si une valeur manque, si un élément optionnel a été omis ou si une valeur par défaut doit s’appliquer.

Exemple corrigé récemment :

const schema = z.tuple([
  z.string(),
  z.string().default("fallback"),
])

schema.parse(["a"])
// ["a", "fallback"]

Si vous utilisez Zod pour parser vos données, les patchs de la v4 en valent la peine.

TypeScript

Cette semaine, plusieurs tickets touchent des cas très avancés. Je ne vais pas rentrer dans le détail ici, parce que la gestion des tickets TypeScript mérite un article à part, mais je vous conseille de garder un oeil sur les issues en cours : https://github.com/microsoft/TypeScript/issues.

Next.js

Next.js continue de publier des versions canary.

Rien à faire si votre app est stable. Les versions canary sont intéressantes si vous maintenez un starter, une lib compatible Next, une stack interne, une intégration avec Turbopack, ou un setup serveur un peu spécifique.

Sinon, laissez passer. Les versions canary servent à observer, reproduire ou tester un bug bien précis.

Résumé

Si vous utilisez TanStack Router ou TanStack Start en prod, relisez les releases du 30 avril avant le prochain déploiement, surtout si votre app utilise du SSR.
Si vous avez des formulaires React Hook Form avec plusieurs setValue à la suite, testez setValues sur un écran.
Si vous êtes sur Zod v4 avec des tuples, des payloads positionnels ou des schémas très imbriqués, jetez un oeil aux derniers patchs avant de bump.
Si votre codebase dépend beaucoup de TypeScript pour les refactors, les types générés ou les alias de paths, regardez les tickets TypeScript.

À lundi prochain !

React Radar #1