Les composants fonctionnels sont-ils équivalents à une programmation fonctionnelle ?

Les développeurs de React savent déjà que React comporte deux types de composants :

• Composant de classe
• Composant de fonction

Vu l'évocation de « classe » et de « fonction », des questions se posent naturellement :

• Les composants de classe sont-ils liés à la programmation orientée objet (POO) ?
• Les composants fonctionnels sont-ils liés à la programmation fonctionnelle (FP) ?

Après tout, si les composants de classe sont liés à la POO, alors les principes de la POO (héritage, encapsulation, polymorphisme, etc.) peuvent guider le développement de composants basés sur les classes. De même, les principes de FP peuvent affecter les composants fonctionnels. En d’autres termes, nous pouvons appliquer directement les meilleures pratiques de ces paradigmes de programmation aux projets React.

Alors, quelle est la relation entre les composants fonctionnels et la programmation fonctionnelle ? Cet article approfondira ce sujet.

Paradigmes de programmation et DSL

Tout d'abord, nous devons préciser que la syntaxe du framework est essentiellement un DSL (Domain Specific Language) personnalisé pour le développement dans un domaine spécifique.

Par exemple, React est un DSL pour créer des vues. Bien que différentes plates-formes utilisent des frameworks différents pour créer des vues, par exemple :

• Côté Web : ReactDOM
• Mini Programme : Taro
• Développement natif : le framework interne de ByteDance React Lynx

Ces frameworks suivent généralement le même DSL (syntaxe React). Ce DSL n'est lié à aucun paradigme de programmation particulier, mais doit être considéré comme un ensemble de fonctionnalités de langage bien adaptées au développement de vues.

Donc, dans le cadre du React DSL :

• Les composants fonctionnels peuvent incarner les principes de la POO.
• Les composants de classe peuvent refléter les principes de FP.

Tant que ces principes sont bénéfiques pour voir le développement, ils peuvent être intégrés dans le DSL.

Par exemple, considérons le composant fonctionnel suivant Header composé de WelcomeMessage et LogoutButton, qui démontre le principe de composition sur héritage en POO :

<code class="language-javascript">function Header(props) {
  return (
    <div>
      <WelcomeMessage name={props.name} />
      <LogoutButton onClick={props.onLogout} />
    </div>
  );
}</code>

De même, considérons le composant de classe Cpn, où le nombre d'états est mis à jour non pas par mutation (this.state.count), mais en appelant this.setState avec des données immuables :

<code class="language-javascript">class Cpn extends React.Component {
  // ...
  onClick() {
    const count = this.state.count;
    this.setState({ count: count + 1 });
  }
  render() {
    // ...
  }
}</code>

L'utilisation de données immuables reflète les principes de la FP.

Par conséquent, lors de l'exploration d'une fonctionnalité React, nous devons considérer les trois étapes suivantes :

1. Quelle est la philosophie de développement fondamentale de React ?
2. Quelles idées issues de différents paradigmes de programmation ont été utilisées pour mettre en œuvre cette idée ?
3. Comment ces idées peuvent-elles être appliquées dans React ?

En appliquant cette réflexion à la relation entre composants fonctionnels et programmation fonctionnelle, on retrouve :

• Les composants fonctionnels sont le résultat de la mise en œuvre (étape 3).
• La programmation fonctionnelle est un paradigme de programmation (étape 2).

Cela définit la relation entre eux : les composants fonctionnels sont le produit de la mise en œuvre de plusieurs paradigmes de programmation (principalement POO et FP) dans React, empruntant ainsi quelques idées à FP.

Les composants fonctionnels ne doivent pas être considérés uniquement comme l'incarnation de la programmation fonctionnelle dans React.

L'évolution des composants fonctionnels

Explorons l'évolution des composants fonctionnels en utilisant le processus de réflexion en trois étapes mentionné précédemment. La philosophie de développement de React s'exprime mieux par la formule suivante :

<code class="language-javascript">function Header(props) {
  return (
    <div>
      <WelcomeMessage name={props.name} />
      <LogoutButton onClick={props.onLogout} />
    </div>
  );
}</code>

Afin de concrétiser ce concept, deux éléments clés sont nécessaires :

• Instantané des données
• Mappage des fonctions

Ici, les données immuables de FP sont plus appropriées comme support d'instantané de données. C'est pourquoi l'état dans React est immuable : l'essence de l'état est un instantané.

