我们采用了以下项目结构
|- pages
|- <page_name>
|- index.js # To do a default export of the main component
|- MainComponent.jsx # Contains other subcomponents
|- main-component.css # CSS for the main component
|- OtherComponents.jsx # more than 1 file for child components that are used only in that page
|- __tests__ # Jest unit and snapshot tests
|- components
|- index.js # Exports all the default components of each component as named exports
|- CommonCmpnt1
|- CommonCmpnt1.jsx
|- common-cmpnt-1.css
|- index.js # To default export the component
|- __tests__
|- CommonCmpnt2
|- CommonCmpnt2.jsx
|- common-cmpnt-2.css
|- index.js # To default export the component
|- __tests__
要澄清的是,没有任何损坏,并且效果非常好。我们的组件可以在components
目录内的多个页面中重复使用,我们在其中导入如下
// Assuming we are inside MainComponent.jsx
// ...
import { CommonCmpnt1 } from '../../components'; // We even take it a step further and use absolute imports
此外,仅使用一次的组件并排放置在其pages
文件夹中。
现在我们面临的唯一问题是热模块重新加载已中断,即,无论何时.jsx
在pages
或components
目录中编辑文件,我们都必须手动重新加载页面以查看生效的更改(这不会影响CSS文件)。这是我们已经习惯的事情,因此不会严重影响我们。
我的问题是,是否有我们不知道的即将发生的灾难?
在为自己寻找适用于NextJS的文件夹结构时偶然发现了这篇文章。我一直在使用类似的结构,但是最近发现这不是您应该使用NextJS的方式。
我对细节不太了解,但是NextJS在页面级别进行了优化。在构建NextJS项目时,您将看到页面记录是构建的一部分。NextJS将文件
pages
夹下的每个组件文件都视为页面,因此,通过将非页面组件放在pages
文件夹中,您的构建时间将大大增加,因为现在NextJS会将这些组件中的每个组件都作为页面进行构建。