Maîtriser Next.js : mon parcours de SSG à SSR par essais et erreurs

Salut les gars ! Dans ce blog, je veux partager avec vous le prochain nouveau projet sur lequel je travaille depuis un bon bout de temps. Cela me ramène vraiment à l'époque où j'ai commencé mon parcours avec MERN stack, où j'avais des difficultés dans chaque projet que je réalisais, mais après avoir traversé toutes ces difficultés, je peux toujours dire que rester bloqué sur certains sujets me fait encore un peu peur. .

Je souhaite partager avec vous tous la différence entre SSG et SSR.
Je faisais un projet mineur de création d'un site de blog et je voulais générer les blogs au moment de la construction, mais cela ne générait pas et après 1 semaine de recherche et d'errance sur Internet pour apprendre la différence, j'ai finalement compris quelle est la différence. 🎜>

Introduction

Next.js est un framework React puissant développé par vercel. Il possède plusieurs fonctionnalités intégrées pour améliorer le développement et l'expérience utilisateur.

Certaines des fonctionnalités sont :

Rendu hybride statique et serveur : il prend en charge à la fois SSR et SSG, permettant aux développeurs de choisir le meilleur en fonction de leur cas d'utilisation.
Routes API : elles vous permettent de créer des points de terminaison d'API dans l'application nextjs elle-même, éliminant ainsi le besoin d'un service backend distinct pour les tâches API simples.
Fractionnement et optimisation automatiques du code : il divise le code et envoie uniquement le javasript nécessaire au navigateur et dispose de nombreuses optimisations intégrées telles que l'optimisation de l'image, des constructions plus rapides, etc.
Routage du système de fichiers : il dispose d'un routage du système de fichiers (selon celui que vous utilisez pour l'application ou le routeur de page) qui crée automatiquement des itinéraires.
Prise en charge de TypeScript : il est recommandé de coder en dactylographié car il détecte de nombreuses erreurs au moment de l'exécution uniquement qui, si elles ne sont pas utilisées, peuvent causer des problèmes au moment de la construction.

SSG contre RSS

Génération côté serveur (SSG)

SSG génère des pages HTML statiques au moment de la construction. Le contenu est pré-rendu, ce qui signifie qu'il ne change pas jusqu'à ce que vous reconstruisiez le site.

Il est préférable pour les pages qui ne changent pas trop fréquemment, comme les pages marketing ou la documentation qui ne change pas trop fréquemment.
Il est essentiellement généré pendant le temps de construction et est statique, il se charge donc extrêmement rapidement.

Pour obtenir le chemin dynamique que vous souhaitez restituer au moment de la construction, vous pouvez utiliser getStaticParams. Vous pouvez en savoir plus à ce sujet ici. Lien

Rendu côté serveur (SSR)

SSR génère des pages HTML à chaque requête. Le serveur restitue le HTML dynamiquement pour chaque requête entrante. Il est préférable pour les pages qui doivent être dynamiques et à jour à chaque demande. Cela inclut les tableaux de bord des utilisateurs, les flux d'actualités et tout autre contenu qui change fréquemment ou est spécifique à l'utilisateur.

Étant donné que le HTML est généré à chaque requête, il est plus lent que SSG mais il garantit que le contenu est toujours frais et à jour.

Pensée finale

Mon parcours avec Next.js, SSG et SSR a été rempli d'opportunités d'apprentissage. Chaque erreur et chaque défi ont approfondi ma compréhension et amélioré mes compétences en résolution de problèmes. Je vous encourage à expérimenter à la fois SSG et SSR dans vos projets pour voir comment ils peuvent mieux répondre à vos besoins.

Merci d'avoir lu ! J'espère que mes expériences vous aideront dans votre parcours Next.js. N'hésitez pas à partager vos propres expériences ou à poser des questions dans les commentaires ci-dessous. Continuons à apprendre et à grandir ensemble en tant que communauté. Bon codage !

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!