Как файлы index.js работают в каталогах компонентов React?

Я только что начал новый проект React и решил использовать этот шаблон, который в основном группирует файлы в соответствии с их соответствующим компонентом:

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

Меня смущает то, как index.js работает в этом случае. Как указано:

Файлы index.js содержат удобные точки входа для компонентов. Несмотря на то, что они добавляют шум, они упрощают импорт.

То, что статья не делает, - это глубина того, что внутри этих файлов. В случае Editable компонента, как бы выглядели Editable.jsx и index.js?

Ответ 1

Ну, это точная структура предполагает, что, например, компонент Editable будет иметь все об этом компоненте внутри Editable.jsx. и я имею в виду, что ваш код компонента остается внутри этого файла.

Теперь какой индекс? Внутри индекса вы бы просто сделали что-то вроде этого:

import Editable from './Editable.jsx';

export default Editable;

и это буквально это. Это полезно, потому что внутри других компонентов или контейнеров вы можете это сделать:

import Editable from '../Editable';

потому что он пытается получить доступ к файлу index.js по умолчанию, поэтому вам не требуется больше информации. Он автоматически index.js файл index.js который импортирует сам фактический компонент. Если у вас не было файла index.js вам пришлось бы это сделать:

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

который, честно говоря, неловко. Теперь мне лично не нравится иметь индексный файл, который все, что он делает, это импортировать компонент и экспортировать его. Обычно я использую весь код компонента внутри файла index.js без необходимости в Editable.jsx. Теперь, если вам так нравится, что вы предпочитаете подход, который вам больше нравится.

Ответ 2

Вы также можете использовать его для пространств имен модулей, например

//MyNamespace/index.js

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

export{
  Mod1,
  Mod2
}

Затем в других файлах вы можете импортировать с пространством имен:

//SomeOtherFile.js

import * as NamespaceToUse from './MyNamespace'

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

Ответ 3

Вы также можете сократить это с помощью:

export { default } from "./Component"

Ответ 4

Если вы используете этот каталог для каждого шаблона компонента в поисках чистого способа организации и доступа к своим модулям, то приведенный выше пример с экспортом по умолчанию не будет работать с несколькими файлами, например; эта структура с каталогом редуктора:

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

Таким образом, redurs/index.js будет выглядеть примерно так:

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

export { filterReducer, todoReducer, theme };

... независимо от того, были ли они изначально экспортированы как файлы по умолчанию или именованные файлы в их исходных файлах, теперь они называются экспортированными и могут быть аккуратно использованы в App.js следующим образом:

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

Таким образом, мы можем избежать всего этого шума:

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