是否有基于React的项目的官方样式指南或命名约定？

Question

我正在与我的团队一起建立一个React项目，该项目将使用mobX作为状态管理器以及TypeScript。

我已经在React Projects中看到了常见的模式和命名模式：

1. 非反应文件夹和文件：camelCase或kebab-case
2. 反应（在components文件夹内）：PascalCase

在react中是否有文件夹/文件命名的正式约定？如果没有，是否有基于该模式的样式指南？还是大多数情况下都使用此功能的原因？

Answer 1

没有官方指南。大多数项目采用 PascalCase 作为 React 组件的原因是为了模仿该文件的主要导出。React 组件按照约定采用 PascalCased，当使用 jsx 时，pascal 大小写变为强制（实际上只有大写首字母变为强制）。其余文件的 comeCase 或 kebab-case 只是遵循一般 javascript 项目更常见的偏好。

Answer 2

React 没有官方的风格指南。但您可以使用eslintAirBnb 的 React 最流行的配置。

在此处阅读更多信息https://github.com/airbnb/javascript/tree/master/react

Answer 3

只是加上我的两分钱。正如其他人所说，文件结构是不受限制的。但是，组件命名不是。他们应该是PascalCase为应对知道你是否正在使用function，class或HTML element†。

例如：

class input extends Component {...}

不好！为什么？因为React不知道您是要使用input元素还是基于类的组件。

这就是为什么您会看到PascalCase组件的原因：

class Input extends Component {...}

†有一个例外，您可以在其中使用dot notation。例如，如果您有多个导出并将它们全部导入为fields，则可以执行以下操作：

组件/字段/ index.js

import React, { Component } from 'react';

export class input extends Component {
  state = { value: "" };

  handleChange = ({ target: { value } }) => {
    this.setState({ value });
  };

  render = () => (
    <input type="text" value={this.state.value} onChange={this.handleChange} />
  );
}

export class textarea extends Component {
  state = { value: "" };

  handleChange = ({ target: { value } }) => {
    this.setState({ value });
  };

  render = () => (
    <textarea
      type="text"
      value={this.state.value}
      onChange={this.handleChange}
    />
  );
}

组件/App/index.js

import React, { Fragment } from 'react';
import * as fields from "../fields";

const App = () => (
  <Fragment>
     <fields.input />
     <fields.textarea />
   <Fragment>
);

export default App;

一般而言，我dot notation完全避免使用。感觉笨拙，可能会使其他不了解fields其结构的开发人员感到困惑。另外，我不喜欢在一个文件中堆叠多个组件，然后将它们作为一堆导入。此外，该文件可能会变得很大且导航和调试很麻烦（请参见下文）。

就是说，为了保持结构简单，我喜欢将主目录保持小写：

??? dist // compiled application files to be served
|   ??? css
|   |   ??? main.[contenthash:8].css
|   |   ??? main.[contenthash:8].css.map
|   ??? js
|   |   ??? main.[hash].js // depending on app size, this may contain multiple js files for code splitting
|   |   ??? main.[hash].js.map
|   ??? media
|   |   ??? [hash].[ext] // static assets like fonts and images
|   ??? favicon.ico
|   ??? index.html
|
??? config // supporting "webpackdevserver" configuration files
|   ??? devServer.js
|   ??? envs.js
|   ??? optimization.js
|   ??? output.js
|   ??? paths.js
|   ??? plugins.js
|   ??? rules.js
|
??? public
|   ??? favicon.ico
|   ??? index.html
|
??? src
|   ??? actions // redux actions
|   ??? components // stateful and stateless reusable components that just display "stuff" -- stateful components change and manipulate the UI
|   ??? containers // stateful components that utilize the reusable "components" to CRUD data and/or are connected to redux
|   ??? images
|   ??? pages // utilize components/containers to display something when visiting a "/route"
|   ??? reducers // redux reducers
|   ??? root // aka "<App />" that combines "routes", redux and other top-level supporting files into one place
|   ??? routes // assigns "pages" to a "/route"
|   ??? styles // shared and/or global styles used by all "components"
|   ??? types // redux types
|   ??? utils // supporting app files: like test setup, custom polyfills, axios configurations, ...etc
|   ??? index.js // a simple file that "ReactDOM.render"s the "App"
|
??? server.js // express setup to serve the "dist" folder
??? webpack.config.js

