Disable react/no-multi-comp?

[dcousens]

The react/no-multi-comp rule disallows multiple react classes from being declared per JS file.
IMHO this actually encourages a more Java-like approach, and forces you to start nesting your file structures deeply rather than flat, as small components (a few lines at best) start reaching out into the file system instead.
Or worse, it seeds a habit of avoiding extracting them at all and instead in-lining them into the parents render function.

I personally think this is frustrating, and should be removed.

Thoughts?

[jprichardson]

Yep, I hate this and agree with @dcousens :p

[jprichardson]

"hate" may have been a bit strong :) Actually, this may deserve a bit of a discussion. At first, it really bothered me. Eventually I've gotten use to it. I'm working on a pretty big React application and I could see how this will really bother me when I start refactoring my components. Overall, I still think that this rule should not be enforced i.e. multiple components should be allowed in one file.

[feross]

I have no opinion on this since I don't use React. I changed the rule as you guys requested.

[dcousens]

ping @cesarandreu [penny for your] thoughts?

[cesarandreu]

I think it's fine to disable it, I don't have a strong opinion about it since I haven't built anything really large with React yet.

But I'd love to see an example of a cases where you think it's better to have multiple class definitions in the same file. So far when I've broken stuff up in a file I've just used static functions that take the expected props and return some DOM elements :D.

[dcousens]

@cesarandreu

So far when I've broken stuff up in a file I've just used static functions that take the expected props and return some DOM elements :D.

That will fail if you want to use things like context without mixing concerns in the top level class.
Often, these small classes will be quickly extracted if they become generic or re-usable.

[winkler1]

From https://speakerdeck.com/vjeux/why-does-react-scale-jsconf-2014

Facebook recommends having a component per file, with the name matching the component name -- so there is no grepping for file contents, but a quick predictable mapping.

[dcousens]

Facebook recommends having a component per file, with the name matching the component name -- so there is no grepping for file contents, but a quick predictable mapping.

I guess that is subjective to your IDE, I have no problems switching around between files, and often use stateless pure functions for mini-components in React. The 1-class-per-file idiom might be necessary if you have thousands of classes in a project, but, I personally work more modular than that, and this would be very frustrating to have enforced.

@winkler1 if you want to continue discussion on this, please open an issue in https://github.com/feross/eslint-config-standard-react.

[cesarandreu]

FWIW, after using React for a while and trying to keep a single component per file... You realize how much of a terrible idea it is. Breaking up components in the same file just makes it easier to reason about what the overall thing represented in the file, even if it's broken up into multiple components. Otherwise you need to crawl through ten different files to understand where data is going.

[winkler1]

^ agree for quick personal stuff. For big work codebases, one component per file works a lot better IMO.

[cesarandreu]

Even when the components are tightly coupled? Breaking up a bunch of tightly coupled components that aren't meant to be reusable doesn't really make sense. I break off components when they're reusable, but it helps to break up large components into smaller parts, and composing them while keeping em in the same file.

I've tried the "one component per file" approach and moved away from it because it made it too difficult to understand how anything worked. You either end up with huge complicated components, or you end up having to chase through ten different files.

[dcousens]

^ agree for quick personal stuff. For big work codebases, one component per file works a lot better IMO.

Disagree, the entirety of my experience using React has been for now-in-production projects, and in that, I closely align with @cesarandreu, extraneous files for no reason leads to code bloat and monolithic style project management.
If you have re-usable code, extract it out. If its tightly coupled, let it stay that way, don't try and hide that fact by spreading complexity outwards.