Next.js, le framework de développement web open-source, dévoile Next.js 14
Next.js, le framework de développement web open-source, dévoile Next.js 14, la nouvelle version offre un compilateur amélioré Next.js Turbopack et un aperçu de la fonctionnalité Pré-rendu partiel.
Next.js est un framework de développement web open-source créé par la société privée Vercel qui fournit des applications web basées sur React avec un rendu côté serveur et une génération de site web statique. La documentation de React mentionne Next.js parmi les "chaînes d'outils recommandées" et le conseille aux développeurs lors de la "construction d'un site web rendu côté serveur avec Node.js" Alors que les applications React traditionnelles ne peuvent rendre leur contenu que dans le navigateur côté client, Next.js étend cette fonctionnalité pour inclure des applications rendues côté serveur.
Comme annoncé à la Next.js Conf, Next.js 14 est la version la plus ciblée avec :
- Turbopack : 5 000 tests réussis pour App & Pages Router
- Démarrage du serveur local 53% plus rapide
- 94% de mises à jour de code plus rapides avec Fast Refresh
- Actions serveur (Stable) : Mutations progressivement améliorées
- Intégration de la mise en cache et de la revalidation
- Appels de fonctions simples, ou fonctionnement natif avec les formulaires
- Pré-rendus partiels (aperçu) : Réponse statique initiale rapide + contenu dynamique en continu
- Next.js Learn (Nouveau) : Cours gratuit sur l'App Router, l'authentification, les bases de données, et plus encore.
Mettez à niveau dès aujourd'hui ou démarrez avec :
Terminal
Code:
npx create-next-app@latest
Compilateur Next.js : Turbopack
Depuis Next.js 13, l'équipe de Next.js a travaillé pour améliorer la performance du développement local dans Next.js, à la fois dans les Pages et dans l'App Router.
Auparavant, ils avaient réécrient next dev et d'autres parties de Next.js pour soutenir cet effort. Ils ont depuis changé leur approche pour être plus incrémental. Cela signifie que le compilateur basé sur Rust atteindra bientôt la stabilité, car ils se sont recentrés sur le support de toutes les fonctionnalités de Next.js en premier.
5 000 tests d'intégration pour next dev passent maintenant avec Turbopack, le moteur Rust sous-jacent. Ces tests incluent 7 ans de corrections de bugs et de reproductions.
En testant vercel.com, une grande application Next.js, ils ont vu :
- Un démarrage du serveur local jusqu'à 53,3 % plus rapide
- Jusqu'à 94,7 % de mises à jour de code plus rapides avec Fast Refresh
Ce benchmark est un résultat pratique des améliorations de performance auxquelles vous pouvez vous attendre avec une grande application (et un grand graphique de modules). Avec 90% de tests réussis pour next dev, vous devriez voir des performances plus rapides et plus fiables lorsque vous utilisez next dev --turbo.
Une fois qu'ils auront atteint 100% des tests réussis, ils passeront Turbopack à la version stable dans une prochaine version mineure. Ils continueront également à supporter l'utilisation de webpack pour les configurations personnalisées et les plugins de l'écosystème.
Formes et mutations
Next.js 9 a introduit les API Routes, un moyen de construire rapidement des points d'accès au backend en même temps que le code du frontend.
Par exemple, vous pouvez créer un nouveau fichier dans le répertoire api/ :
pages/api/submit.ts
Code:
1
2
3
4
5
6
7
8
9
10
| import type { NextApiRequest, NextApiResponse } from 'next';
export default async function handler(
req: NextApiRequest,
res: NextApiResponse,
) {
const data = req.body;
const id = await createItem(data);
res.status(200).json({ id });
} |
Ensuite, côté client, vous pouvez utiliser React et un gestionnaire d'événement comme onSubmit pour effectuer fetch dans votre route API.
pages/index.tsx
Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
| import { FormEvent } from 'react';
export default function Page() {
async function onSubmit(event: FormEvent<HTMLFormElement>) {
event.preventDefault();
const formData = new FormData(event.currentTarget);
const response = await fetch('/api/submit', {
method: 'POST',
body: formData,
});
// Handle response if necessary
const data = await response.json();
// ...
}
return (
<form onSubmit={onSubmit}>
<input type="text" name="name" />
<button type="submit">Submit</button>
</form>
);
} |
Avec Next.js 14, l'équipe de Next.js veut simplifier l'expérience des développeurs dans la création de mutations de données. De plus, ils voulent améliorer l'expérience de l'utilisateur lorsqu'il dispose d'une connexion réseau lente, ou lorsqu'il soumet un formulaire à partir d'un appareil moins puissant.
Actions serveur (stable)
Et si vous n'aviez pas besoin de créer manuellement une route API ? Au lieu de cela, vous pourriez définir une fonction qui s'exécute en toute sécurité sur le serveur, appelée directement à partir de vos composants React.
L'App Router est construit sur le canal React canary, qui est stable pour les frameworks afin d'adopter de nouvelles fonctionnalités. Depuis la v14, Next.js est passé à la dernière version de React canary, qui inclut des actions serveurs stables.
L'exemple précédent du Pages Router peut être simplifié en un seul fichier :
app/page.tsx
Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
| export default function Page() {
async function create(formData: FormData) {
'use server';
const id = await createItem(formData);
}
return (
<form action={create}>
<input type="text" name="name" />
<button type="submit">Submit</button>
</form>
);
} |
Actions serveur devrait sembler familier aux développeurs qui ont déjà utilisé des frameworks centrés sur le serveur dans le passé. Il s'appuie sur les principes fondamentaux du web tels que les formulaires et l'API web FormData.
Bien que l'utilisation des actions serveur par le biais d'un formulaire soit utile pour l'amélioration progressive, ce n'est pas une obligation. Vous pouvez également les appeler directement en tant que fonction, sans formulaire. Lorsque vous utilisez TypeScript, vous bénéficiez d'une sécurité de type de bout en bout entre le client et le serveur.
La modification des données, le re-rendu de la page ou la redirection peuvent se faire en un seul aller-retour sur le réseau, ce qui garantit que les données correctes sont affichées sur le client, même si le fournisseur en amont est lent. En outre, vous pouvez composer et réutiliser différentes actions, y compris plusieurs actions différentes dans la même route.
Mise en cache, revalidation, redirection, etc.
Les actions serveur sont profondément intégrées dans l'ensemble du modèle App Router. Vous pouvez :
- Revalider les données mises en cache avec revalidatePath() ou revalidateTag()
- Rediriger vers différentes routes avec redirect()
- Définir et lire les cookies avec cookies()
- Gérer les mises à jour optimistes de l'interface utilisateur avec useOptimistic()
- Attraper et afficher les erreurs du serveur avec useFormState()
- Afficher les états de chargement sur le client avec useFormStatus()
Pré-rendus partiels (aperçu)
Léquipe de Next.js a partagé un aperçu de Pré-rendu partiel - une optimisation du compilateur pour le contenu dynamique avec une réponse statique initiale rapide - sur laquelle ils travaillent pour Next.js.
Les Pré-rendus partiels s'appuient sur une décennie de recherche et de développement sur le rendu côté serveur (SSR), la génération de sites statiques (SSG) et la revalidation statique incrémentale (ISR).
Motivation
Il y a actuellement trop de temps d'exécution, d'options de configuration et de méthodes de rendu à prendre en compte. Vous voulez la vitesse et la fiabilité de la statique, tout en prenant en charge des réponses personnalisées et entièrement dynamiques.
Les performances globales et la personnalisation ne doivent pas se faire au détriment de la complexité.
Le défi était de créer une meilleure expérience pour les développeurs, en simplifiant le modèle existant sans introduire de nouvelles API pour les développeurs. Bien que la mise en cache partielle du contenu côté serveur ait déjà existé, ces approches doivent encore répondre aux objectifs de composabilité et d'expérience du développeur que nous visons.
Le Pré-rendu partiel l ne nécessite aucune nouvelle API à apprendre.
Construit sur React Suspense
Le Pré-rendu partiel est défini par vos limites Suspense. Voici comment cela fonctionne. Considérons la page de commerce électronique suivante :
app/page.tsx
Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
| export default function Page() {
return (
<main>
<header>
<h1>My Store</h1>
<Suspense fallback={<CartSkeleton />}>
<ShoppingCart />
</Suspense>
</header>
<Banner />
<Suspense fallback={<ProductListSkeleton />}>
<Recommendations />
</Suspense>
<NewProducts />
</main>
);
} |
Si l'option Pré-rendu partiel est activée, cette page génère un shell statique basé sur les limites de votre <Suspense />. Le fallback de React Suspense est pré-rendu.
Les fallbacks de Suspense dans le shell sont ensuite remplacés par des composants dynamiques, comme la lecture des cookies pour déterminer le panier, ou l'affichage d'une bannière en fonction de l'utilisateur.
Lorsqu'une requête est faite, le shell HTML statique est immédiatement servi :
Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
| <main>
<header>
<h1>My Store</h1>
<div class="cart-skeleton">
<!-- Hole -->
</div>
</header>
<div class="banner" />
<div class="product-list-skeleton">
<!-- Hole -->
</div>
<section class="new-products" />
</main> |
Étant donné que <ShoppingCart /> lit les cookies pour connaître la session de l'utilisateur, ce composant est ensuite diffusé dans le cadre de la même requête HTTP que le shell statique. Il n'y a pas d'allers-retours supplémentaires sur le réseau.
app/cart.tsx
Code:
1
2
3
4
5
6
7
| import { cookies } from 'next/headers'
export default function ShoppingCart() {
const cookieStore = cookies()
const session = cookieStore.get('session')
return ...
} |
Pour obtenir l'enveloppe statique la plus granulaire possible, il peut être nécessaire d'ajouter des limites de suspension supplémentaires. Cependant, si vous utilisez déjà loading.js aujourd'hui, il s'agit d'une limite Suspense implicite, donc aucun changement ne sera nécessaire pour générer le shell statique.
À venir
Le pré-rendement partiel est en cours de développement. Plus de mises à jour seront partagées dans une prochaine version mineure.
Amélioration des métadonnées
Avant que le contenu de votre page puisse être diffusé à partir du serveur, d'importantes métadonnées concernant la fenêtre de visualisation, la palette de couleurs et le thème doivent d'abord être envoyées au navigateur.
S'assurer que ces méta tags sont envoyés avec le contenu initial de la page contribue à une expérience utilisateur fluide, en empêchant la page de vaciller en changeant la couleur du thème, ou en modifiant la mise en page en raison des changements de viewport.
Dans Next.js 14, nous avons découplé les métadonnées bloquantes et non bloquantes. Seul un petit sous-ensemble d'options de métadonnées est bloquant, et nous voulons nous assurer que les métadonnées non bloquantes n'empêcheront pas une page partiellement pré-rendue de servir le shell statique.
Les options de métadonnées suivantes sont désormais obsolètes et seront supprimées demetadata dans une prochaine version majeure :
- viewport : Définit le zoom initial et d'autres propriétés de la fenêtre de visualisation
- colorScheme : Définit les modes de support (clair/foncé) pour la fenêtre de visualisation.
- themeColor : Définit la couleur avec laquelle le chrome autour de la fenêtre de visualisation doit être rendu.
À partir de Next.js 14, de nouvelles options viewport et generateViewport remplacent ces options. Toutes les autres options de metadata restent inchangées.
Vous pouvez commencer à adopter ces nouvelles API dès aujourd'hui. Les options de metadata existantes continueront à fonctionner.
Source : Next.js
Et vous ?
:fleche: Que pensez-vous de cette nouvelle version de Next.js ?
Voir aussi :
:fleche: Next.js 13 est disponible, elle apporte Turbopack, le nouveau successeur de Webpack basé sur Rust, sur une application comportant 3 000 modules, le démarrage de Turbopack prend 1,8 seconde
:fleche: Fresh, un framework web de nouvelle génération, conçu pour la vitesse, la fiabilité et la simplicité, il apporte un peu de concurrence pour Next.js
:fleche: État de JavaScript 2022 : React reste le framework front-end dominant mais est en perte de vitesse côté satisfaction, JQuery est la troisième bibliothèque la plus utilisée