然后在该component文件夹中，我将PascalCase我的组件表示为类似以下内容：

??? components
    ??? Input
        ??? __tests__
        |   ??? Input.test.js // jest unit tests for "index.js"
        ??? index.js // all required code/styles to be exported
        ??? styles.scss // styles required by "index.js"

为什么是这种结构？

• 可重用的组件，可随时随地使用。
• 与之相关的所有内容都Input包含在此文件夹中。因此，我可以将其交给某人，他们可以将其放入其应用程序中并使用它。
• Webpack已设置为自动导入index.js，因此导入非常容易，而无需遍历大量嵌套文件：（import Input from 'components/Input';而且，js由于“ index.js”包含所有必需的代码，因此无需指定要使用的确切文件）。

缺点：

• 您将有很多小文件夹。
• 编译错误将全部包含index.js术语，因此乍一看对于“ index.js”失败的原因可能会造成混淆。

我曾经做过的另一种方法是：

??? components
    ??? input // lowercase name to delineate it's a "pure" function -- the actual function will be a PascalCased "Input"
    |   ??? input.test.js // jest unit tests for "input.js"
    |   ??? input.js // all required code/styles to be exported
    |   ??? styles.scss // styles required by "input.js"
    |
    ??? Sidebar // PascalCase because it's a "class"
        ??? Sidebar.test.js // jest unit tests for "Sidebar.js"
        ??? Sidebar.js // all required code/styles to be exported
        ??? styles.scss // styles required by "Sidebar.js"

为什么是这种结构？

• 可重用的组件，可随时随地使用。
• 与之相关的所有内容都Input包含在此文件夹中。因此，我可以将其交给某人，他们可以将其放入其应用程序中并使用它。
• 取决于主文件夹，它描述了组件是a function还是a class。
• 发生编译错误时，我确切知道是哪个文件导致了该错误。

缺点：

• 您将有很多小文件夹。
• 有时组件可以从有状态变为无状态（反之亦然），因此，如果您严格要求并坚持使用这种命名模式，则必须更新主文件夹以反映更改，这意味着您还需要更新使用此文件的任何其他文件的路径。
• 导入可能看起来有些冗长和冗长： import Input from 'components/input/input.js';

其他一般准则：

• 避免默认导出匿名函数：

默认导出的匿名函数的示例：

export default () => (
  <p>Anonymous Function</p>
);

为什么？因为在测试时，该功能将在酶中显示为：

<_default />

当一个组件中有多个匿名函数时，哪个是哪个！

<_default />
<_default />
<_default />

• 避免使用冗长的文件（150行或更少的行数），因为这会导致阅读/理解困难，甚至调试起来更加麻烦。

我发现，通常情况下，如果适当地进行优化，大多数组件将在100行以下。最坏的情况是我将不得不创建小的子组件来补充主要组件。但！更容易阅读和调试。

什么更容易阅读：

Example＃1（34行带有补充子组件）

Example＃2（所有318行）

示例1模仿读书。粘贴在一起的多个页面可提供易于阅读的体验。与示例＃2相比，它读起来像一英里长的滚动条，很容易迷路！

• 样式表可以是蛇形或驼峰式。

这可能会造成混淆，但是这完全取决于您如何应用样式。如果您只是这样导入样式：

import "./styles.css";

然后，您可以使用蛇形保护套：

<input className="snake-case" type="text" value="" onChange={this.handleChange} />

但是，如果您使用css modules，则需要使用camelCase：

import { camelCaseClassName } from "./styles.css";

为什么？由于捆绑器（如Webpack）不支持蛇形进口：

<input className={camelCaseClassName} type="text" value="" onChange={this.handleChange} />

结论：创建文件夹结构的方法有很多种，其中有一些提示和技巧来保持逻辑流程。只要选择一个最适合您并且不会干扰您身边工作的人！

换句话说，KISS ===“保持简单，愚蠢！”