Il n'y a pas d'exigences spécifiques pour le porteur du mappage de fonctions. Dans React, chaque mise à jour déclenche un nouveau rendu, et le processus de rendu lui-même est un processus de mappage de fonctions. L'entrée est constituée d'accessoires et d'état, et la sortie est JSX.

En revanche, les composants Vue sont plus conformes aux principes de la POO. Considérez ce composant Vue App :

<code class="language-javascript">class Cpn extends React.Component {
  // ...
  onClick() {
    const count = this.state.count;
    this.setState({ count: count + 1 });
  }
  render() {
    // ...
  }
}</code>

La méthode de configuration du composant n'est exécutée qu'une seule fois lors de l'initialisation. Les opérations de mise à jour ultérieures opèrent sur les mêmes données au sein de la fermeture, ce qui correspond à la notion d'instances en POO.

Étant donné que React n'impose pas d'exigences particulières au porteur du mappage de fonctions, les composants de classe et les composants de fonction sont des options viables.

Pourquoi les composants de fonction ont-ils remplacé les composants de classe ?

Beaucoup de gens pensent que l'amélioration de la réutilisabilité de la logique grâce aux hooks est la principale raison pour laquelle les composants fonctionnels sont supérieurs aux composants de classe. Cependant, le modèle de développement de classes basé sur un décorateur, en particulier lorsqu'il est combiné avec TypeScript, s'est avéré être une méthode efficace de réutilisation logique.

La vraie raison est que les composants fonctionnels peuvent mieux implémenter le concept de UI = fn(snapshot).

Comme mentionné précédemment, l'instantané dans la formule représente un instantané de l'état, qui dans React comprend :

• état
• accessoires
• contexte

Pour un composant donné, la formule UI = fn(snapshot) garantit que le même instantané produit la même sortie (JSX). Cependant, les mises à jour d'état peuvent également déclencher des effets secondaires, tels que la récupération de données ou la manipulation du DOM.

Dans les composants de classe, ces logiques d'effets secondaires sont dispersées dans diverses méthodes de cycle de vie, ce qui rend React difficile à contrôler. Mais en composant fonctionnel :

• Les effets secondaires sont limités à l'utilisationEffet. React garantit que les effets secondaires des rendus précédents sont nettoyés (via la valeur de retour de useEffect) avant d'appliquer de nouveaux effets secondaires.
La propagation de
• ref est restreinte par des mécanismes tels que forwardRef, limitant son impact potentiel.
• Les effets secondaires de la récupération de données sont gérés par Suspense comme suit :

<code>UI = fn(snapshot);</code>

Utilisation :

<code class="language-javascript">const App = {
  setup(initialProps) {
    const count = reactive({ count: 0 });
    const add = () => { count.value++; };
    return { count, add };
  },
  template: "...omitted"
};</code>

En bref, les composants fonctionnels garantissent que les effets secondaires restent contrôlables, fournissant une sortie cohérente pour la même entrée d'instantané. Ceci est cohérent avec le concept de fonctions pures dans FP, c'est pourquoi les composants fonctionnels sont devenus un choix courant dans React.

Conclusion

Les composants fonctionnels ne sont pas une implémentation directe de la programmation fonctionnelle dans React, mais le support le plus approprié pour implémenter le concept de base de React UI = fn(snapshot). React intègre d'excellentes idées issues de divers paradigmes de programmation, parmi lesquels FP a la plus grande influence. En fin de compte, chaque choix de conception sert l’idée globale.

---

Chez Leapcell, nous sommes votre premier choix pour héberger vos projets Node.js.

Leapcell est une plateforme sans serveur nouvelle génération pour l'hébergement web, les tâches asynchrones et Redis :

Support multilingue

• Développez avec Node.js, Python, Go ou Rust.

Déployez un nombre illimité de projets gratuitement

• Payez uniquement ce que vous utilisez – pas de demandes, pas de frais.

Une rentabilité inégalée

• Payez au fur et à mesure, pas de frais d'inactivité.
• Exemple : 25 $ prend en charge 6,94 millions de requêtes avec un temps de réponse moyen de 60 ms.

Expérience développeur simplifiée

• Interface utilisateur intuitive, facile à configurer.
• Pipeline CI/CD entièrement automatisé et intégration GitOps.
• Mesures et journalisation en temps réel pour des informations exploitables.

Évolutivité facile et hautes performances

• Mise à l'échelle automatique pour gérer facilement une simultanéité élevée.
• Zéro frais opérationnels - concentrez-vous uniquement sur la construction.

Apprenez-en plus dans la documentation !

Suivez-nous sur X : @LeapcellHQ

---

Lisez notre blog

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!