ESLint - Le composant doit être écrit comme une fonction pure (fonction de préférence / sans état)

ESLint me donne cette erreur sur un projet react.

ESLint - Composant doit être écrite comme une fonction pure (réagir préfèrent/apatrides fonction)

Il pointe à la première ligne du composant.

export class myComponent extends React.Component {
render() {
    return (

      //stuff here

    );
  }
}

Comment puis-je me débarrasser de cette erreur?

source d'informationauteur JakeBrown777

  1. 17

    Deux choix.

    Temporairement désactiver l'avertissement (non testé, il y a plusieurs façons de le faire)

    //eslint-disable-next-line prefer-stateless-function
export class myComponent extends React.Component {
  ...
}

    Écrire comme un pur apatrides composant

    La valeur de retour est utilisé comme render méthode d'une classe de composant:

    export const myComponent = () => {
  return (
    //Stuff here
  )
}

    (Ou de l'utilisation non-ES6 notation si c'est votre truc.)

    Pour les composants comme ça avec aucun autre logique, je préfère le rendement implicite, par exemple,

    export MyComponent = () =>
  <div>
    //Stuff here
  </div>

    C'est une question de préférence. Je dirais que vous devriez suivre Réagir conventions de nommage, bien que, et de conserver tous les composants en commençant avec une majuscule.

    Si vous avez besoin d'accessoires, ils sont transmis comme argument de la fonction:

    const MyComponent = (props) =>
  <div>
    <Something someProp={props.foo} />
  </div>

export MyComponent

    Et vous pouvez se déstructurent dans le paramètre:

    const MyComponent = ({ foo }) =>
  <div>
    <Something someProp={foo} />
  </div>

    Cela peut rendre l'implicite de retour un peu plus facile si vous avez été en utilisant les vars.

  2. 3

    Écrire votre composant comme un apatride en fonction:

    export myComponent = () => { //stuff here };

    Il y a en fait deux types de définition de composants à Réagir: composants Fonctionnels (qui sont juste des fonctions de accessoires à Réagir), et des composants de classe.

    La principale différence entre eux est que les composants de classe peut avoir state et du cycle de vie des méthodes telles que componentDidMountcomponentDidUpdateetc.

    Chaque fois que vous n'avez pas besoin de l'état du cycle de vie des méthodes, vous devez écrire votre composant comme un apatride en fonction, en tant qu'apatrides composants sont en général plus facile de raisonner sur.

    À écrire une composante fonctionnelle, vous écrivez une fonction qui prend un seul argument. Cet argument va recevoir le composant d'accessoires. Par conséquent, vous n'utilisez pas this.props pour accéder au composant de accessoires - il suffit d'utiliser la fonction de l'argument.

  3. 1

    Si tout ce que vous faites est rendu un jsx modèle, et de ne pas déclarer l'état avec constructor(props)ensuite, vous devez écrire votre composant comme une pure fonction des accessoires, et ne pas utiliser le class mot pour la définir.

    ex.

    export const myComponent = () => (
   //jsx goes here  
);
  4. 1

    Vous obtiendrez cette erreur uniquement lorsque votre classe n'a pas de cycle de vie de méthode ou d'un constructeur.
    Pour résoudre cela, vous devez désactiver la fibre de biens ou d'en faire une fonction pure ou créer constructeur de la classe.

  5. 1
    const myComponent = () => {
return (
  //stuff here

  );
};

export default myComponent;

    Et dans app.js fichier il suffit d'importer ce composant, comme nous le faisons pour la classe comme

    import myComponent from './myComponent.js'

    et de l'appeler comme

    <myComponent />

    Il va travailler pour vous.

  6. 1

    Si vous comptez sur propsalors il y a de mieux (un peu défendable, de cette écriture) moyen de corriger cette erreur sans écrire Apatrides fonctions - par la rédaction d'un PureComponent et à l'aide de cette eslint règle [source]:

    "react/prefer-stateless-function": [2, { "ignorePureComponents": true }],

    Avec la règle ci-dessus, le fragment de code suivant est valide (car il dépend de props)

    class Foo extends React.PureComponent {
  render() {
    return <div>{this.props.foo}</div>;
  }
}

    Réagir équipe de plans pour la construction d'optimisations autour de SFC, mais ils ne sont pas encore là. Jusqu'à ce qu'il se passe, SFCs n'offre plus d'avantages que la PureComponents. En fait, ils seront légèrement plus mauvais qu'ils ne seront pas éviter le gaspillage rend.