React: Existe-t-il un moyen d'accéder à une nouvelle API de contexte dans ComponentDidMount?

Ajout d'un exemple que j'essaie de faire fonctionner: https://codesandbox.io/s/l20yn296w7

EDIT: En suivant les instructions de https://github.com/reactjs/rfcs/blob/master/text/0002-new-version-of-context.md#class -based-api

C'est ainsi que cela peut être réalisé avec une nouvelle API.

class BaseMapElement extends React.Component {
  componentDidMount() {
    console.log(this.props.context);
  }

  render() {
    return null;
  }
}

const MapElement = () => (
  <Context.Consumer>
    {context =>
      <BaseMapElement context={context} />
    }
  </Context.Consumer>
)

Donc, la seule façon d'accéder via componentDidMount est de rediriger vers Props?

Edit: changé en componentDidMount

Le composant d'ordre supérieur qui se redirige vers les accessoires est un bon modèle, mais pour les cas où je ne veux pas du composant supplémentaire que je fais généralement, c'est stocker la valeur de contexte sur l'instance du composant comme: this.contextValue = value puis accédez-y dans le crochets de cycle de vie. C'est un peu moche mais ça va en général, je pense que depuis que vous avez opté pour le modèle plus sympa, hoc, en tant qu'optimisation

Je suis confronté au même dilemme.
Il devrait y avoir un moyen facile d'accéder ou d'appeler le contexte dans les méthodes du cycle de vie.
Nous pourrions avoir besoin d'initialiser des éléments, de vérifier et de récupérer des données ou même de nettoyer au démontage.
Les gens le font maintenant avec le contexte prétendument brisé actuel.
Oui, cela peut être résolu en enveloppant notre composant dans un autre composant! Mais cela ressemble plus à une solution de contournement qu'à une solution.

stocker la valeur de contexte sur l'instance du composant comme: this.contextValue = value puis y accéder dans les hooks de cycle de vie

Je suis presque sûr que ce n'est pas sûr en mode asynchrone. Veuillez ne pas faire ça. cc @acdlite

Oui, cela peut être résolu en enveloppant notre composant dans un autre composant! Mais cela ressemble plus à une solution de contournement qu'à une solution.

Je suis d'accord avec ça. Ce serait bien d'accéder nativement via componentDidMount et componentWillUnmount pour pouvoir initialiser / nettoyer les choses,

En général, utiliser des variables d'instance pour être intelligent et tromper le flux de données normal va causer des problèmes en asynchrone. Ne le fais pas. C'est un peu déroutant aujourd'hui, car les variables d'instance sont le seul moyen de faire certaines choses, comme les minuteries. Avant de publier async, nous publierons des recommandations plus claires - et un jour, nous aurons une nouvelle API de composant qui ne dépend pas tellement des instances.

tl; dr: utilise une indirection d'accessoires. Et ne vous inquiétez pas trop du composant supplémentaire.

Je suis presque sûr que ce n'est pas sûr en mode asynchrone. Veuillez ne pas faire ça.

En quoi cela serait-il dangereux (et de quelle manière)? Ce n'est pas clair dans tout ce discours sur le mode asynchrone, ce que signifie «unsafe». Cela commence à se sentir comme un boogyman dont le comportement est irrationnel et imprévisible, ce qui ne donne pas beaucoup d'assurance aux gens dans un système généralement apprécié pour son modèle de flux de données simple et facilement compréhensible. J'ai l'impression que les composants sont de retour dans le pays pré-0.13 où ils sont à nouveau des objets magiques.

Il est également facile de dire "Il suffit d'ajouter un autre composant", mais c'est souvent onéreux et cela introduit sa propre catégorie de bogues et de défis. Je ne commence pas à avoir l'impression que les gens doivent inventer des abstractions sur une API de réaction pour être «sûrs».

désolé ^ si ce qui précède semble ennuyé / en colère, je n'avais pas l'intention de ce ton! sur un phhhhooone

Cela semblait en colère haha ​​mais je comprends votre point et je partage vos questions sur comment / pourquoi ce sera dangereux

