Les Server Components ne s'exécutent que sur le serveur, n'envoient aucun JavaScript au navigateur, et peuvent await des données directement, ce qui supprime la plomberie fetch plus useEffect plus états de chargement. Les Client Components, marqués use client, gardent l'interactivité, le state et les API du navigateur. Vous remontez la récupération de données dans les composants serveur et gardez les composants client comme de petites feuilles, ce qui réduit le bundle et déplace la cascade de données côté serveur.
Pourquoi les recruteurs posent cette question
C'est le plus gros changement dans React depuis des années, donc le recruteur vérifie que vous vous êtes tenu à jour et que vous savez articuler une frontière plutôt que réciter un argumentaire marketing. Il veut vous entendre expliquer ce qui traverse la frontière de sérialisation, où le state peut vivre ou non, et quels sont les arbitrages. L'enthousiasme vague passe mal ici ; un candidat qui nomme une contrainte réelle passe pour quelqu'un qui a livré.
Comment structurer votre réponse
- Définissez les deux types de composants en une phrase chacun.
- Expliquez ce qui peut traverser la frontière et ce qui ne le peut pas.
- Décrivez la forme de l'arbre de composants qui en résulte.
- Nommez un arbitrage concret que vous avez rencontré.
Exemple de réponse
Le modèle mental qui m'a débloqué, c'est que la frontière est une frontière de sérialisation, pas un dossier. Les Server Components s'exécutent sur le serveur et leur code n'atteint jamais le navigateur, donc une grosse bibliothèque markdown ou de dates utilisée là coûte zéro kilooctet côté client. Ils peuvent await un appel à la base directement dans le corps du composant. Tout ce qui a du state, des effets ou un gestionnaire d'événement doit être un Client Component avec use client en haut, et les props qui y entrent doivent être sérialisables, donc vous passez des données plutôt que des fonctions ou des instances de classe. En pratique, mes arbres ressemblent à des composants serveur de bout en bout avec de petites feuilles interactives, et je passe les données récupérées côté serveur en props. L'arbitrage que j'ai rencontré sur un projet récent, c'était la charge mentale en revue de code, parce que les gens ajoutaient use client sur un parent pour un petit bouton et tiraient discrètement tout un sous-arbre côté client. On a fini par ajouter une règle de lint et un contrôle de taille de bundle en CI pour attraper ça.
Vous passez cet entretien bientôt ? GhostPilot écoute votre appel en direct, repère la question dès qu'elle est posée et affiche une réponse structurée à l'écran en temps réel. Essayez-le lors de votre prochain entretien blanc, ou prenez un Session Pass à $29, sans abonnement, pour le jour J.
Voir comment ça marcheQuestions de relance à prévoir
- Où se place le hook use là-dedans ?
- Comment gérez-vous un formulaire qui a besoin d'un aller-retour serveur ?
- Comment mettriez-vous en cache des données récupérées dans un composant serveur ?
Autres questions pour Développeur full stack
Votre recruteur posera sa propre version de celle-ci. Collez votre véritable fiche de poste dans le Question Predictor gratuit et obtenez les 20 questions que ce poste a le plus de chances de poser, avec ce que chacune cherche vraiment à sonder.
Prédire mes questions