Как файлы 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';