Ça commence à se sentir comme un boogyman dont le comportement est irrationnel et imprévisible

Je suis désolé, mais nous travaillons sur un guide avec des suggestions spécifiques depuis plus d'un mois maintenant. Veuillez nous donner le temps de les collecter et de les publier sous forme d'article de blog. Il est également difficile de discuter sans les alphas réels avec lesquels jouer, ce sur quoi nous avons également travaillé dur.

Nous devons donc soit ne rien dire du tout, soit avertir à l'avance de choses qui ne fonctionneront pas bien. Nous nous trompons du côté de l'avertissement, mais je peux voir à quoi il peut sembler que nous vous rendons la tâche plus difficile. Je suis sûr qu'une fois le code sorti et que vous pourrez jouer avec, vous verrez ce que nous voulons dire, et cela aura plus de sens.

En quoi cela serait-il dangereux (et de quelle manière)?

Avez-vous eu la chance de regarder mon discours ? Ce sera un peu difficile à expliquer si vous n'en avez pas vu la deuxième partie, car il ne serait pas clair pourquoi nous faisons cela. Alors je vous demande de le regarder. J'espère que mon exposé vous convaincra que nous visons à résoudre une large catégorie de problèmes qui ont tourmenté React depuis le début, et que ces fonctionnalités valent la peine de revoir certaines hypothèses auxquelles nous nous sommes peut-être habitués.

En supposant que vous ayez vu le discours, voici une explication plus précise de ce cas particulier. Afin de pouvoir «suspendre» le rendu comme je l'ai montré dans la démo, React doit pouvoir appeler render() à tout moment, potentiellement avec différents accessoires. Par exemple, si vous pouvez définir this.props et this.state sur des accessoires d'un nouvel écran (qui est en cours de chargement), appelez render , puis définissez-le sur l'ancien this.props et this.state lors du rendu en réponse à une interaction sur la version courante de l'arbre (par exemple si j'appuie sur quelque chose pendant le chargement du nouvel écran).

En asynchrone, la règle empirique est la suivante: seuls les cycles de vie comme componentDidMount , componentDidUpdate et componentWillUnmount et les rappels de référence s'exécutent à des moments bien définis dans le temps avec des accessoires et des états qui correspondent à ce qui est sur l'écran. Heureusement, nous n'avons que quelques autres cycles de vie qui ne correspondent pas parfaitement à cette image, et nous leur présentons de meilleures alternatives ( getDerivedPropsFromState , getSnapshotBeforeUpdate ). Ce sera une migration progressive. Encore une fois, tout sera dans le billet de blog.

Passons maintenant à la racine de ce problème. En mode asynchrone, React ne garantit pas quand et dans quel ordre il appelle la méthode render . Ce qui est vraiment quelque chose que React n'a jamais garanti en premier lieu - c'était juste le même ordre à chaque fois. Stocker un champ dans render puis le lire dans un cycle de vie n'est pas «sûr» car vous pourriez stocker un champ au moment où React a appelé render avec différents accessoires (comme pour un arbre suspendu qui n'est pas encore prêt).

Il devrait y avoir un moyen facile d'accéder ou d'appeler le contexte dans les méthodes du cycle de vie.
Oui, cela peut être résolu en enveloppant notre composant dans un autre composant! Mais cela ressemble plus à une solution de contournement qu'à une solution.

Je comprends qu'il se sent comme il est une enveloppe supplémentaire, mais il est ce qui rend le nouveau fast contexte. Si nous n'avions pas de nœuds wrapper explicites dans l'arborescence, nous ne pourrions pas «trouver» rapidement les composants qui doivent être mis à jour.

Si vous avez besoin d'accéder au contexte dans le cycle de vie, prenez-le comme accessoire.

class Button extends React.Component {
  componentDidMount() {
    alert(this.props.theme);
  }

  render() {
    const { theme, children } = this.props;
    return (
      <button className={theme ? 'dark' : 'light'}>
        {children}
      </button>
    );
  }
}

