封装在于抽象，抽象程度决定层次

<div className="level-1" style={{ background: 'red' }}>
  <div className="level-2">
    <div className="level-3"></div>
  </div>
</div>

权衡background放在哪里时，就是在考虑层次的问题。

1

封装是个很接地气的女娃子，毕竟要以实用为主，理论为辅，在她面前所谓的代码规范也要礼让三分。
狗蛋定义规范:函数的形参要以arg开头，为了和函数内部的变量区分开，例如:

  private showChatModal(argName: string) {
    this.setState({
      name: argName,
    });
  }

尽管很多场景下，这种规范显得很蹩脚，但狗蛋依然觉得自己是在践行规范，感到无比的骄傲和自豪，自己没有贪图一时方便，多么的伟大...

用argName还是name这也是封装吗?
这当然是！
这当然是！
这当然是！

2

封装可不仅仅是把一段代码抽离出来放进一个函数内

一行代码也是一种封装

const isUpdate = !!hero.id

hero对象中有id属性则是修改，没有id 属性则是添加(通常，id都是字符串)
众所周知，两个!是相互抵消，只是把一个非boolean转换为boolean

const isAdd = !hero.id

const isUpdate = Boolean(hero.id)

您觉得那个更好呢。

封装还可在文件夹的结构上体现

hero
  index.less
  index.tsx

hero
  hero.less
  hero.tsx
  index.tsx

前者index.tsx 等同于后者hero.tsx+index.tsx，文件在编辑器、开发者工具都不具备很好的区分性。
作为入口文件的index.tsx 承担了过多的代码，而它只应该决定hero文件夹对外提供的形态

至此，可以说封装是前端的全部。

3

封装是一种投资，资本是时间

一段代码因为业务变化，修改后的样子

  private renderUserInput() {
    const { level } = this.state;
    let input;
    if (level === 1) {
      input = (
        <Input placeholder="级别1" onChange={this.onlevel1Change}></Input>
      );
    } else if (level === 2) {
      input = (
        <Input placeholder="级别2" onChange={this.onlevel2Change}></Input>
      );
    } else {
      input = (
        <Input placeholder="级别3" onChange={this.onlevel3Change}></Input>
      );
    }
  }
 return input;

咦，每一个 input就是变了个placeholder 和 onChange ，您觉得有没有必要改成

 <Input placeholder={placeholder} onChange={onChange}></Input>

咦，这种结构为什么不用switch...

封装还难在一个度字上

必须要强调渐进式封装的重要性，体验痛楚未尝不是件坏事，如果不知道怎么封装就千万不要封装。
过渡封装无疑是最为致命的，程序员变成了傀儡，不如去复制、黏贴。

重复的逻辑在未来有的救，在新的代码上运用新的封装，旧的代码可以逐步替换，业务没有变动不去改动也无妨，因为改必然要对应同等规模的测试。

开发产品是给用户去使用的，说白了，用户不看代码，所以，为了封装导致项目延期，甚至在线上造成了bug，是万万不可取的。

而且，没有完美的代码，更没有完美的封装，总要有些取舍，谁也不是一下生就跑步出来的。

4

那封装重不重要呢。

当然重要
当然重要
当然重要

复制、黏贴不仅累，还容易出错，你总是要改动一些地方，或者这复制一点，那复制一点。
可怕的是都错了还要一个个改，不同的团队成员你实现一遍，我实现一遍，不知道谁会被坑...
一来影响心情，二来降低效率，程序员心情不好可就很难输出了，离职的前奏...

没怎么封装的代码是给一个成长的机会，过度封装的代码是给一个变得成熟的机会。

阳光总在风雨后嘛，当然，我们不能去埋怨写出这些代码的人，你永远不知道他经历了什么，换做是我们，不一定会比他做的更好。

封装的规律也在于此，需要拨茧抽丝，逐步的看清本质，从而一针见血、招招致命。

5

封装的透明性、可扩展性、易读性。
封装不能过于依赖现有的业务逻辑。
封装要往前看一看。
封装重复的逻辑，而非封装重复的代码。
宁可不封装也不要过渡封装。

这些定义的话单拿出来说和屁话也差不了多少，后续的章节中会结合具体的例子，和大家共同探讨怎样更好的封装。

诸天气浩荡，我道日兴隆

轻松一刻