Limitations du contexte lors de l’imitation de Redux dans l’application Web

Online Coding Courses for Kids

Le point le plus important à comprendre à propos du contexte est qu’il restitue tous les composants qui sont des descendants du fournisseur de contexte, qu’ils consomment ou non le contexte lorsqu’un changement d’état se produit. La seule exception à cette règle est lorsque les enfants du fournisseur de contexte ne changent pas et que seuls les composants qui consomment le contexte sont restitués. C’est la raison principale pour laquelle nous passons l’accessoire enfants aux composants qui fournissent un contexte au lieu de créer des composants à l’intérieur d’eux (veuillez lire Article de blog de James Nelson pour éviter les rendus de contexte inutiles).

L’essentiel, c’est que nous nous retrouvons avec des composants qui sont restitués, même s’ils n’ont pas changé, alors que nous voudrions idéalement restituer uniquement ceux sur lesquels des changements se sont produits. C’est du moins le cas avec Redux lorsqu’il est utilisé conformément aux directives et pratiques de la bibliothèque.

La meilleure stratégie pour réduire les rendus inutiles consiste à diviser le contexte en d’autres contextes (ou à en créer de nouveaux à partir de zéro). Un bon argument pour le faire est lorsque:

  • Une partie de l’état change fréquemment et nous voulons l’isoler.
  • Les composants sont uniquement intéressés à consommer une partie de l’état de l’application.
  • Une partie de l’état change rarement et les composants peuvent consommer à la fois la partie et l’état entier.

Pour illustrer soigneusement les scénarios dans lesquels nous pourrions vouloir diviser le contexte, décrivons d’abord une page commune de notre application. Nous avons la page du réfrigérateur qui à l’en-tête de la page a un formulaire qui enregistre les ingrédients et une liste des ingrédients du réfrigérateur en tant que corps de la page. De plus, lorsqu’un utilisateur supprime avec succès un ingrédient de réfrigérateur, il affiche un message de notification indiquant «L’ingrédient de réfrigérateur a été supprimé avec succès».

Suppression d’un ingrédient du réfrigérateur

Nous pouvons améliorer légèrement les performances en essayant de réduire les rendus inutiles chaque fois qu’une notification se produit.

Actuellement, lorsqu’un utilisateur termine une action qui affiche une notification, la page entière est à nouveau rendue deux fois – une fois lors de l’ajout d’une notification à l’écran et de nouveau lors de sa suppression. La séparation du sous-état des notifications de l’état du contexte du magasin revient à isoler les changements fréquents (un nombre écrasant d’actions utilisateur émet une notification) et où les composants sont intéressés à ne consommer que la partie de l’état.

Comme nous l’avons fait avec StoreContextProvider, nous allons mettre en œuvre le NotificationContextProvider composant.

Composant NotificationContextProvider

Notre composant racine créera tous les fournisseurs de contexte. Nous avons supprimé le réducteur de notifications de appReducer et au lieu de cela, nous le transmettons en tant que valeur accessoire à la nouvelle création NotificationContextProvider composant.

Composant racine avec des contextes de stockage et de notification

Finalement, le NotificationToast (qui est responsable de la gestion des notifications) consommera uniquement l’état du contexte de notification et sa fonction de répartiteur, que nous avons nommée «notifier».

Composant NotificatonToast après la création de l’état de notification et des contextes de mise à jour

Maintenant, chaque fois qu’un composant envoie une notification, il ne restitue que le NotificationToast composant et non l’ensemble de l’application.

Utilisation du profileur de développement React pour enregistrer l’action de suppression des ingrédients du réfrigérateur

En utilisant React dev profiler pour enregistrer notre action, nous pouvons voir que lorsque la notification se produit uniquement NotificationToast est affecté (veuillez regarder les troisième et quatrième rendus de la session enregistrée de profiler). Ainsi, non seulement nous avons amélioré les performances de nos applications (cela s’accompagne d’un coût de maintenabilité que nous verrons dans la section suivante) mais, plus important encore, nous n’avons restitué que les composants qui ont changé (cela s’applique pour NotificationToast composant uniquement).

Nous ne discuterons du cas que lorsque les modifications de sous-état sont peu fréquentes et que les composants peuvent consommer l’état de la partie et de l’état de l’application entière. Il est de plus en plus courant que les applications aient un thème dans lequel un utilisateur sélectionne sa préférence d’affichage des applications. Cette partie de l’État n’est pas censée changer souvent. Par conséquent, nous pouvons diviser l’état du thème et sa fonction de répartition dans des contextes distincts. Les composants seront intéressés à consommer à la fois le contexte de thème et le fournisseur de contexte de stockage, mais comme les changements d’état du thème sont peu fréquents, dans ce cas, nous ne nous soucierons pas des rendus inutiles des composants (un autre scénario similaire est l’authentification des utilisateurs).

Close Menu