使用React一年的简单总结！【React系列01】

共 4430字，需浏览 9分钟

· 2021-03-30

关注公众号 前端人，回复“加群”

添加无广告优质学习群

从2017年9月开始我转为前端开发，当时公司没有一个单纯专注前端的开发人员，我接到任务后首先是考虑的是应该使用哪种前端技术（框架）。

在简单对比Angular、Vue 和 React 后，我选择了 React。因为我曾经花了时间了解过，而且我特别喜欢 React 的 JSX 语法和单向数据流绑定方式。本文就简单总结一下这一年我使用 React 的实际经验。

我开始使用 React时的版本是16.0.0，到现在16.5.0，我感受到最大的变化是：

1、新增了Context，翻译为：上下文。有了这个 API 我们可以简单的共享组件间的数据。比如：在向多级子组件传 props 时无需每一级组件都要传递 props。在顶级组件创建了Context.Provider,在任何子组件中使用Context.Consumer就可以获取到顶级组件的props。

2、多种ref的创建方式。在最初，要访问 DOM ，需要在组件增加ref={myRef}，而且 ref 的值只能是string。到现在，我们不仅可以利用原来的方式创建（旧不被官方推荐），还可以 ref={ins => this.myRef = ins} ，ref 的值可以是一个函数；当然还可以这样:

class  extends React.Component {
  constructor(props) {
    super(props);
    this.myRef = React.createRef();
  }
  render() {
    return <div ref={this.myRef} />;
  }

3、在16.3.0版本中，React 组件的生命周期增加了 static getDerivedStateFromProps(),getSnapshotBeforeUpdate(),componentDidCatch(),并且对componentWillReceiveProps()和componentWillUpdate()增加了不安全的前缀，如：UNSAFE_componentWillReceiveProps()。

我们这里不展开讨论这些生命周期API改变给我们日常开发带来的影响。

4、除了上面列出变化，还有 Fragment、异步渲染等等的改变与变化。在短短一年，React 的变化与改进很大，这也要我们开发者需要时刻关注 React 的动态，养成习惯去 React官网查看每个版本的变化日志，这样才有助于改进我们的应用，能更好的掌握 React。

二、掌握Babel 和Webpack的配置

1、Babel 总结

Babel 是现代化前端开发的关键角色，Babel 的存在才使得我们可以用 ES6、ES7，甚至 ES8的新特性来开发前端项目。

因为我们的项目基本是运行在浏览器上的，每个浏览器的 JS 支持情况不一致，当使用Babel把我们的项目代码转译成 ES5，可以最大程度兼容目标浏览器列表。

在2017年，Babel的 presets 需要我们手动引入所需要的包，如：babel-preset-latest、babel-preset-react、babel-preset-es2015和babel-preset-stage-0。很多时候我们很难确定我们具体需要哪个包，因为不知我们会在项目中使用什么新特性。

babel-preset-env的出现改变这一现象，可以根据我们设置的浏览器列表，按需选择语法环境包。尤其现在 Babel7的发布，使得 Babel 配置更加简单了。

2、Webpack 总结

Wepack是工程化前端开发的基础。我创建第一个React SPA 项目的时候，没有使用 CRA(create-react-app),因为我当时觉得，既然我刚接触现代前端开发方式，我就要从零开始学习，那当然是从 Webpack 配置开始学习了。

Webpack作为现在最流行的打包工具，但由于其松散的配置方式和插件化配置使得整个 Webpack配置让人看起来十分复杂，因此让很多人望而却步，不敢真正去了解 Webpack 配置项的意义。其实，Webpack 配置没那么难，尤其现在 Webpack4的出现，可以说可以是零配置了。在项目开始的时候，只需要配置入口，出口、css 加载器和 js 加载器就可以项目运行起来了。至于其他的配置，用到的时候再添加也不迟。

配置优化更加不能急，项目的完成度没有到达90%，谈优化是多余的。这一年来，我项目中 Webpack 配置不知改了多少次了，这种东西并不是说开始配置好了就不用再改动了。所以我们一步一步来，就可以慢慢熟悉整个 Webpack 配置的诀窍了。

三、代码拆分

1、 React组件拆分

我特别喜欢React的组件化开发，在开发过程中我们可以重用组件。当一个页面的功能增多时，代码数肯定飙升的。这个时候我们可以考虑把一些功能拆分出来，不仅使得当前文件代码减少，增加可读性，而且说不定当前拆分的小功能组件可以被其他页面重用，减少重复的工作量。不用害怕拆分，哪怕是一个按钮都可以抽取到一个独立的组件中，比如：在我的项目中，我的一个小小的删除按钮就拆分出来，因为每个删除按钮都需要一个弹窗按钮来包裹，每次写按钮功能时，都要重复的用弹窗组件来包裹，拆分一个自定义的删除按钮就让我们每次只需要引用我们的资金的删除按钮即可。当然，组件的拆分可以拆分成无状态组件、正常功能组件，甚至是自定义业务组件库。我在前面的文章写过自建公司内部的 React 业务组件库，因为这些组件不只是可以在当前项目使用，多个项目实行相同的功能时，不断的 copy 也是增加工作量。

2、逻辑函数拆分

我们都知道一个函数方法只实现一种功能，一般来说每个页面都是特定的功能，但总会存在相同的数据处理方式。这个时候我们创建一个函数库，把常用的数据处理方法抽取出来，在别的页面使用时就可以简单实现了。比如：在判断值是否有效时，虽然是很简单的方法，但每次都要这样判断 null、undefined以及(空串),着实让人感觉麻烦。

3、常量配置的拆分

我们做 SPA，接口作为最大的常量配置项，我们必须用单独的文件来声明这些接口，因为不可能一个接口只用在一个地方，当接口路径改变时，我们只需要在接口声明文件中更改一次即可。而且不能模块的接口需要拆分到不同的文件中，增加可读性。还有其他的一些页面配置声明都可以放到统一目录下（constants目录），这样不仅让项目结构更加清晰，而且增加代码的健壮性。

四、不断的重构、重构

这一年来，项目功能在不断变化，这样也带来项目代码页不断变化，出来不断拆分代码之外。我们要不断的对每个功能的实现方式不断重构，也行以前需要用10行代码才能解决的问题，现在想到了一个更好的方法，只需要5行了。

在我的项目中，我重构最多的是应用的路由，从开始只是使用页面级别的路由，到现在每个组件都使用路由，其中重构的次数不下与10次。

也许我一开始就应该考虑这种路由方式了，但当时是一个简单的项目就没必要搞那么复杂吧。并不是我不想这样做，只是必要性太低了。其实重构的过程，也是对代码进行改进的过程，随着开发时间的增加，对代码使用的理解不一样了，重构让我更升入理解了 React 的一些 API。只要我有空，我就会 review 项目的代码，看看哪些地方可以改进，包括 Babel Webpack 配置的重构。

五、代码规范和团队协作

一个好的项目不只是说功能完成了就可以了，除了不断重构之外，在每次的编码过程中注意编码规范还是十分重要的。

因为代码是写给人看的，自己看的懂的代码，团队成员不一定能看懂。除了代码需要格式化之外，还需要一定的注释，在逻辑复杂的地方增加一定的注释，方便团队成员和日后自己的 review 代码时能看懂该段代码，也会对优化带来启示的。

在 Rect 这样的前端项目中，一般使用 ESLint 进行语法规范、用Prettirer进行代码美化，而且还要对编辑器进行美化编写规则，如.editorconfig,让团队成员的在其编辑器上写出的代码与自己的风格一致。

六、尝试使用高级特性

在项目开发开始阶段中，我们因为专注于业务功能的实现，容易忽略一些功能其实可以用高级特性来实现。这就让我们在重构的过程中考虑是否使用高级特性来替代当前的实现逻辑了。使用高级特性不仅让我们的项目代码简洁、还可以让我更好的理解React、JS 的高级特性，这样的项目开发方式才能最大程度提升自己的水平。

七、使用 TypeScript吧

由于项目开始时，我对 TypeScript 一无所知，压根没考虑过使用 TypeScript 来实现。对应 TypeScript 的有点和在 React 的使用方式，我在前面的文章有写过。现在我最苦恼的是，我很想使用 TypeScript 来开发，但把现在的项目代码转为 TypeScript 的工作量实在太大了。因此，我们应尽可能在项目使用 TypeScript!!!