export default React.forwardRef((props, ref) => (
  <ThemeContext.Consumer>
    {theme => <Button {...props} theme={theme} ref={ref} />}
  </ThemeContext.Consumer>
));

C'est presque le même nombre de lignes qu'une définition contextTypes .

Oui, cela peut être résolu en enveloppant notre composant dans un autre composant! Mais cela ressemble plus à une solution de contournement qu'à une solution.

Je voulais juste confirmer ce que Dan a dit que l'approche fonction enfant / prop de rendu est l '_API officielle_ du nouveau contexte - alors veuillez l'utiliser et laissez React s'inquiéter de la rapidité. (Ce sera!)

En quoi cela serait-il dangereux (et de quelle manière)?

Le projet de documentation sur le mode strict aborde également certaines des raisons pour lesquelles la mutation de l'instance (qui n'est qu'un autre type d'effet secondaire) est dangereuse en mode asynchrone.

Nous avons une branche expérimentale qui suit les lignes directrices proposées ici. Quelqu'un peut-il jeter un coup d'œil pour voir si cela a du sens? https://github.com/commodityvectors/react-mapbox-gl/pull/11

Je ne suis pas familier avec cette bibliothèque, donc je ne sais pas si les gens utilisent jamais des références avec ses composants - mais s'ils le faisaient, le mixin withContext sur ce PR pourrait être un bon cas d'utilisation pour le nouvelle API forwardRef .

C'est logique. Merci pour la référence. Je vais clore ce problème pour le moment.

Je viens de rencontrer ce problème parce que j'ai essayé de voir si je pouvais réaliser la même chose.

Donc, d'après ce que je peux tirer de tout cela, il n'est pas possible dans le composant qui utilise le Context.Consumer d'accéder à l'API en dehors de la fonction de rendu enfant. J'ai trouvé quelque chose qui pourrait fonctionner pour rendre tout cela un peu plus facile (j'apprécierais vraiment quelques commentaires si ce n'est pas une bonne pratique pour une raison quelconque):

const MapElement = (props) => (
  <Context.Consumer>
    {context =>
      <RunOnLifecycle
        runOnMount={() => { /*use context*/ }}
        runOnUnMount={() => { /*use context*/ }}
        runOnUpdate={(prevProps) => { /*use context - compare prevProps with props */ }}
        { ...props }
      />
    }
  </Context.Consumer>
)

Et ce composant d'aide <RunOnLifecycle/> :

export interface IPropsRunOnLifecycle {
  runOnMount?: () => void;
  runOnUpdate?: (prevProps: object) => void;
  runOnUnMount?: () => void;
  children?: JSX.Element | ReactNode;
  [prop: string]: any;
}

export class RunOnLifecycle extends React.Component<IPropsRunOnLifecycle> {
  componentDidUpdate(prevProps, prevState, snapshot) {
    if (this.props.runOnUpdate != null) {
      this.props.runOnUpdate(prevProps);
    }
  }

  componentDidMount() {
    if (this.props.runOnMount != null) {
      this.props.runOnMount();
    }
  }

  componentWillUnmount() {
    if (this.props.runOnUnMount != null) {
      this.props.runOnUnMount();
    }
  }

  render() { return this.props.children || null; }
}

Vous vous demandez si cela va causer des maux de tête sur toute la ligne. Cela ressemble toujours à un React assez standard, même s'il s'agit d'un hack.

Il existe des différences subtiles qui pourraient faire de cette approche une mauvaise idée. Par exemple, si MapElement était un composant de classe qui utilisait des références, les références ne seraient pas encore définies lors de l'exécution du rappel runOnMount .

😄 Je suggérerais plutôt d'utiliser une approche HOC pour cela:
https://reactjs.org/docs/context.html#consuming -context-with-a-hoc

Le seul inconvénient réel de l'utilisation d'un HOC pour ce genre de chose a été atténué par l'API forwardRef :
https://reactjs.org/docs/react-api.html#reactforwardref

