Acabo de comenzar un nuevo proyecto de React y decidí usar este patrón, que básicamente agrupa los archivos según su componente respectivo:
├── 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.jsLo que me confunde es cómo funciona index.js en este caso. Como se cita:
Los archivos index.js están ahí para proporcionar puntos de entrada sencillos para los componentes. Aunque añaden ruido, simplifican las importaciones.
Lo que el artículo no hace es profundizar en lo que hay dentro de estos archivos. En el caso del componente Editable, ¿cuál sería el aspecto ideal de Editable.jsx e index.js ?
Esta estructura exacta sugiere que, por ejemplo, el componente Editable tendría todo sobre ese componente dentro de Editable.jsx . y quiero decir que el código de su componente permanece dentro de ese archivo.
Ahora, ¿para qué sirve el índice? Dentro del índice, simplemente haría algo como esto:
import Editable from './Editable.jsx'; export default Editable;y eso es. Esto es útil porque dentro de otros componentes o contenedores puede hacer esto:
import Editable from '../Editable'; porque intenta acceder al archivo index.js de forma predeterminada, por lo que no requiere más información de usted. Importaría automáticamente el archivo index.js que importa el componente real en sí. Si no tuviera un archivo index.js , habría tenido que hacer esto:
import Editable from '../Editable/Editable'; lo cual es un poco incómodo. No me gusta tener un archivo de índice que todo lo que hace es importar un componente y exportarlo. Lo que suelo hacer es simplemente tener todo el código de mi componente dentro del archivo index.js sin la necesidad de Editable.jsx en absoluto. Eso depende de usted, así que siéntase libre de tomar el enfoque que más le guste.
Si uno está usando este directorio por patrón de componente buscando una forma limpia de organizar y acceder a sus módulos, entonces el ejemplo anterior con una exportación predeterminada no funcionará con varios archivos, por ejemplo; esta estructura con un directorio reductor:
── reducers │ ├── todoReducer.js │ └── filterReducer.js │ └── themeReducer.js │ └── index.js ├── components ├── App.js ├── app.css └── index.jsEntonces reducers/index.js se vería así:
// index.js import filterReducer from './filterReducer'; import todoReducer from './todoReducer'; import theme from './themeReducer'; export { filterReducer, todoReducer, theme };...ya sea que se exportaron originalmente como archivos predeterminados o con nombre en sus archivos originales, ahora se denominan exportaciones y se pueden usar limpiamente en App.js de la siguiente manera:
// App.js import { filterReducer, todoReducer, theme } from '../reducers';Así podemos evitar todo este ruido:
import filterReducer from './reducers/filterReducer'; import todoReducer from './reducers/todoReducer'; import theme from './reducers/theme';También puede aprovecharlo para espacios de nombres de módulos, por ejemplo
//MyNamespace/index.js import Mod1 from './Mod1' //assumes ./Mod1.js import Mod2 from './Mod2' //assumes ./Mod2.js export{ Mod1, Mod2 }Luego, en otros archivos, puede importar con un espacio de nombres:
//SomeOtherFile.js import * as NamespaceToUse from './MyNamespace' // Then access as: NamespaceToUse.Mod1 NamespaceToUse.Mod2