De façon incrémentale, et seulement là où ça rapporte quelque chose. Classes et composants fonction cohabitent très bien, donc aucune réécriture big bang n'est nécessaire. Convertissez d'abord les composants feuilles, extrayez la logique partagée des composants d'ordre supérieur et des render props vers des hooks personnalisés, et gardez les error boundaries en classes puisqu'elles doivent encore l'être. Rattachez chaque conversion à du travail que vous faisiez déjà, avec des tests qui portent sur le comportement plutôt que sur l'implémentation.
Pourquoi les recruteurs posent cette question
C'est une question de jugement déguisée en question de migration. Le recruteur veut voir si vous brûleriez un trimestre sur une réécriture sans bénéfice visible pour l'utilisateur, ou si vous trouvez un chemin incrémental. Il vérifie aussi des connaissances pratiques : quelles méthodes de cycle de vie se traduisent proprement en effets, lesquelles non, que les error boundaries ne peuvent pas être converties, et comment vous évitez les régressions sans couverture complète.
Comment structurer votre réponse
- Rejetez la réécriture big bang et dites pourquoi l'incrémental marche ici.
- Donnez votre ordre : les feuilles d'abord, la logique partagée vers des hooks personnalisés.
- Nommez les morceaux qui ne se convertissent pas proprement.
- Expliquez comment vous vous protégez des régressions et mesurez l'avancement.
Exemple de réponse
Je n'en ferais pas un projet, j'en ferais une habitude. Classes et composants fonction cohabitent tranquillement, donc rien ne force à tout convertir, et une réécriture sans changement visible pour l'utilisateur est difficile à vendre et un excellent moyen d'introduire des bugs. Donc la règle devient : si vous modifiez déjà un fichier, et que c'est une feuille ou presque, convertissez-le. De toute façon, le vrai trésor n'est pas dans les composants, il est dans la logique partagée piégée dans les composants d'ordre supérieur et les render props, parce que ça se transforme en hooks personnalisés que tout le monde peut réutiliser. Sur la correspondance, componentDidMount et componentWillUnmount vont dans un seul effet avec un nettoyage, componentDidUpdate se scinde en général en plusieurs effets par sujet, et getDerivedStateFromProps se révèle presque toujours être de l'état dérivé qu'il suffit de calculer pendant le rendu. Les error boundaries restent des classes, ça n'a pas changé. Avant de convertir quoi que ce soit de non trivial, je veux des tests de niveau comportement autour, qui testent ce que voit l'utilisateur plutôt que l'état interne, pour que la conversion soit démontrablement neutre.
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
- Quelles méthodes de cycle de vie n'ont pas d'équivalent propre en hook ?
- Comment convertiriez-vous un composant d'ordre supérieur qui enveloppe quarante écrans ?
- Comment empêchez-vous l'équipe de migrer à moitié puis de caler ?
Autres questions pour Développeur React
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