Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

[Suggestion]: lazy initialization example can encourage unsafe patterns - show example

Ouverte Adaptée aux débutants
#8,677 2 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 3 jours

@Mahendra-2006 y travaille déjà.

Depuis le 1/10/2026.

  • #8679 par @Mahendra-2006 — ouverte

Évaluation

Difficulté
2/5
Temps estimé
1-3 heures
Accessibilité débutants
82/100
Type d'issue
Documentation
Clarté
Clairement spécifiée
Activité
Active
Stack technique
javascript, react
Domaine
documentation

Piste de recherche

Commencez par la section « lazy initialization » de la page de documentation React liée. Clarifiez que la création de ressources gérées par le cycle de vie pendant le rendu peut être dangereuse lorsqu’un rendu n’est pas validé, et montrez la différence avec la lazy initialization sûre ; c’est terminé lorsque les lecteurs peuvent déterminer quels modèles nécessitent un Effect.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

type: documentation
Summary

Show example when lazy initialization example can be unsafe.

Page

https://react.dev/reference/rules/components-and-hooks-must-be-pure#lazy-initialization

Details

The lazy initialization section currently presents this pattern as valid:

function ExpenseForm() {
   SuperCalculator.initializeIfNotReady(); // ✅ Good: if it doesn't affect other components

   // Continue rendering...
}

However, I think this example is easy to generalize into a dangerous pattern:

if (ref.current === null) {
   ref.current = createResource();
}

For resources with a lifecycle - subscriptions, event listeners, timers, connections, etc. - creating the resource during render is unsafe because a render is not guaranteed to result in a committed effect.

For example:

function useLegacyStore() {
   const subscriptionRef = useRef(null);

   if (subscriptionRef.current === null) {
     subscriptionRef.current = store.subscribe(() => {
       // ...
     });
   }

   useEffect(() => {
     return () => {
       subscriptionRef.current?.unsubscribe();
     };
   }, []);
}

This can appear to work when components only render as part of normal mount/unmount flows. However, with concurrent rendering or APIs such as Activity, React may render a component without subsequently mounting the
Effect associated with that render.

The subscription has already been created, while its cleanup is tied to an Effect that may never run.

The documentation should make this distinction explicit, perhaps by adding a warning/example.

Inspired by:
https://hackernoon.com/react-activity-when-a-render-no-longer-guarantees-an-effect

Langage dominant
JavaScript
Étoiles
11.8k
Forks
8k
Merge moyen
3 j 5 h
PR mergées (30 j)
9

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de reactjs/react.dev

Toutes les issues de reactjs/react.dev

Issues similaires

Plus d'issues JavaScript

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.