Javascript: Putting a Component into Index.jsx may be a bad practice

Created on 19 Sep 2019  Β·  2Comments  Β·  Source: airbnb/javascript

Hello,
I like your guidelines but one think when I was using React in 2017 that I was confused about (#1316) is still a problem in my opinion : how we name our Components.
Okay so in #1316 we see we're lacking a convention name for container vs pure components :

It's a fine question. I don't think this guide should proscribe a strict naming convention here. Having CardContainer seems fine, but I've also seen ConnectedCard, or StatefulCard, etc.

Also according to this comment https://github.com/airbnb/javascript/issues/1316#issuecomment-282886376

One of them should be Card/index.jsx (lowercase index, always) - whether the stateful or stateless one is the index depends on which one you consistently want to import from elsewhere in the app.

Raises another concern : when my stateless component who was index.jsx is not what should be imported anymore but now it's my stateful I need to change index.jsx's content to something totally different (incredibly confusing in commits). Then I move up the state of a component so my folder should now mainly exports a stateless component so index.jsx now holds a dumb component and not a smart anymore.
Directly changing index.jsx's content is tedious, very confusing in the commits and for the team.
Moreover having 100 components all called index.jsx if freaking annoying in editors or IDEs (even those who are smart enough to show me the folder's name before the index.jsx are wasting space doing so and usually I see index.jsx more clearly than I see the folder's name)

The answer to both problems is there https://medium.com/@Charles_Stover/optimal-file-structure-for-react-applications-f3e35ad0a145
Basically index.jsx becomes a simple file which imports then exports : cleaner commits and you edit files with meaningful names. Especially that he also answer another problem how to name components based on whether they're statefull or stateless

my-app
└── src
└── components
└── component-name
β”œβ”€β”€ component-name.css
β”œβ”€β”€ component-name.scss
β”œβ”€β”€ component-name-container.js
β”œβ”€β”€ component-name-redux.js
β”œβ”€β”€ component-name-styles.js
β”œβ”€β”€ component-name-view.js
└── index.js

If index.js becomes a simple import/exports file then giving guideline to how to name component may make sense because every single stateless and stateful components now have meaningful name : no more wait... should I search for component-name/index or component-name/view to get the stateless you always search component-name-TYPE you always see on your screen component-name-TYPE.
It's a game changer in my opinion.
Just my 2 cents sorry if you talked about it already I didn't see related issues.

Most helpful comment

Okay despite the fact I don't totally agree with you and will stick with the way described in the medium article I'm glad that you took your time to answer me :)

All 2 comments

The re-export approach is wasteful and is the reason treeshaking becomes needed in the first place.

An IDEs’ failure to handle index filenames better (in tans or autocompletes or jump to file) means the IDE should improve; I’d suggest filing issues for your ide.

As for having to refactor - i agree that if everyone is used to Foo being stateful or stateless and you invert that, it’s confusing. The only way to avoid that in general in software is to pick a naming convention and never change it - in this case, a statefulness convention for index files.

Okay despite the fact I don't totally agree with you and will stick with the way described in the medium article I'm glad that you took your time to answer me :)

Was this page helpful?
0 / 5 - 0 ratings