How do index.js files work in React component directories?

I just started a new React project and decided to use this pattern, which basically groups files according to their respective component:

├── actions
│   ├── LaneActions.js
│   └── NoteActions.js
├── components
│   ├── App
│   │   ├── App.jsx
│   │   ├── app.css
│   │   ├── app_test.jsx
│   │   └── index.js
│   ├── Editable
│   │   ├── Editable.jsx
│   │   ├── editable.css
│   │   ├── editable_test.jsx
│   │   └── index.js
...
│   └── index.js
├── constants
│   └── itemTypes.js
├── index.jsx
├── libs
│   ├── alt.js
│   ├── persist.js
│   └── storage.js
├── main.css
└── stores
    ├── LaneStore.js
    └── NoteStore.js

What's confusing me is how index.js works in this case. As quoted:

The index.js files are there to provide easy entry points for components. Even though they add noise, they simplify imports.

What the article doesn't do is go in depth of what's inside these files. In the case of the Editable component, what would Editable.jsx and index.js ideally look like?


Solution 1:

This exact structure suggests that, for example, the Editable component would have everything about that component inside Editable.jsx. and I mean that your component code stays inside that file.

Now what's index for ? Inside index you would simply do something like this:

import Editable from './Editable.jsx';

export default Editable;

and that's it. This is helpful because inside other components or containers you can do this:

import Editable from '../Editable';

because it tries to access the index.js file by default thus not requiring any more info from you. It would import automatically the index.js file which imports the actual component itself. If you did not have an index.js file you would have had to do this:

import Editable from '../Editable/Editable';

which is kind of awkward. I don't like to have an index file that all it does is import a component and export it. What I usually do is just have all my component code inside the index.js file without the need of the Editable.jsx at all. That's up to you so feel free to take the approach you like better.

Solution 2:

If one is using this directory per component pattern looking for a clean way to organize and access your modules, then the example above with a default export won't work with multiple files, e.g; this structure with a reducer directory:

── reducers
│   ├── todoReducer.js
│   └── filterReducer.js
│   └── themeReducer.js
│   └── index.js
├── components
    ├── App.js
    ├── app.css
    └── index.js

So reducers/index.js would look something like this:

// index.js
import filterReducer from './filterReducer';
import todoReducer from './todoReducer';
import theme from './themeReducer';

export { filterReducer, todoReducer, theme };

...whether originally exported as default or named files in their original files, they are named exports now, and can be used cleanly in App.js as follows:

// App.js
import { filterReducer, todoReducer, theme } from '../reducers';

So we can avoid all this noise:

import filterReducer from './reducers/filterReducer';
import todoReducer from './reducers/todoReducer';
import theme from './reducers/theme';

Solution 3:

You can also leverage it for module namespaces, e.g.

//MyNamespace/index.js

import Mod1 from './Mod1' //assumes ./Mod1.js
import Mod2 from './Mod2' //assumes ./Mod2.js

export{
  Mod1,
  Mod2
}

Then in other files you can import with a namespace:

//SomeOtherFile.js

import * as NamespaceToUse from './MyNamespace'

// Then access as:
NamespaceToUse.Mod1
NamespaceToUse.Mod2