前端开发人员的 5 个基本实践（React 版）

介绍

踏上新的职业旅程往往伴随着兴奋和满怀期待。然而，当面对一个如同混乱拼图的代码库时，现实可能截然不同。为了缓解这种常见情况，尤其是对于高级开发人员而言，采用特定的最佳实践至关重要。这不仅可以确保代码质量，还能让您展现出一丝不苟的专业人士形象，从而在公司内部获得认可和晋升。

1. 最佳路径处理：绝对路径优于相对路径

想象一下，在迷宫中摸索前行，只有“后退四步，然后左转两次”之类的神秘线索。这就是代码中相对路径的感受。与其如此，不如拥抱绝对路径的强大力量！它提供了文件的完整地址，使导入过程清晰明了，让您免于无休止的猜谜游戏。设置它们可能需要使用 Webpack 或 TypeScript 等工具进行一些配置，但相信我们，这一切都是值得的。

额外提示：对于使用 create-react-app 的项目，一个简单的 jsconfig.json 文件就能帮你搞定。只需几行代码，你就能定义一个用于导入的基本 URL，将那个庞大的路径 ../../../../../components/Button 转换成简洁的 @/components/Button。

如果您使用 TypeScript，请将以下配置添加到“tsconfig.json”文件中：

{
  "compilerOptions": {
    "baseUrl": "src",
    "paths": {
      "@/*": ["src/*"]
    }
  },
  "include": ["src"]
}

通过这样做，您可以转换如下所示的代码片段：

//from this
import { Button } from '../../../../components/Button'
import { Icon } from '../../../../components/Icon'
import { Input } from '../../../../components/Input'
Into something cleaner and easier to read, like:
//to this
import { Button } from '@/components/Button'
import { Icon } from '@/components/Icon'
import { Input } from '@/components/Input'

2. 精简模块组织：“出口桶”的力量

使用“导出桶”技术（也称为“重新导出”），代码的可读性和维护性得到了显著提升。在文件夹中创建一个“index.js”（或 TypeScript 的“index.ts”）文件并导出所有模块，可以简化导入并增强代码组织。
实现示例：
假设有一个“components”文件夹，其中包含“Button.tsx”、“Icon.tsx”和“Input.tsx”。利用“导出桶”，您可以创建一个“index.ts”文件来简化导入：

export * from './Button'
export * from './Icon'
export * from './Input'

这种做法不仅减少了单独导入的需要，而且有助于形成更清晰、更易于理解的代码库——这对于中型到大型项目至关重要。

3. 在“导出默认”和“命名导出”之间进行选择

当我们深入探讨“出口桶”这个话题时，必须注意的是，它可能与“出口违约”的使用相冲突。如果这还不清楚，我将举例说明：

让我们回到我们的组件：

export const Button = () => {
  return <button>Button</button>
}
export default Button
export const Icon = () => {
  return <svg>Icon</svg>
}
export default Icon
export const Input = () => {
  return <input />
}
export default Input

假设每个组件都在一个单独的文件中，而你想一次性导入它们。如果你习惯了默认导入，可以尝试如下方法：

import Button from '@/components'
import Icon from '@/components'
import Input from '@/components'

然而，这样做是行不通的，因为 JavaScript 无法确定使用哪个“export default”，从而导致错误。你只能这样做：

import Button from '@/components/Button'
import Icon from '@/components/Icon'
import Input from '@/components/Input'

然而，这抵消了“导出桶”的优势。如何解决这个难题？解决方案很简单：使用“命名导出”，即不使用“默认”导出：

import { Button, Icon, Input } from '@/components'

与“导出默认设置”相关的另一个关键问题是重命名导入内容的能力。我将分享一个我职业生涯早期的真实案例。我接手了一个 React Native 项目，之前的开发人员对所有界面都使用了“导出默认设置”。这些界面名为“登录”、“注册”和“忘记密码”。然而，这三个界面都是彼此的副本，只做了微小的修改。问题在于，在每个界面文件的末尾，都有一个“导出默认登录”的字样。这导致了混乱，因为路由文件导入是正常的：

import Login from '../../screens/Login'
import Register from '../../screens/Register'
import ForgotPassword from '../../screens/ForgotPassword'

