`react/no-multi-comp` does not seem to work correctly with hooks and `ignoreStateless`

[elliott-king]

Hello. Hopefully this is the correct place to ask.

I am trying to use the react/no-multi-comp rule:

    "rules": {
        ...
        "react/no-multi-comp": ["error", {"ignoreStateless": true}]
    }

As I understand it, this should NOT allow two components in one file that both use state. For example, I would expect this to fail, but it passes:

import React, { useState } from "react";

const FirstStateful = () => {
  let [bool, setBool] = useState("a");
  return <button onClick={() => setBool(!bool)}>{String(bool)}</button>;
};

const SecondStateful = () => {
  let [counter, setCounter] = useState(1);
  return <button onClick={() => setCounter(counter + 1)}>{counter}</button>;
};

const FirstNotStateful = ({ content }) => {
  return <p>{content}</p>;
};

const SecondNotStateful = ({ content }) => <p>{content}</p>;

Note that if I change the rule to "react/no-multi-comp": ["error", {"ignoreStateless": false}], it does mark everything after the first one as an error.

Additionally, I noticed that there was a recent commit affecting no-multi-comp, so I cloned eslint & retried this with a local dependency, still no dice.

[ljharb]

All functional components are stateless; the naming of the useState hook is irrelevant (hook state is stored in a side channel of the element, not part of an instance of the function).

the name of the option “ignoreStateless” predates hooks, when functional components were universally called “SFCs”.

[elliott-king]

I feel like that is obeying the letter of the law, not the spirit. The purpose of the linter rule is to prevent cluttering your files. As I user of eslint, I am more concerned about organization than the exact implementation of state.

If I were to convert class components into functional, this rule would previously restrict my class components, but would no longer do so afterwards. The technical details seem reasonable, but it would be an odd experience change for the user.

This is of course your project, I don't wish to strain the patience of OSS maintainers. I just ask that you reconsider this with respect to a user's consistency.

[ljharb]

I’m not sure what you’re asking - whether a component has state or not has zero bearing on any of the motivation this rule. The purpose of the option was to allow multiple small functional components in the same file with what was historically a primary class component.

[elliott-king]

Okay, I see. I understand now, thanks!