Comment fonctionnent les fichiers index.js dans les répertoires de composants React ?

Question

Je viens de commencer un nouveau projet React et j'ai décidé d'utiliser ce qui regroupe essentiellement les fichiers en fonction de leur composant respectif :

├── 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

Ce qui me trouble, c'est la façon dont index.js fonctionne dans ce cas. Comme cité :

Les fichiers index.js sont là pour fournir des points d'entrée faciles pour les composants. Même s'ils ajoutent du bruit, ils simplifient les importations.

Ce que l'article ne fait pas, c'est d'aller en profondeur dans ce qui est à l'intérieur de ces fichiers. Dans le cas du composant Editable, qu'est-ce qui serait Editable.jsx et index.js ressemblerait idéalement ?

Answer 1

Eh bien, ces structures exactes suggèrent que, par exemple, les Editable aurait tout ce qui concerne ce composant à l'intérieur Editable.jsx . et je veux dire que le code de votre composant reste à l'intérieur de ce fichier.

A quoi sert l'index ? À l'intérieur d'index, vous feriez simplement quelque chose comme ceci :

import Editable from './Editable.jsx';

export default Editable;

et c'est littéralement tout. C'est utile car vous pouvez le faire dans d'autres composants ou conteneurs :

import Editable from '../Editable';

parce qu'il essaie d'accéder au index.js par défaut, ce qui ne nécessite pas d'informations supplémentaires de votre part. Il importera automatiquement le index.js qui importe le composant lui-même. Si vous n'avez pas de index.js vous auriez dû le faire :

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

ce qui est honnêtement un peu gênant. Personnellement, je n'aime pas avoir un fichier index qui ne fait qu'importer un composant et l'exporter. Ce que je fais habituellement c'est d'avoir tout mon code de composant à l'intérieur du fichier index.js sans avoir besoin de l'option Editable.jsx du tout. C'est à vous de décider, alors n'hésitez pas à adopter l'approche qui vous convient le mieux.

Answer 2

Si l'on utilise ce répertoire par modèle de composant en cherchant une façon propre d'organiser et d'accéder à vos modules, alors l'exemple ci-dessus avec une exportation par défaut ne fonctionnera pas avec plusieurs fichiers, par exemple, cette structure avec un répertoire de réducteur :

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

Alors réducteurs/index.js ressemblerait à quelque chose comme ça :

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

export { filterReducer, todoReducer, theme };

...qu'ils soient exportés par défaut ou nommés dans leurs fichiers d'origine, ils sont maintenant des exportations nommées, et peuvent être utilisés proprement dans App.js comme suit :

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

Ainsi, nous pouvons éviter tout ce bruit :

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

Answer 3

Vous pouvez également l'utiliser pour les espaces de noms des modules, par exemple

//MyNamespace/index.js

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

export{
  Mod1,
  Mod2
}

Ensuite, dans d'autres fichiers, vous pouvez importer avec un espace de nom :

//SomeOtherFile.js

import * as NamespaceToUse from './MyNamespace'

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