The organization of components in the project

Many are guided by the recommendations of the Presentational and Container Components , but the distinguished author admits in footnotes that the concept of separation is controversial, and the components can be mixed. And if so, why drag a suitcase without a handle? It is more convenient to store all project components in one shared folder. What are the advantages:

• Easy file system navigation.
• The unique names of the components of the project.
• Import without pain ('../../../../../ ..').

When the project grows up, you should split it up into private npm-packages, encapsulating the implementation. But not to grow a tree of subfolders inside the folder of components - to develop and maintain this significantly more difficult. Verified

All components are organized by domain principle in one src / componens folder. For example, you can define domains: Post - display the publication, PostForm - form of editing the publication.

How to create a domain component - src / components / Post / Post.js.

Why you cannot use index.js instead of Post.js - the uniqueness of the component file names within the project is observed, navigation of the editor tabs is simplified (and WebStorm will have the valuable "Find Usages" function for the context menu of the selected file - see the note).

All components in the domain component folder receive the domain component prefix (Post * .js).

Subfolders in the domain component folder are not allowed, inside there is a flat structure of files from descendant components (PostTitle.js, PostBody.js) and ancestor components (PostViewPage.js, PostListPage.js). The descendant components are used inside the domain component, and the ancestor components are used outside (in the router, for example).

To import domain components, you should set your package.json inside each domain component folder, in which you must set the entry point "main":

{ "name": "Post", "version": "0.0.0", "private": true, "main": "./Post.js", } 

In addition, within the domain component file (Post.js), the re-export of ancestor components is declared:

 import PostViewPage from './PostViewPage' import PostListPage from './PostListPage' //... export { PostViewPage, PostListPage } export default Post 

Unfortunately, you cannot use the "export from" construction (WebStorm restriction), for example:

 export { default as PostViewPage } from './PostViewPage' 

As a result, no explicit access to files within the components folder is required, for example:

 import Post from 'components/Post/Post' 

By convention, it is allowed to use imports only by the name of the domain component:

 import Post, { PostViewPage, PostListPage } from 'components/Post' 

Sources

A note on the "Find Usages" feature in WebStorm. There are at least three usage contexts: 1) by the selected file, 2) by the selected variable or symbol, 3) by the selected default in the export of the component.

1) Select the components / Post / PostViewPage.js file, the search result:

 // Post.js import PostViewPage from './PostViewPage' 

2) Select the PostViewPage symbol inside the PostViewPage.js file, the search result:

 // PostViewPage.js PostViewPage.propTypes = {} 

3) Select the default in the export of the PostViewPage component, the search result:

 // routes.js import { PostViewPage } from 'components/Post' <Route exact path="/post/:id(\d+)/" component={PostViewPage} /> 

As you can see, the third method of use yields the most useful information for the ancestor component.

PS

 import MyComponent from 'components/MyComponent' 

 ['module-resolver', { 'root': ['src'] }] 

 { "compilerOptions": { "target": "ES6" }, "exclude": [ "node_modules" ] }