Nous avons adopté l'approche comme les documents de réaction et ce que les gens ont dit ici. Cela fonctionne bien pour nous jusqu'à présent.

https://github.com/commodityvectors/react-mapbox-gl/blob/master/src/Map.js#L63

Il existe des différences subtiles qui pourraient faire de cette approche une mauvaise idée. Par exemple, si MapElement était un composant de classe qui utilisait des références, les références ne seraient pas encore définies lors de l'exécution du rappel runOnMount.

Merci pour les commentaires @bvaughn . Pour le moment, je l'utilise uniquement comme une sorte de composant proxy d'état qui ajoute / supprime des éléments de l'interface utilisateur en fonction de ce qui est monté dans l'arborescence de contexte. Un peu comme des portails mais dans l'arborescence des composants React. Donc, ne pas rendre du tout des enfants ou avoir affaire à des arbitres.

Je garderai à l'esprit si je dois faire quelque chose qui interagit avec les arbitres.

Salut tout le monde,

J'ai besoin de données de contexte dans les méthodes du cycle de vie. donc, j'ai suivi l'approche HOC après avoir vu les premiers commentaires et passé les données de contexte comme accessoires.
Tout fonctionne comme prévu. Mais maintenant, je veux écrire des cas de test unitaires pour les composants mais je suis incapable de le faire.

J'apprécierais vraiment si quelqu'un pouvait partager comment je peux écrire des cas de test pour ce scénario.

J'utilise enzyme, enzyme-adapter-react-16 et jest mais j'ai quelques difficultés à le faire.

@AmnArora

Dans l'entreprise pour laquelle je travaille, nous faisons ce qui suit (notez que ce n'est peut-être pas le consensus), nous exportons également le composant "nu", puis nous l'importons dans nos tests et passons manuellement les accessoires.

Par exemple

// MyComponent.js
export class MyComponent extends Component { /* ... */ }
export default HOC()(MyComponent)

// MyComponent.spec.js
import { MyComponent } from '...'

// OtherComponents.js
import MyComponent from '...'

En outre, en ajoutant à cette discussion, nous avons rencontré le même problème et avons créé ce https://www.npmjs.com/package/react-context-consumer-hoc qui consomme plusieurs contextes.

Tout fonctionne comme prévu. Mais maintenant, je veux écrire des cas de test unitaires pour les composants mais je suis incapable de le faire.

@AmnArora Pourquoi

@pgarciacamou Tout d'abord merci pour la réponse rapide. Eh bien, après n'avoir rien trouvé sur le Web et posté la requête ici. J'ai proposé la même solution que vous avez mentionnée.

Les cas de test fonctionnent maintenant mais cela semble être une solution. Je vais jeter un œil à https://www.npmjs.com/package/react-context-consumer-hoc et discuter avec mon équipe.

Merci. : 100:

@bvaughn La chose est antérieure lorsque j'utilisais redux pour la gestion de l'état, j'ai copié superficiellement le composant et utilisé les méthodes dive () et instance () pour obtenir l'instance du composant.

Mais aucune de ces méthodes n'était disponible lors de l'utilisation de l'API contextuelle.

Et quand je n'utilisais aucune de ces méthodes, j'obtenais l'erreur suivante: _unknown node with tag 12_

Je t'ai eu.

Ces deux problèmes semblent indiquer que la version d'Enzyme que vous utilisez ne prend pas correctement en charge la nouvelle API de contexte. C'est malheureux.

J'ai eu un dégoût massif pour redux et unistore (beaucoup de pollution de code / pièces mobiles supplémentaires imo), ce qui m'a conduit à la configuration suivante qui permet à nos composants imbriqués d'accéder à un seul état global. Tout le reste qui ne devrait pas être dans l'état global (c'est-à-dire les valeurs d'entrée de texte, les valeurs de bascule) est stocké dans l'état local de chaque composant imbriqué.

https://github.com/davalapar/session-context

Salut,

ce problème est-il résolu?

J'ai un scénario où j'avais 3 composants. Créateur, affichage, cellules.
La cellule a ma logique de rendu qui est utilisée à la fois dans Creator et Display.

