WebWeekly：《React 代码整洁之道》

当前期刊数: 34

本期精读的文章是：React 代码整洁之道。

1 引言

编程也是艺术行为，当我们思考代码复用、变量命名时，就是在进行艺术思考。

可能这篇文章没法提高面试能力、开发效率，因为涉及的内容都是 “软能力”。但如果与我一样，时常害怕自己代码不够优雅，那就在茶余饭后看看这篇文章，也许，可以解决一部分你心中的困惑。

2 内容概要

作者整理了几个好的思维习惯，尝试认同它，再看看如何实践。

不冗余

避免重复代码段，对 JSX 同理：

// Dirty
const MyComponent = () => (
  <div>
    <OtherComponent type="a" className="colorful" foo={123} bar={456} />
    <OtherComponent type="b" className="colorful" foo={123} bar={456} />
  </div>
);

// Clean
const MyOtherComponent = ({ type }) => (
  <OtherComponent type={type} className="colorful" foo={123} bar={456} />
);
const MyComponent = () => (
  <div>
    <MyOtherComponent type="a" />
    <MyOtherComponent type="b" />
  </div>
);

但也不要过度优化，过度优化和搞破坏没什么区别。

可预测、可测试

如果使用 Jest 测试，可以考虑截图测试插件：Jest Image Snapshot

自我解释

尽可能减少代码中的注释。可以通过让变量名更语义化、只注释复杂、潜在逻辑，来减少注释量，同时也提高了可维护性，毕竟不用总在代码与注释之间同步了。

// Dirty
const fetchUser = (id) => (
  fetch(buildUri`/users/${id}`) // Get User DTO record from REST API
    .then(convertFormat) // Convert to snakeCase
    .then(validateUser) // Make sure the the user is valid
);

// Clean
const fetchUser = (id) => (
  fetch(buildUri`/users/${id}`)
    .then(snakeToCamelCase)
    .then(validateUser)
);

上面的例子，方法 convertFormat 含义是 “转换格式”，太过于笼统，以至于不得不添加注释。如果换成 snakeToCamelCase （转换为驼峰风格），这个名字就解释了自己的功能。

斟酌变量名

布尔值或者返回值是布尔类型的函数，命名以 is has should 开头：

// Dirty
const done = current >= goal;
// Clean
const isComplete = current >= goal;

函数以其效果命名，而不是怎么做的来命名

// Dirty
const loadConfigFromServer = () => {
  ...
};
// Clean
const loadConfig = () => {
  ...
};

很多时候我也经常犯这种错误，毕竟写代码的时候总要考虑实现，一不小心就将实现的方式带入了函数名中。

遵循设计模式

这里的设计模式，并不是指工程上的，而是更广泛的开发中的设计模式，比如 “你应该使用 tslint 校验代码格式” “typescript 开启 stricts 模式” “编写一个 React 函数，应当将 React 作为 peerDependency” 等等（当然，不要随意设置 peerDependency 也是一种江湖约定）。

对于 React，遵循以下几个最佳实践：

单一责任原则, 确保每个功能都完整完成一项功能，比如更细粒度的组件拆分，同时也更利于测试。
不要把组件的内部依赖强加给使用方。
lint 规则尽量严格。

根据我的体验，尤为痛恨违背第二条的组件，比如当 React 组件使用了数据流，但必须依赖项目初始化该数据流才能执行，如果不是被生活所迫，我才不会使用这种组件。

第三条也一样，如果你是一个知名轮子的作者，请毫不留情的使用最严格的 lint 规则。如果使用者的 lint 规则比你还严格，你的组件将无法使用。

考虑到以上几点并不会降低编码速度

编写整洁的代码在开始一定会放慢开发速度，因为你需要转变自己的思维模式，但随着不断迭代，它的带来的效率提升会逐渐弥补前面的损失，并不断带来开发效率的提升。