// Further down, the usage in routes:

  {
    ResetPassword: { screen: ResetPassword },
    Login: { screen: LoginScreen },
    Register: { screen: RegisterScreen },
  }

但是打开屏幕文件时，它们都导出相同的名称：

const login() {
  return <>tela de login</>
}
export default Login
const login() {
  return <>tela de registro</>
}
export default Login
const login() {
  return <>tela de esqueci minha senha</>
}
export default Login

这造成了维护方面的噩梦，人们不断感到困惑，需要极其警惕才能避免错误。

总而言之，强烈建议在项目中大多数情况下使用“命名导出”，仅在绝对必要时才使用“导出默认值”。在某些情况下，例如 Next.js 路由和 React.lazy，可能需要使用“导出默认值”。然而，在代码清晰度和满足特定需求之间取得平衡至关重要。

4. 正确的文件命名约定

假设您有一个包含以下文件的组件文件夹：

-

-components:
----Button.tsx
----Icon.tsx
----Input.tsx

现在，假设你想将这些组件的样式、逻辑或类型分离到单独的文件中。你会如何命名这些文件？一个显而易见的方法可能是：

--components:
----Button.tsx
----Button.styles.css
----Icon.tsx
----Icon.styles.css
----Input.tsx
----Input.styles.css

当然，这种方法看起来可能有些混乱，难以理解，尤其是当你打算将组件进一步划分为不同的文件（例如逻辑或类型）时。但是，如何保持结构的条理性呢？解决方案如下：

--components:
----Button
------index.ts (exports everything necessary)
------types.ts
------styles.css
------utils.ts
------component.tsx
----Icon
------index.ts (exports everything necessary)
------types.ts
------styles.css
------utils.ts
------component.tsx
----Input
------index.ts (exports everything necessary)
------types.ts
------styles.css
------utils.ts
------component.tsx

这种方法可以轻松识别每个文件的用途，并简化了所需内容的搜索。此外，如果您使用 Next.js 或类似框架，则可以调整文件命名以指示该组件是用于客户端还是服务器端。例如：

--components:
----RandomComponent
------index.ts (exports everything necessary)
------types.ts
------styles.css
------utils.ts
------component.tsx
----RandomComponent2
------index.ts (exports everything necessary)
------types.ts
------styles.css
------utils.ts
------component.server.tsx

这样，区分组件是用于客户端还是服务器端就变得非常简单，无需打开代码进行验证。组织和标准化文件命名对于保持项目开发的清晰度和效率至关重要。

5. 正确使用 ESLint 和 Prettier 进行代码标准化

想象一下，你和十多位同事一起开发一个项目，每个人都从过去的经验中汲取各自的编码风格。这时，ESLint 和 Prettier 就派上用场了。它们在维护整个团队的代码一致性方面发挥着至关重要的作用。

Prettier 就像代码格式的“守护者”，确保每个人都遵守项目设定的样式指南。例如，如果项目标准规定使用双引号，您就不能简单地选择单引号，因为 Prettier 会自动替换它们。此外，Prettier 还可以执行各种其他修复和格式化操作，例如代码对齐、在语句末尾添加分号等等。您可以在官方文档 Prettier 选项中查看具体的 Prettier 规则。

另一方面，ESLint 会对代码强制执行特定规则，从而帮助维护代码库的内聚性和一致性。例如，它可以强制使用箭头函数而非常规函数，确保 React 依赖项数组正确填充，禁止使用“var”声明，而应使用“let”和“const”，并应用驼峰式命名规范。您可以在官方文档中找到具体的 ESLint 规则：ESLint 规则。

ESLint 和 Prettier 的结合使用有助于维护源代码的一致性。如果没有它们，每个开发人员都会遵循自己的风格，这可能会导致将来的冲突和维护困难。设置这些工具对于项目的长远发展至关重要，因为它有助于保持代码的条理性和易于理解。如果您尚未使用 ESLint 和 Prettier，请认真考虑将它们纳入您的工作流程，因为它们将极大地造福您的团队和整个项目。

结论：

通过将这些最佳实践融入到你的 React 开发工作流程中，你将能够构建一个更井然有序、更易读、更易于维护的代码库。请继续致力于提升编码标准，如果你觉得这些实践有用，别忘了点赞🦄！祝你编码愉快！🚀