Actuellement, je dois transmettre le statut si l'élément est en cours de création ou s'il doit s'afficher. J'ai utilisé des cellules à différents endroits, je dois donc transmettre le statut en tant qu'accessoires séparément. Je voulais donc utiliser le contexte pour l'état, mais le problème est que je voulais modifier le contexte uniquement si le composant d'affichage était monté. Pouvons-nous y parvenir avec les versions actuelles de React? (J'utilise React 16.7)

Il y a eu quelques commentaires ci-dessus montrant comment accéder aux valeurs Context.Consumer dans componentDidMount . Les avez-vous essayés? N'ont-ils pas fonctionné pour une raison quelconque?

Notez que React 16.6 a ajouté une nouvelle API contextType pour les classes, ce qui facilite la lecture du nouveau contexte dans componentDidMount .

https://reactjs.org/docs/context.html#classcontexttype

Ouais, à condition que vous n'ayez besoin que d'un seul contexte dans votre composant - contextType est une option pratique.

Notez que React 16.6 a ajouté une nouvelle API contextType pour les classes, ce qui facilite la lecture du nouveau contexte dans componentDidMount .

Ce ne est pas. Même si un seul type de contexte suffit, Class.contextType rompt l'héritage. La même chose est vraie pour HOC.

Nous sommes assez explicites dans nos documents sur la recommandation de composition plutôt que d'héritage pour la réutilisation du code entre les composants. Au-delà de cela, je ne comprends pas vraiment ce que vous dites.

L'API contextType _does_ certainement facilite l'accès aux valeurs de contexte dans componentDidMount (c'est ce dont parle ce fil).

Nous sommes assez explicites dans nos documents sur la recommandation de composition plutôt que d'héritage ...

C'est trop large ...

Le cas avec lequel je me bats en ce moment, c'est que j'ai une famille de composants avec un tas de fonctionnalités communes nécessaires pour prendre en charge leur mise en œuvre. Tout est parfaitement modélisé par héritage, sauf ... les bits de contexte!

Étant donné qu'il semble que je ne joue avec le contexte que dans des situations comme celle-ci, l'API de contexte est assez frustrante.

... c'est le sujet de ce fil ...

Oui, ce commentaire est légèrement hors sujet.

Changer contextType avec la classe de contexte interrompt le magasin de redux: /

Notez que React 16.6 a ajouté une nouvelle API contextType pour les classes qui facilite la lecture du nouveau contexte dans componentDidMount.

Ouais, à condition que vous n'utilisiez qu'un seul contexte dans votre composant - contextType est une option pratique.

N'existe-t-il aucun moyen de composer des contextes avant de les affecter à MyCoolComponent.contextType ?

Ma lecture est que pour l'instant, si nous voulons un composant qui peut:

a) Consommez plusieurs contextes
b) Utilisez des éléments de ces contextes dans des méthodes autres que render

Cela signifie que nous sommes bloqués avec le modèle décrit où le wrapper consomme le contexte et transmet les accessoires à l'enfant.

Je pense qu'une situation idéale serait que je puisse écrire quelque chose comme ça, et tirer le meilleur parti des deux mondes (c'est-à-dire de multiples contextes disponibles dans toute la classe):

MyCoolComponent.contextType =  composeContexts(OneContext, TwoContext, RedContext, BlueContext)

Est-ce qu'il y a un moyen de faire ça?

Cela fonctionne pour la méthode de rendu, mais ne fonctionne pour aucune autre méthode .... une idée ??

Héy.
Existe-t-il une possibilité d'utiliser la nouvelle API de contexte dans le constructeur d'un composant de classe?

Nous migrons nos projets de la v15.x vers la v16.x, l'une des tâches est d'utiliser la nouvelle API contextuelle
Dans notre projet, nous utilisons css-modules + isomorphic-style-loader, ce dernier expose certaines API pour injecter les feuilles de style des composants dans le DOM.