写组件库也是同理，用脚写固然能快速完成，但后续往往要重构掉。我很羡慕函数式工作环境的开发者，他们几乎只要为每个功能写一遍，剩下的就是记住并调用它。

在 React 中的实践

略过几个没意思的例子。。

在 React 使用 defaultProps 代替在代码中动态判断

显然，利用 React 组件的规则，将入参的默认值预先定义好是最高效的。但顺带一句，如果在 ts 最严格的 stricts 模式里，依然会报错：变量可能未定义。这是因为 defaultProps 依然是个约定，而不能通过强类型推导出，目前还没有更优雅的解决思路。

渲染与判断逻辑分开

// Dirty
class User extends Component {
  state = { loading: true };

  render() {
    const { loading, user } = this.state;
    return loading
      ? <div>Loading...</div>
      : <div>
          <div>
            First name: {user.firstName}
          </div>
          <div>
            First name: {user.lastName}
          </div>
          ...
        </div>;
  }

  componentDidMount() {
    fetchUser(this.props.id)
      .then((user) => { this.setState({ loading: false, user })})
  }
}

// Clean
import RenderUser from './RenderUser';
class User extends Component {
  state = { loading: true };

  render() {
    const { loading, user } = this.state;
    return loading ? <Loading /> : <RenderUser user={user} />;
  }

  componentDidMount() {
    fetchUser(this.props.id)
      .then(user => { this.setState({ loading: false, user })})
  }
}

逻辑与渲染分离，便于维护，其次便于测试。

当然有人可能会问 “就算逻辑与渲染分离了，但组成的大组件不还是逻辑耦合的吗”，对，这就像函数单一指责一样，render 是过程代码，但过程中涉及到的逻辑，分配给单一指责的渲染组件渲染，如果把逻辑与渲染写在一起，就类似一个函数把功能全做完，这样做显然诸事不利。

提倡无状态组件

// Dirty
class TableRowWrapper extends Component {
  render() {
    return (
      <tr>
        {this.props.children}
      </tr>
    );
  }
}

// Clean
const TableRowWrapper = ({ children }) => (
  <tr>
    {children}
  </tr>
);

性能是一个原因，原文比较强调性能与代码量。我认为 stateless 重点在于阻碍了内部状态的使用，移除了生命周期，所以提高了组件的可控性，也就拓宽了组件的使用场景。

受控与非受控组件都有其适用场景，像非常基础的底层组件库，往往倾向提供两套机制，通过 value 与 defaultValue 决定是否受控。拥有这样能力的组件源码就没法通过 stateless 写，所以无状态组件的面向对象并不是基础底层组件，而且这些基础组件也没必要完全无状态，两者都提供是最好的选择。

说到这，也就是考虑到成本问题，那么无状态组件也就更适合上层具有业务含义的组件。页面级别组件状态太多，不适合，所以我认为无状态组件比较适合 Wrapper 层，也就是对基础组件包裹并增强业务能力这一层。

解构

// Dirty
const splitLocale = locale.split('-');
const language = splitLocale[0];
const country = splitLocale[1];

// Clean
const [language, country] = locale.split('-');

ES6 新增的语法可以提升不少代码可读性，需要刻意训练去培养这个习惯。

3 精读

本周精读已经融于内容概要中 ^_^。最后推荐在 typescript 中开启 strict 模式，强制使用良好的开发习惯。

// Bad
onChange(value => console.log(value.name))
// Dirty
onChange((value) => {
  if (!value) {
    value = {}
  }
  console.log(value.name)
})
// Clean
onChange((value = {}) => console.log(value.name))
// Clean
onChange(value => console.log(value?.name))

不要信任任何回调函数给你的变量，它们随时可能是 undefined，使用初始值是个不错的选择，但有的时候初始值没什么意义，使用 ?. 语法可以安全的访问属性，是时候抛弃 _.get 了。

4. 总结

我要回去重构代码了，你呢？

《React 代码整洁之道》