Dans la V15, nous mettons ces API dans l'ancienne API de contexte et laissons chaque composant l'obtenir via quelque chose comme

    class MyComp extends Component {
        static contextTypes = {
                insertCss: PropTypes.func
           }
         ....
         componentWillMount () {
                // insert a style tag for this component
               this.removeCss = this.context.insertCss(myStyles)
         }
    }

En V15, nous pouvons mettre cela dans le componentWillMount. Cela garantira que le composant aura un style correct avant le rendu.

Dans la version 16, cependant, le composantWillMount est marqué comme dangereux et sera désapprouvé à l'avenir.
Donc, nos pensées immédiates seraient de placer notre appel context.insertCss dans le constructeur du composant.

Cependant, vu du document ,

Si contextTypes est défini dans un composant, les méthodes de cycle de vie suivantes recevront un paramètre supplémentaire, l'objet context:

constructeur (accessoires, contexte)

Cette utilisation (avec le contexte comme 2ème paramètre) sera également obsolète.

J'ai essayé la nouvelle api de contexte, en attribuant MyComp.contextType = StyleContext
Pourtant, je trouve que j'obtiens this.context n'est pas défini dans le constructeur.

    class MyComp extends Component {
        static contextType = StyleContext

         constructor (props) {
             super(props)
             console.log(this.context) // undefined
         }

    }

Existe-t-il un guide pratique sur la façon d'utiliser le contexte dans le constructeur?

Aucun conseil?

Héy.
Existe-t-il une possibilité d'utiliser la nouvelle API de contexte dans le constructeur d'un composant de classe?

Nous migrons nos projets de la v15.x vers la v16.x, l'une des tâches est d'utiliser la nouvelle API contextuelle
Dans notre projet, nous utilisons css-modules + isomorphic-style-loader, ce dernier expose certaines API pour injecter les feuilles de style des composants dans le DOM.

Dans la V15, nous mettons ces API dans l'ancienne API de contexte et laissons chaque composant l'obtenir via quelque chose comme

    class MyComp extends Component {
        static contextTypes = {
                insertCss: PropTypes.func
           }
         ....
         componentWillMount () {
                // insert a style tag for this component
               this.removeCss = this.context.insertCss(myStyles)
         }
    }

En V15, nous pouvons mettre cela dans le componentWillMount. Cela garantira que le composant aura un style correct avant le rendu.

Dans la version 16, cependant, le composantWillMount est marqué comme dangereux et sera désapprouvé à l'avenir.
Donc, nos pensées immédiates seraient de placer notre appel context.insertCss dans le constructeur du composant.

Cependant, vu du document ,

Si contextTypes est défini dans un composant, les méthodes de cycle de vie suivantes recevront un paramètre supplémentaire, l'objet context:

constructeur (accessoires, contexte)

Cette utilisation (avec le contexte comme 2ème paramètre) sera également obsolète.

J'ai essayé la nouvelle api de contexte, en attribuant MyComp.contextType = StyleContext
Pourtant, je trouve que j'obtiens this.context n'est pas défini dans le constructeur.

    class MyComp extends Component {
        static contextType = StyleContext

         constructor (props) {
             super(props)
             console.log(this.context) // undefined
         }

    }

Existe-t-il un guide pratique sur la façon d'utiliser le contexte dans le constructeur?

Aucun conseil?

Vous pouvez faire comme ça au lieu d'utiliser contextType

class MyComponent extends React.Component {
   render(){
       const {
         //props including context props
       } = this.props;
       return(<View />);
   }
};

const withContext = () => (
  <MyContext.Consumer>
    { (contextProps) => (<MyComponent {...contextProps}/>)}
  </MyContext.Consumer>
);

export default withContext;

Pour ceux qui comme moi ont du mal à l'utiliser en dehors de votre fonction de rendu, utilisez simplement ce qui suit dans votre sous-composant:

useContext ()

Par exemple:

const context = useContext(yourContext)

MainComponent.Subcomponent = () => {
 const context = useContext(context)

  useEffect(()=> {
    console.log(context)
  })
}