前言：在 CI/CD 和 DevOps 领域中，持续交付和持续部署是一个老生常谈的话题，也属于前端工程化的范畴。持续集成这个术语最早是在 1994 年由 Grady Booch 提出。持续集成是借助工具对软件项目进行持续的自动化的编译打包构建测试发布，来检查软件交付质量的一种行为。而持续部署是基于持续交付的优势自动将经过测试的代码推入生产环境的过程。接下来我们主要来聊聊前端工程化中的持续集成服务（CI）。

目前社区已有一些出色的持续集成服务（CI）的选择：

• Jenkins
• Travis CI
• GitLab CI
• CircleCI
• GitHub Actions
• …

下面我们主要介绍一下 GitHub Actions：

它使用起来比较简单，只要在我们的仓库根目录建立.github/workflows文件夹，然后将我们的工作流配置(YAML 文件)放到这个目录下，就能启用GitHub Actions服务。

GitHub Actions 是什么

Github Actions 是 Github 的持续集成服务（CI），在 2018 年 10 月推出。

我们知道，持续集成（CI）由很多操作组成，比如抓取代码、运行测试、登录远程服务器，发布到第三方服务等等。GitHub 把这些操作都称为 actions。

很多操作在不同项目里面是类似的，脚本完全可以共享。因此 GitHub 允许开发者把每个操作写成独立的脚本文件，存放到代码仓库并发布到官方市场，使得其他开发者可以直接引用。

GitHub Actions 基本概念

GitHub Actions 有一些自己的术语：

• workflow （工作流程）：持续集成一次运行的过程，就是一个 workflow。
• job （任务）：一个 workflow 由一个或多个 jobs 构成，含义是一次持续集成的运行，可以完成多个任务。
• step（步骤）：每个 job 由多个 step 构成，一步步完成。
• action （动作）：每个 step 可以依次执行一个或多个命令（action）。

GitHub Actions 使用

它使用起来比较简单，只要在我们的仓库根目录建立.github/workflows文件夹，然后将我们的工作流配置文件（YAML 格式文件）放到这个目录下。（GitHub Actions 的配置文件叫做 workflow 文件，文件名我们可以任意取，后缀名统一为.yml，比如 ci.yml。一个库可以有多个 workflow 文件，GitHub 只要发现.github/workflows目录里面有.yml文件，就会自动运行该文件）

如下是一个需要 CI 运行 yarn ci 的 workflow 文件示例：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58

# name 字段是 workflow 的名称。如果省略该字段，默认为当前 workflow 的文件名
name: ci

# on 字段指定触发 workflow 的条件，通常是某些事件，如下是 push 事件和 pull_request 事件触发 workflow
on:
  push:
    # 指定只有 main 分支发生 push 事件时，才会触发 workflow
    branches: [main]
  pull_request:
    branches: [main]

# jobs 字段，表示要执行的一项或多项任务
jobs:
  # 每一项任务的 job_id，这里是 build 作为 job_id
  build:
    # name 字段是任务的说明
    name: build
    # runs-on字段指定运行所需要的虚拟机环境。它是必填字段。有如下三种
    runs-on: ubuntu-latest
    # runs-on: windows-latest
    # runs-on: macOS-latest

    # steps 字段指定每一项任务的运行步骤，可以包含一个或多个步骤
    steps:
      # 步骤名称
      - name: Checkout
        # 使用的 action
        uses: actions/checkout@v3

      - name: Setup Node.js environment
        uses: actions/setup-node@v3
        # 定义的输入参数，每个输入参数都是一个键/值对
        with:
          node-version: 16

      - name: Cache node modules
        uses: actions/cache@v3
        # 该步骤所需的环境变量
        env:
          cache-name: cache-node-modules
        with:
          path: ./node_modules
          key: ${{ runner.os }}-build-cache-node-modules-${{ hashFiles('**/package.json') }}
          restore-keys: |
            cache-node-modules-
      - name: Run ci
        # 该步骤运行的命令或者 action
        run: |
          yarn
          yarn ci

  # 下面运行顺序依次为：job1、job2、job3
  # job1:
  # job2:
  # needs 字段指定当前任务的依赖关系，即运行顺序
  # needs: job1
  # job3:
  # needs: [job1, job2]

更多语法参考：GitHub Actions 的工作流程语法

示例：npm 包自动发布

因为我也会经常的在 Github 上开源一些工具类，同时需要同步发 布到 npm 上，因此也是希望代码提交后能自动的实现 npm 包的发布。接下来就主要记录一下使用 GitHub Actions 自动发布 npm 包。

eg：hzzlyxx/eslint-config-ts

1、生成 npm Access Token

creating-and-viewing-access-tokens

• 登录 npm 官网，在头像下拉选项中选中 Access Tokens 进入界面

• 点击 Generate New Token 按钮，选择 Automation 或者 publish 选项，再点击 Generate Token 按钮

• 界面提示 Successfully generated a new token! ，复制生成的 token

2、注入 secret

• 点击仓库上 Settings 菜单进入设置界面

• 在左侧菜单栏选中 Secrets/actions 进入，然后点击 New repository secret 按钮，输入表单信息，Name 为 NPM_TOKEN，Value 为上一步生成的 npm Access Token，最后点击 Add Secret 按钮添加完成

3、添加 yml 文件

在仓库根目录建立.github/workflows文件夹，并新建 npm.yml 文件，填写如下内容：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

name: publish

on: [push, pull_request]

jobs:
  publish:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: actions/setup-node@v3
        with:
          node-version: 16
      - name: Npm Publish
      uses: JS-DevTools/npm-publish@v1
        with:
          token: ${{ secrets.NPM_TOKEN }}

4、push 代码

保存上面的文件后，将整个仓库推送到 GitHub。

GitHub 发现了 workflow 文件以后，就会自动运行。然后就可以在仓库的 Actions 菜单查看日志，日志默认保存 30 天。

Tips：package 的 version，是由代码库中的 package.json -> version 指定的， 如果要重新发布，需要手动修改 version 值。

5、npm 上查看

回到 npm 上，查看账户下的 packages。如果有，说明自动发布成功了。

小结

到这，我们的GitHub Actions持续集成服务（CI）就告一段落了，后续还将探索其他 CI 方案以及前端工程化。

参考

• GitHub Actions 入门教程

前言：2020 年 10 月 10 日，webpack5 正式发布，并带来了诸多重大的变更，使前端的构建效率与质量大为提升。最近也是趁着空闲时间把项目里的 webapck4 进行了升级，接下来就介绍一下我的踩坑升级之旅吧。

准备工作

node 版本

Webpack 5 对 Node.js 的版本要求至少是 10.13.0 (LTS)，如果还在使用旧版本的 Node.js，需要进行升级。

升级 webpack

1

yarn add webpack webpack-cli -D

检查依赖是否过期及升级相关包的版本

1

yarn outdated

将会列出package.json所有依赖的版本信息，包括当前安装版本，给予 semver 渴望的版本以及最新的版本。

接下来就说升级所有使用到的 plugin 和 loader 为最新的可用版本。

升级废弃的配置项

如有使用以下的配置项，请升级至最新的版本：

• optimization.hashedModuleIds: true → optimization.moduleIds: 'hashed'
• optimization.namedChunks: true → optimization.chunkIds: 'named'
• optimization.namedModules: true → optimization.moduleIds: 'named'
• NamedModulesPlugin → optimization.moduleIds: 'named'
• NamedChunksPlugin → optimization.chunkIds: 'named'
• HashedModuleIdsPlugin → optimization.moduleIds: 'hashed'
• optimization.noEmitOnErrors: false → optimization.emitOnErrors: true
• optimization.occurrenceOrder: true → optimization: { chunkIds: 'total-size', moduleIds: 'size' }
• optimization.splitChunks.cacheGroups.vendors → optimization.splitChunks.cacheGroups.defaultVendors
• Compilation.entries → Compilation.entryDependencies
• serve → serve 已被移除，推荐使用 DevServer
• Rule.query (从 v3 开始被移除) → Rule.options/UseEntry.options

清理配置

• 将 optimization.moduleIds 和 optimization.chunkIds 从配置中移除，使用默认值会更合适，因为它们会在 production 模式 下支持长效缓存且可以在 development 模式` 下进行调试。
• 将配置中使用的 [hash] 占位符改为 [contenthash]。效果一致，但事实证明会更为有效
• 正则表达式参数的 IgnorePlugin，现已支持传入一个 options 对象：`new IgnorePlugin({ resourceRegExp: /regExp/ })

踩坑记录点

1、webpack-dev-server配置属性变更

• contentBase -> static.directory
• 移除 stats
• 移除 disableHostCheck
• openPage -> open
• before -> onBeforeSetupMiddleware
• after -> onAfterSetupMiddleware
• …

以上列举了一些常用配置修改，具体 v3 升级到 v4 的迁移指南可以查看官方文档 https://github.com/webpack/webpack-dev-server/blob/master/migration-v4.md

2、多入口开启 hot: true 热更新无效

1
2
3

optimization: {
  runtimeChunk: 'single'
},

具体可以查看webpack-dev-server/issues/2792

3、JSON 模块需要使用具名导出

1
2

import pkg from './package.json';
console.log(pkg.version);

4、webpack-merge 变更

1
2
3
4
5

// webpack 4.x
const merge = require('webpack-merge');

// webpack 5.x
const { merge } = require('webpack-merge');

5、optimize-css-assets-webpack-plugin 变更（官方准备弃用了）

使用官方推荐的新插件：css-minimizer-webpack-plugin

1

yarn add css-minimizer-webpack-plugin -D

6、url-loader、file-loader、raw-loader（将来会被淘汰）

官方推荐：资源模块

7、config.module.rules 里配置了 loaders

webpack5 不再支持 loaders 的属性，需要改成 use

1
2
3
4

{
  test: /\.(sc|sa|c)ss$/,
use: ['style-loader', 'css-loader', 'postcss-loader', 'sass-loader'],
}

8、heap-eval-module-source-map 名称修改

需要改成 eval-cheap-module-source-map

9、copy-webpack-plugin 报错

ValidationError: Invalid options object. Copy Plugin has been initialized using an options object that does not match the API schema.

1
2
3
4
5
6
7
8
9
10
11
12
13

module.exports = {
  plugins: [
    // webpack 4.x
    new CopyWebpackPlugin(['public'])

    // webpack 5.x
    new CopyWebpackPlugin({
      patterns: [
        { from: 'public', to: 'public' }
      ]
    })
  ]
}

10、去除 dll

在 webpack5 中已经不建议使用这种方式进行模块缓存，因为其已经内置了更好的 cache 方法

11、cache 持久化缓存

通过配置 cache 缓存生成的 webpack 模块和 chunk，来改善构建速度。

webpack5 默认将构建的缓存结果放在 node_modules/.cache 目录下，可以通过配置更改目录。

1
2
3
4
5
6
7
8
9
10
11
12
13
14

module.exports = {
  cache: {
    // 将缓存类型设置为文件系统
    type: 'filesystem',
    buildDependencies: {
      /* 将你的 config 添加为 buildDependency，以便在改变 config 时获得缓存无效 */
      config: [__filename],
      /* 如果有其他的东西被构建依赖，你可以在这里添加它们 */
      /* 注意，webpack.config，加载器和所有从你的配置中引用的模块都会被自动添加 */
    },
    // 指定缓存的版本
    version: '1.0',
  },
};

Tips:

• cache 的属性 type 会在开发模式下被默认设置成 memory，而且在生产模式中被禁用，所以如果想要在生产打包时使用缓存需要显式的设置。
• 为了防止缓存过于固定，导致更改构建配置无感知，依然使用旧的缓存，默认情况下，每次修改构建配置文件都会导致重新开始缓存。当然也可以自己主动设置 version 来控制缓存的更新。

更多缓存配置可以参考官方文档 https://webpack.js.org/configuration/other-options/#cache

12、Node Polyfill 脚本被移除

webpack4 版本中附带了大多数 Node.js 核心模块的 polyfill，一旦前端使用了任何核心模块，这些模块就会自动应用，但是其实有些是不必要的。

webpack5 将不会自动为 Node.js 模块添加 polyfill，而是更专注的投入到前端模块的兼容中。因此需要开发者手动添加合适的 polyfill。

13、Module Federation

Module Federation 使得使 JavaScript 应用得以从另一个 JavaScript 应用中动态地加载代码 —— 同时共享依赖。相当于 webpack 提供了线上 runtime 的环境，多个应用利用 CDN 共享组件或应用，不需要本地安装 npm 包再构建了。

具体配置可以查看官方文档 https://webpack.js.org/concepts/module-federation/

我的 webpack5 项目配置参考

https://github.com/hzzlyxx/webpack5

总结

webpack5 正式发布已经有段时间了，总的来说：

• 在加构建性能大幅度提升，依赖核心代码层面的持久缓存 cache，可大大加快二次构建速度
• 在打包体积上能有效减少，依赖更优的 Tree Shaking
• 默认支持浏览器长期缓存，降低配置门槛
• 令人激动的新特性 Module Federation，蕴含极大的可能性

参考

• https://webpack.js.org/
• https://webpack.js.org/migrate/5/
• https://github.com/webpack/webpack-dev-server/blob/master/migration-v4.md

上篇我们具体介绍了一些组件库的搭建，这篇我们将介绍一下组件库文档 1.0 的构建生成过程。

需求

首先来看一下组件库文档最基本的一些需求：

• 提供组件的介绍说明
• 提供组件的属性列表 Props
• 提供组件调用的示例源码 Usage
• 提供组件调用的演示 demo

方案

我们前期规范好了 markdown 说明文件以及 demo 文件，我们就可以直接通过 node 的读写文件再配合 react 菜单路由的方式进行生成：

• node 读写文件
• react 路由

规范

在上篇我们讲到对于一个组件，需要在开发组件时编写好组件的说明文档 markdown 文件以及 demo，文档规范如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

## Input

#### 输入框组件。

## Input Props：

| 参数       | 说明                     | 类型                                         | 默认值  |
| ---------- | ------------------------ | -------------------------------------------- | ------- |
| disabled   | 是否禁用                 | boolean                                      | -       |
| icon       | input 图标               | React.ReactElement                           | -       |
| iconPlace  | input 图标渲染位置       | 'left' \| 'right'                            | 'right' |
| allowClear | 是否可清除，渲染清除图标 | boolean                                      | false   |
| showNumber | 是否渲染字数计算         | boolean                                      | false   |
| maxLength  | 最大输入长度             | number                                       | 70      |
| onChange   | input 输入框改变的回调   | (e: ChangeEvent\<HTMLInputElement\>) => void | -       |

> Tip：Input 的 props 不止上面列举的项，可传入原生 input 的所有属性

### Usage

```js
import { Input } from "@hzzly/components";

const onChange = (e) => {
  console.log("Value: ", e.target.value);
};

ReactDOM.render(<Input icon={<Icon />} onChange={onChange} />, mountNode);
```

这也是我们目前定义的组件 markdown 规范，这样书写一个 markdown 文件就能满足前三点的需求，最后一点我们单独定义了一个 demo 文件来进行组件的演示和调试。

技术实现

node 读写 markdown 和 demo

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

/**
 * 读取组件库
 */
function readComponents() {
  const markdowns = {};
  const demos = {};
  const components = [];
  const dir = path.join(__dirname, "../src");
  const dirs = fs
    .readdirSync(dir)
    .filter(
      (f) => f.indexOf(".") < 0 && f.toLowerCase().indexOf("components") > -1
    );
  dirs.forEach((d) => {
    const absolutePath = path.join(dir, d);
    if (this.isDir(absolutePath)) {
      fs.readdirSync(absolutePath).forEach((f) => {
        components.push(f);
        const mdPath = path.join(dir, `./${d}/${f}/index.md`);
        const demoPath = path.join(dir, `./${d}/${f}/demo.tsx`);
        if (fs.existsSync(mdPath)) {
          markdowns[f] = fs.readFileSync(mdPath).toString();
        }
        if (fs.existsSync(demoPath)) {
          demos[f] = `../src/${d}/${f}/demo`;
        }
      });
    }
  });

  return {
    components,
    markdowns,
    demos,
  };
}

/**
 * 写入markdown字符串
 */
function writeMd() {
  let { markdowns } = readComponents();
  markdowns = {
    ...markdowns,
    Welcome: fs
      .readFileSync(path.join(__dirname, `../src/welcome.md`))
      .toString(),
  };
  const str = JSON.stringify(markdowns, "", "\t");
  fs.writeFile(
    path.join(__dirname, "../src/md.ts"),
    `export default ${str}`,
    (err) => {
      if (err) {
        console.error(err);
      }
      console.log("写入配置成功!");
    }
  );
}

自动生成组件及路由

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84

/**
 * 创建组件
 */
function createComponents() {
  const { components, demos } = readComponents();
  components.forEach((component) => this.createComponent(component, demos));
}

function createComponent(name, demos) {
  const to = path.resolve(__dirname, `../src/pages/${name}.tsx`);
  fs.ensureFileSync(to); // 确保文件存在(文件目录结构没有会新建)
  const template = `import React from 'react';
import { markdown } from '@/utils';
${demo[name] ? `import Demo from '${demo[name]}';` : ""}

interface Props {}

const index: React.FC<Props> = () => {
  return (
    <>
      <div
        className="markdown"
        // eslint-disable-next-line react/no-danger
        dangerouslySetInnerHTML={{ __html: markdown('${name}') }}
      />
      <div className="demo">
        <h2 className="demo-title">演示</h2>
        ${demo[name] ? "<Demo />" : "<p>演示代码</p>"}
      </div>
    </>
  )
}

export default index;
`;
  fs.outputFileSync(to, template);
}

/**
 * 写入路由
 */
function writeRouter() {
  const { components } = readComponents();
  const template = `
import React from 'react';
import { RouteConfig } from "react-router-config";

import Home from '@/pages/Home';
import Welcome from '@/pages/Welcome';

const MarkDown = React.lazy(() => import(/* webpackChunkName: "IMarkDown" */ '@/pages/MarkDown'));
${components
  .map(
    (component) =>
      `const ${component} = React.lazy(() => import(/* webpackChunkName: "I${component}" */ '@/pages/${component}'));`
  )
  .join("\n")}

const routes: RouteConfig[] = [
  {
    path: '/',
    component: Home,
    children: [
      { path: "/welcome", component: Welcome, name: 'Welcome' },
      { path: "/markdown", component: MarkDown, name: 'MarkDown测试' },
      ${components
        .map((component) => {
          if (component.toLowerCase().indexOf("js") > -1) {
            return `{ path: "/${component.toLowerCase()}", component: ${component}, name: '${component}' },`;
          } else {
            return `{ path: "/${component
              .replace(/\B([A-Z])/g, "-$1")
              .toLowerCase()}", component: ${component}, name: '${component}' },`;
          }
        })
        .join("\n      ")}
    ],
  },
];

export default routes;
`;
  fs.outputFileSync(path.join(__dirname, `../src/router/index.ts`), template);
}

markdown 解析

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

// utils.ts
import marked from "marked";
import hljs from "highlight.js/lib/core";
import javascript from "highlight.js/lib/languages/javascript";
import md from "@/md";

function markdown(component: string, isComponent = true): string {
  marked.setOptions({
    renderer: new marked.Renderer(),
    highlight: (code: string) => {
      return hljs.highlightAuto(code).value;
    },
    pedantic: false,
    gfm: true,
    tables: true,
    breaks: false,
    sanitize: false,
    smartLists: true,
    smartypants: false,
    xhtml: false,
  });
  if (md[component]) {
    return marked(md[component]);
  } else if (isComponent) {
    return marked(`## ${component}`);
  }
  return marked(component);
}

小结

在日常开发的过程中，我们除了组件的代码编写外，还有很多流程上、边角上的工作需要做，这些事情往往都比较琐碎又必须要做。我们多借助工具去解决我们的工作中那些零星简单的任务。

前言：从去年年底开始规划项目的重构，也是这样一个机遇，我开始负责项目的一个基础架构以及一些公共基础服务，主要搭建了组件库以及工具类库来提升后续开发以及重构的效率，期间也是踩了不少坑，接下来就作为整个搭建过程的一个总结，本篇主要是组件库的搭建与实践。

一个项目或系统有着大量的业务场景和业务代码，相似的页面和代码层出不穷，那如何管理和抽象这些相似的代码和模块，这肯定是许多团队都会遇到的问题。不断的拷代码？还是抽象成 UI 组件或业务组件？显然后者更高效。

问题

之前的开发流程从产品设计到研发的过程中，最常出现在需求沟通与研发过程中由于缺少统一的规范和标准化体系来指导实践，导致实施环节各方沟通成本高。

• 认知：产品、研发、设计师对于同一需求都有自己理解的解决方案，缺少统一规范的约束，难以达成共识。
• 效率：设计效率低，交互原型的维护成本及上下游团队的沟通成本高，易造成不专业的印象。
• 品质：认知和效率的局限性，最终导致实施落地的产品质量和用户体验难以得到保障。

价值

组件库最大的价值在于提升整个团队的产研效率，使设计质量得以保障的同时提升产品整体的用户体验。

• 保证产品体验的一致性：对于一个含有多业务系统的大型复杂产品，每个独立的业务系统虽然在功能上有一定区别，但整体的用户体验需要满足基本的一致性。
• 提升设计师的效率：在需求量巨大且需求来自不同的业务线时，需要逐一绘制页面及组件，造成大量重复劳动，并且在评审及需求沟通环节还可能存在不断地细节调优，所以对于设计师而言，组件的高频复用能大大提升设计效率，使设计师更多的将精力聚焦于理解和解决用户的实际问题。
• 提升产研团队的效率：通用场景及普通需求直接按规范进行设计和研发，减少上下游对同一页面及组件使用方式的不同理解而产生的多余沟通成本。
• 利于技术的沉淀：从一个组件库可以扩展到其它的技术方案，比如懒加载、Tree Shaking、文档预览等等。

解决方案

搭建统一的组件库

实践

接下来将详细介绍搭建一个前端组件库需要涉及的流程和相关知识、工具，其中也是参考了一些主流开源组件库的做法。

基础架构

组件库目录结构

目前现在的组件目录结构大致如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

├── ...
├── package.json
├── README.md // 文档说明
├── tsconfig.json // ts 配置文件
├── tsconfig.build.json // ts 编译配置
├── build // 配置文件
├── esm // es modules目标文件
├── lib // umd目标文件
├── docs // 文档
└── src
    ├── JsComponents // 原生js组件
    ├── components // React 组件
    ├── images
    ├── style // 公共样式文件
    └── index.ts // 入口文件

组件目录结构

组件的目录结构参考了 antd 的规范

1
2
3
4
5
6
7
8

Input
├── Input.tsx // 组件
├── demo.tsx // 示例演示demo
├── index.md // 组件文档说明
├── index.tsx // 组件入口文件
└── style // 样式文件
    ├── index.scss
    └── index.ts

编译后的组件目录结构

1
2
3
4
5
6
7
8
9

├── Input.d.ts
├── Input.js
├── index.d.ts
├── index.js
└── style
    ├── index.css
    ├── index.d.ts
    ├── index.js
    └── index.scss

规范

无规矩不成方圆，在组件库开始之初就定义好规范，保证代码的严谨性，配置了以下规则：

• eslint/@typescript-eslint
• stylelint
• git hooks
• git commit
• prettier

组件

基础架构定义好之后就可以愉快的进行组件开发了，组件的基本开发流程：

• 组件初始化
• 代码 coding
• 组件 demo
• 组件文档说明
• 组件库入口文件导出组件

对于组件初始化，我们也是通过脚本自动化实现，减少这些繁琐重复的工作。

样式

对于组件的样式，一开始我们有两套方案：

• 常规样式（css/scss）
• CSS-in-JS（styled-components）

我个人的话更喜欢 CSS-in-JS 的方案，不用去考虑样式的打包以及引用方式，但最终考虑到业务场景还需要输出原生的 css 代码提供旧项目引用，所以最后也是采用了常规样式，通过 gulp 打包输出 css 以及 scss 文件，后面打包的时候也会具体介绍一下。

文档

这里介绍一下目前的文档说明以及文档生成方案，首先对于每一个组件，需要在开发组件时编写好组件的说明文档（规则格式看下面组件文档）以及 demo，当我们运行组件库文档预览项目时会通过 node 脚本读取组件的说明文档以及 demo 自动生成对应的路由文件，这样我们就能实时预览文档以及 demo 演示。

组件文档

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

## Input

#### 输入框组件。

## Input Props：

| 参数       | 说明                     | 类型                                         | 默认值  |
| ---------- | ------------------------ | -------------------------------------------- | ------- |
| disabled   | 是否禁用                 | boolean                                      | -       |
| icon       | input 图标               | React.ReactElement                           | -       |
| iconPlace  | input 图标渲染位置       | 'left' \| 'right'                            | 'right' |
| allowClear | 是否可清除，渲染清除图标 | boolean                                      | false   |
| showNumber | 是否渲染字数计算         | boolean                                      | false   |
| maxLength  | 最大输入长度             | number                                       | 70      |
| onChange   | input 输入框改变的回调   | (e: ChangeEvent\<HTMLInputElement\>) => void | -       |

> Tip：Input 的 props 不止上面列举的项，可传入原生 input 的所有属性

### Usage

```js
import { Input } from "@hzzly/components";

const onChange = (e) => {
  console.log("Value: ", e.target.value);
};

ReactDOM.render(<Input icon={<Icon />} onChange={onChange} />, mountNode);
```

组件库文档

组件库的文档一般都是对外可访问的，因此需要部署到服务器上，同时也需具备本地预览的功能。

可以自己搭一个文档站点，也可以使用目前主流的文档生成器（Docz、Storybook、VuePress）来生成文档站点。

这里我们采用的是自己搭建的一个单独的 React 项目，也就是上面的 docs 文件夹，其实自己搭也比较简单，首先是思路：

• readFile 读取 src 下组件的 md 文件和 demo 文件保存起来
• writeFile 写入路由配置以及对应的路由文件
• 通过不同的路由渲染对应的组件文档和演示

主要借助的是 node 读写文件的便捷性，对于文档自动生成方案在后面文章会具体介绍一下，先明确一下思路就行。

打包

对于打包后的文件，统一放在 ems 目录下，顾名思义我们需要打包成 ESModule 的规范。

1
2
3
4
5
6
7
8
9
10
11

// packages.json
{
  ...
  "scripts": {
    "clean": "rimraf dist",
    "build": "npm run clean && tsc -p tsconfig.build.json && gulp -f ./build/gulpfile.js", // 组件库打包
    "start": "cross-env webpack-dev-server --config ./build/webpack.dev.js", // 组件开发调试环境
    "build:umd": "cross-env NODE_ENV='production' webpack --config ./build/webpack.umd.js", // umd打包
  },
  ...
}

编译打包 ts[x]

在入口文件我们需要以 ESModule 的规范导出组件：

1

export { default as Input } from "./components/Input";

打包工具的话我们就不能使用 webpack 来打包我们的组件库，可以使用 rollup 或 TS 来编译组件，这里我们采用的是 TS 编译的方案，配置 tsconfig.build.json :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

{
  "compilerOptions": {
    "outDir": "ems",
    "target": "es6",
    "module": "esnext",
    "moduleResolution": "node",
    "declaration": true, // 生成声明文件 .d.ts
    "skipLibCheck": true,
    "allowSyntheticDefaultImports": true,
    "experimentalDecorators": true,
    "baseUrl": ".",
    "paths": {
      "@/*": ["./src/*"]
    },
    "jsx": "react"
  },
  "include": ["src"],
  "exclude": [
    // 排除编译文件
    "node_modules",
    "src/**/demo.tsx",
    "**/*.md"
  ]
}

编译打包样式文件

上面我们已经成功编译了 ts 或 tsx 文件，但是对于我们的样式文件还没处理（TS 无法编译样式文件），样式文件根据我们上面的代码规范，需要打包编译到对应的组件文件夹下，这样就可以跟着组件路径来引入：

1

import "@hzzly/components/esm/input/style";

这里我们采用 gulp 来处理样式文件：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

// 生成css到对应组件
function scss2css() {
  return gulp
    .src(paths.styles)
    .pipe(base64({ maxImageSize: 2000 }))
    .pipe(sass()) // 处理sass文件
    .pipe(autoprefixer()) // 根据browserslistrc增加前缀
    .pipe(cssmin({ compatibility: "ie9" })) // 压缩
    .pipe(gulp.dest(paths.dest.esm));
}

// 拷贝scss到对应的组件
function copyScss() {
  return gulp
    .src(paths.styles)
    .pipe(base64({ maxWeightResource: 10000 }))
    .pipe(gulp.dest(paths.dest.esm));
}

UMD

这里还有一个业务场景是 JsComponents 需要打包成 umd 的格式提供旧框架通过链接的方式直接引用，所以我们还配置了 umd 的打包规范，分别单独打包 js 原生组件, 将组件单独打包需要在 Webpack 中配置多个entry，大致配置如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

const entry = {};

const names = fs
  .readdirSync(path.resolve(__dirname, `../src/JsComponents`))
  .filter((f) => f.indexOf('.') < 0);
names.forEach((name) => {
  entry[name.toLocaleLowerCase()] = path.resolve(__dirname, `../src/JsComponents/${name}/index.ts`);
});

module.exports = {
  ...
  entry,
  output: {
    path: path.resolve(__dirname, '../lib'),
    filename: '[name].min.js',
    publicPath: './',
  },
  ...
}

迭代维护

CHANGELOG.md

组件日常维护占整个组件库生命周期的很大一部分，组件库做起来了以后，组件功能后续会不断迭代，也许是 bug fix，也可能 feature，这些组件的迭代我们通过 PR 和 issue 来管理，同时，我们需要管理好组件的 changelog，为了规范我们也是将 changelog 维护到一个 Markdown 文件里，通过 conventional-changelog 工具自动根据 commit message 生成 CHANGELOG.md**。

总结

到这里，也算是对最近在组件库的探索做了个总结，从零开始构建了一个比较完整的组件库，这段经历也是让我在架构思维以及业务层面有了新的认识，也学到了不少的知识。当然，还有很多不完善的地方，也是在慢慢优化完善，在组件化这条路上，我们还有很多事情要做，加油！！！

参考

• Ant Design

前言：最近在完善 Input 组件字数计算的时候引发了不少的问题：1、到限制字数时，继续输入中文会替换末尾的文字；2、不同浏览器截断的表现不一样等等问题。

先明确一下需求

需求

• 输入到最大长度时，超出截断
• 首尾非文字（空格、换行等）不计入字数统计中
• 超出截断时保持已输入的文字以及开头非文字部分

尝试

总体思路

1、不能直接使用 input 的 maxLength，因为计算数字的时候会把首尾非文字也计算其中

2、监听 input 的 onChange 事件，当输入的长度大于最大长度时截断

根据以上思路，既然不能直接使用 input 的 maxLength，那就在 onChange 事件里进行逻辑处理。

第一次尝试

1
2
3
4
5
6
7

const v = e.target.value.trim();
if (v.length > maxLength && !("value" in props)) {
  setNum(maxLength);
  inputRef.current.value = v.slice(0, maxLength);
  return;
}
setNum(v.length);

存在的问题

• 输入到最大长度时开头空格或换行会被截掉
• 输入中文时会从尾部开始替换掉输入框的值
• 尾部空格较多时，截取的时候会出问题，计算数字的时候会把空格计算其中

第二次尝试

1
2
3
4
5
6
7
8
9
10
11
12

const { value } = e.target;
const v = value.trim();
if (value.length - v.length !== 0) {
  setLength(maxLength + (value.length - v.length)); // 动态计算maxLength保证首尾空格或换行还在
}
if (v.length > maxLength) {
  const newValue = v.slice(0, -(v.length - maxLength)).trim(); // 防止倒数第一个前面的值为空格
  inputRef.current.value = value.slice(0, -(v.length - maxLength));
  setNum(newValue.length);
} else {
  setNum(v.length);
}

通过上面两个逻辑判断和处理已经解决了第一次尝试的两个问题，那还有一个问题是不是没解决呢？其实在其他浏览器能解决输入中文时替换掉输入框的值，但是 Chrome 浏览器却不行，WTF！Chrome 竟然不行。其实原因是我上面提到的 Chrome 和其他浏览器输入中文时的表现不一样。

我们用两张图来看一下就明白了

第一张图是 Chrome 输入中文的表现，第二张图是其他浏览器输入中文的表现。是的，Chrome 输入中文时会实时把拼音显示在输入框内，这样就会导致在截取的时候判断不准确替换掉了尾部的值，那有没有什么解决方案呢？那肯定是有的，接下来就来优化一下这个问题。

优化

判断是否中文输入

当用户使用拼音输入法输入时，我们会发现 onChange/onInput 取得的值是拼音值，但是很明显，我们需要计算的是用户输入的中文值的长度，而不是拼音值的长度。所以这里需要解决使用拼音输入法时会取得拼音值的问题。

我们先来看两个比较陌生的事件：

• compositionstart：文本合成系统如 input method editor（即输入法编辑器）开始新的输入合成时会触发 compositionstart 事件。例如，当用户使用拼音输入法开始输入汉字或者使用语音输入时，这个事件就会被触发。
• compositionend：当文本段落的组成完成或取消时， compositionend 事件将被触发 (具有特殊字符的触发，需要一系列键和其他输入，如语音识别或移动中的字词建议)。例如，当用户使用拼音输入法输入汉字或者使用语音输入完毕或者取消时，这个事件就会被触发。

因此我们可以声明一个标记lock，在compositionstart、compositionend两个事件过程之间的时候lock值为 true，在 input onChange事件中通过lock的值来判断当前输入的状态和截取。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

if (e.type === 'compositionstart') {
  lock.current = true;
}
if (e.type === "compositionend") {
  lock.current = false;
}
const { value } = e.target;
const v = value.trim();
if (value.length - v.length !== 0) {
  setLength(maxLength + (value.length - v.length))
}
if (v.length > maxLength) {
  const newValue = v.slice(0, -(v.length - maxLength)).trim();
  if (!lock.current) {
    inputRef.current.value = value.slice(0, -(v.length - maxLength));
  }
  setNum(newValue.length);
} else {
  setNum(v.length);
}

// html
<input
  ref={inputRef}
  className="yp-input__inner"
  onChange={handleChange}
  onCompositionStart={handleChange}
  onCompositionEnd={handleChange}
  ...
/>

总结

那到这里一个 Input 组件字数计算的问题总算解决了，从中也是吸取了不少的经验和总结，继续加油！！！

前言：最近针对项目代码仓库进行了一次重构，之前代码管理缺少规范和模块化的思想，也是借着项目重构这次机会重新规划代码仓库，实践落地了一种新的项目管理方式——Monorepo，Monorepo的管理概念跟我们规划的项目代码管理非常贴合，再加上我们新增的组件库及工具库，打造了一套比较完整的工作流。

一些概念性的的东西这里就不多说了，不太了解 Monorepo 的可以自行 google 一下，这里就默认已经了解过了。

要想从零开始定制一套完善的 Monorepo 的工程化工具，还是一件比较有难度的事情。不过社区已经提供了一些比较成熟的方案，我们可以拿来进行定制。

在重构方案选择上，我们选择了业界比较成熟的 lerna 和 yarn workspaces，用 yarn 来处理依赖问题，用 lerna 来处理发布问题。

仓库地址

lerna

lerna 官方的定位：A tool for managing JavaScript projects with multiple packages（一个用来管理带有多个package的JavaScript项目）。

lerna不负责构建，测试等任务，它提出了一种集中管理package的目录模式，提供了一套自动化管理程序，让开发者不必再深耕到具体的组件里维护内容，在项目根目录就可以全局掌控，基于 npm scripts，使用者可以很好地完成组件构建，代码格式化等操作。

安装

1
2
3

npm install lerna –g
//
yarn add lerna global

基本命令

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

// lerna 项目初始化
lerna init // 固定模式
lerna init -i // 独立模式

// 创建子项目
lerna create [包名]

// 清除所有子项目的依赖
lerna clean

// 安装所有依赖
lerna bootstrap

// 发布
lerna publish

重构的价值

之前的代码管理非常的混杂，还是比较传统的代码目录结构，一些公共基础服务无法扩展复用，如下：

1
2
3
4
5
6
7
8
9
10
11

// 之前的代码目录
├── package.json
├── README.md
├── tool // 项目打包编译配置
├── release // 打包目标文件夹
└── src // 源代码
    ├── css
    ├── html
    ├── images
    ├── js
    └── sass

重构后的代码结构无论是模块化还是复用性都很清晰，同时在代码规范上也比之前更规范了，如下：

1
2
3
4
5
6
7
8
9

// 重构后的代码目录：
├── ... // 其它配置文件（代码规范）
├── package.json
├── README.md
├── lerna.json // lerna 配置文件
└── packages // 分割的小项目
    ├── components
    ├── utils
    ├── ... // 多个业务模块

总结一下：

• 将之前混杂的代码库分割为独立版本控制的小项目（项目更清晰）
• 解决了包之间的依赖关系（新增了组件库以及工具库）
• 通过git仓库检查到改动并自动同步（公共基础库的发布）
• 根据提交的commit生成CHANGELOG版本日志文件（项目代码更规范）
• TypeScript支持
• 统一技术栈
• 完善的工作流

当然，lerna 还有更多的功能可以去发掘，还有很多可以结合 lerna 一起使用的工具。构建一套完善的仓库管理机制，可能它的收益不是一些量化的指标可以衡量出来的，也没有直接的价值输出，但它能在日常的工作中极大的提高工作效率，解放生产力，节省大量的人力成本。

下篇就来聊聊组件库的那些事。

前言：最近在项目中进行渐进式重构升级，技术栈也是从之前的jQuery时代转换成React和TypeScript。当然重构过程中也冒出了不少的问题，本文将记录一下React TS中自定义DOM属性的一些解决方案。

先看一下需求

• 在原生DOM节点新增自定义属性

比如：

1

<div mark="mark"></div>

在React中这样写是能正常渲染的，React官方对于自定义DOM属性也是有一篇文章特别说明，大致意思就是React 16之前对于未知的DOM属性。如果JSX具有React无法识别的属性，React只会跳过它，并不会渲染在DOM中，在React 16之后，进行了更改，所有未知属性都将最终出现在DOM中。

但是在TypeScript中这样写就会报错：

类型“DetailedHTMLProps<HTMLAttributes, HTMLDivElement>”上不存在属性“mark”

Google了一圈，在 stackoverflow 看到一个差不多的问题，尝试按照useful最多的这样声明：

1
2
3
4
5

declare module 'react' {
  interface HTMLProps<T> {
    mark?:string;
  }
}

然而还是报相同的错误，未解决。

最后在一个Answer中找到了解决方案，测试可行：

1
2
3
4
5

declare module 'react' {
  interface HTMLAttributes<T> extends AriaAttributes, DOMAttributes<T> {
    mark?: string;
  }
}

添加这句声明后能顺利的解决ts的报错，但这也不是最好的解决方案，这是为什么呢？在添加了这句声明后，发现我们在上面声明的图片格式失效报错了：

找不到模块“xxxxxx.png”或其相应的类型声明

这里就直接列举出我尝试后的解决方案，可能不是最好的，但目前可以解决上面的两个报错问题：

把自定义DOM属性类型声明和图片类型声明分开到不一样的.d.ts文件里，防止冲突报错

如果有更好的解决方案，欢迎交流探讨。

前言：最近在团队中负责公共基础服务的建设，封装了公共类库及组件库，以为能带来比较大的便捷，真是理想很丰满，现实很骨感，开发时通过ES Module引入及使用都很方便，的确达到了开发效率的提升，但后续打包发布测试时却遇到了难题，目标项目中未使用的代码也一并打包进来了，导致最后的bundle过大。那问题就很明显了，需要去除掉未使用的代码。

下面跟分享下，我在Tree Shaking上的摸索历程。

什么是Tree Shaking

用个简单的栗子描述一下：我们将应用程序想象成一棵树。绿色叶子表示实际用到的 source code(源码) 和 library(库)，是树上活的树叶。灰色叶子表示未引用代码，是树上枯萎的树叶。为了除去死去的树叶，你必须摇动这棵树，使它们落下。

具体来说，在 webpack 项目中，有一个入口文件，相当于一棵树，入口文件有很多依赖的模块，相当于树叶。实际情况中，虽然依赖了某个模块，但其实只使用其中的某些功能。通过 Tree Shaking，将没有使用的模块摇掉，这样来达到删除无用代码（dead-code）的目的。

Tree Shaking 较早由 rollup 提出并实现，后来，webpack 从 webpack2 开始也增加了 Tree Shaking 的功能。

Tree Shaking的原理

Tree Shaking 本质是借助 ES module 的静态分析能力来消除无用的代码（dead-code）。

静态分析能力

Tree Shaking 的目的是减少文件的体积，节约带宽，提高加载速度，所以文件必须在浏览器加载之前完成瘦身，也就是在打包的时候完成这个功能。ES6 使用 import 和 export 可以在编译期确定模块间的依赖关系，这是 Tree Shaking 的必需条件，这也意味着被 Babel 编译成 ES5 的代码是不能 Tree Shaking 的。

dead-code

我们需要理解什么是无用的代码，满足以下特征，即是无用代码：

• 代码不会被执行，不可达到
• 代码执行的结果不会被用到
• 代码只会影响死变量（只写不读）

Tree Shaking的原理总结下来就是以下两点：

1、ES6的模块引入是静态分析的，故而可以在编译时正确判断到底加载了什么代码
2、分析程序流，判断哪些变量未被使用、引用，进而删除此代码

TS 编译的类库

原理理解后，那对于开头那个问题就比较好解决了。

查看我的tsconfig.json后果然配置有误，配置的 "target": "ES5" 没有配置 module 导致 TS 编译成 CommonJS 模块了，也就无法满足 Tree Shaking 的条件。

1
2
3
4
5
6
7
8
9

// 修改后的tsconfig.json
{
  ...
  "compilerOptions": {
    "target": "ES5",
    "module": "ESNext"
    ...
  }
}

修改完 TS 编译配置后，让目标项目重新打包后就符合预期，去除了无用的代码，bundle的体积也明显的减少了。

到这里，感觉万事大吉了，然而比较坑的是用 class 写的类库还是没办法消除，还是会被打包进去。

还是我们上面配置的"target": "ES5" 的问题，因为我们项目还需要兼容IE（万恶的IE），所以需要配置编译为es5，导致我们的 class 被编译成了 IIFE （立即调用函数表达式），又有一个新的问题：Webpack Tree Shaking不会清除IIFE

Webpack Tree Shaking

当我们用 Webpack 配合 UglifyJS 打包文件时，我们class类的IIFE又被打包进去了。这跟我们想象的完全不一样啊？为什么呢？无用的类不能消除，这还能叫做 Tree Shaking 吗。

在你的Tree-Shaking并没什么卵用中有过分析，里面有一个例子比较好，见下文

原因很简单：uglify没有完善的程序流分析。它可以简单的判断变量后续是否被引用、修改，但是不能判断一个变量完整的修改过程，不知道它是否已经指向了外部变量，所以很多有可能会产生副作用的代码，都只能保守的不删除。

栗子：

1
2
3
4
5
6
7
8
9
10
11
12

var V8Engine = (function () {
  function V8Engine () {}
  V8Engine.prototype.toString = function () { return 'V8' }
  return V8Engine
}())
var V6Engine = (function () {
  function V6Engine () {}
  V6Engine.prototype = V8Engine.prototype // <---- side effect
  V6Engine.prototype.toString = function () { return 'V6' }
  return V6Engine
}())
console.log(new V8Engine().toString()) // V6

V6Engine虽然没有被使用，但是它修改了V8Engine原型链上的属性，这就产生副作用了。如果 V6Engine 这个IIFE里面再搞一些全局变量的声明，那就当然不能删除了。那就没有解决方案吗？在你的Tree-Shaking并没什么卵用中最后有提供解决方案。

如果想利用好 Webpack 的 Tree Shaking，我们需要规范自己的代码：

• 使用 ES2015 模块语法（即 import 和 export）
• 确保没有编译器将您的 ES2015 模块语法转换为 CommonJS 的（顺带一提，这是现在常用的 @babel/preset-env 的默认行为，详细信息请参阅文档）
• 尽量不写带有副作用的代码。诸如编写了立即执行函数，在函数里又使用了外部变量等
• 如果JavaScript库开发中，难以避免的产生各种副作用代码，可以将功能函数或者组件，打包成单独的文件或目录，以便于用户可以通过目录去加载。如有条件，也可为自己的库开发单独的webpack-loader，便于用户按需加载
• 配置TypeScript编译器以"esnext"用作 module，使代码能以 ES module 导出

目前也是越来越多的 Npm 第三方模块考虑到了 Tree Shaking，并对其提供了支持。 相信 Tree Shaking 也会越来越成熟。

参考

• Webpack 官方文档
• 你的Tree-Shaking并没什么卵用
• Tree-Shaking性能优化实践 - 原理篇

前言：前两天开发了一个抽奖功能的需求，也是被定时器折磨了一番。

问题

• React Hooks里的定时器
• 倒计时不准
• 应用退到手机后台后的定时器

接下来咱们一一解决它。

React Hooks里的定时器

对于每个使用 React Hooks 的开发者来说，setInterval 是一个绕不过去的”坑“。由于React Hooks 特有的设计理念，如果用固有的思维模式去写 setInterval，很容易触发意想不到的 bug。

比如下面的错误写法：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

function Test() {
  const [count, setCount] = useState(0);
  const timer = useRef();
  
  useEffect(() => {
    if (!timer.current) {
      timer.current = setInterval(() => {
        setCount(count + 1);
      }, 1000);
    }
    return () => {
      if (timer.current) {
        clearInterval(timer.current);
        timer.current = null;
      }
    }
  }, []);
  
  return <div>{count}</div>;
}

这样写确实很简洁，也符合我们固有的思维模式，但是它的实现效果却与我们的目标背道而驰。

预期的效果是页面上的数字会每秒增加 1 ，但实际是数字增加到 1 后便静止不动了。由于 useEffect 的依赖为空数组，所以 setInterval 只会在组件完成初次渲染后被调用一次，从而使得回调函数在之后每次被定时调用时，取到的 count 都是初次渲染时的值 0（闭包的原因），页面上的数值也会永远停留在 1。

解决方案：

我们使用useRef来解决来解决这种闭包引起的问题。（useRef 在 React Hooks 中的作用，正如官网说的，它像一个变量，类似于 this ，它就像一个盒子，你可以存放任何东西， useRef 每次都会返回相同的引用）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

function Test() {
  const [count, setCount] = useState(0);
  const timer = useRef();
  const time = useRef(0);
  
  useEffect(() => {
    if (!timer.current) {
      timer.current = setInterval(() => {
        time.current += 1;
        setCount(time.current);
      }, 1000);
    }
    return () => {
      if (timer.current) {
        clearInterval(timer.current);
        timer.current = null;
        time.current = null;
      }
    }
  }, []);
  
  return <div>{count}</div>;
}

倒计时不准（定时器不准）

我们知道定时器的执行时间并不是确定的。这是由于 JS 是门非阻塞单线程语言，因为在最初 JS 就是为了和浏览器交互而诞生的。如果 JS 是门多线程的语言话，我们在多个线程中处理 DOM 就可能会发生问题（一个线程中新加节点，另一个线程中删除节点）。那么为什么说定时器的执行时间不是确定的呢？那就得来细数一下轮询（Event loop）了。

Event Loop 的是计算机系统的一种运行机制。JS 语言就采用这种机制，来解决单线程运行带来的一些问题。

在 JavaScript 中，任务被分为两种，一种宏任务（MacroTask），一种叫微任务（MicroTask）。

常见的宏任务有：script全部代码、setTimeout、setInterval、setImmediate（浏览器暂时不支持，只有IE10支持，具体可见MDN）、I/O、UI Rendering。

常见的微任务有：Process.nextTick（Node独有）、Promise、Object.observe(已废弃)、MutationObserver

一次 Event loop 顺序是这样的：

1. 执行同步代码，这属于宏任务
2. 执行栈为空，查询是否有微任务需要执行
3. 执行所有微任务
4. 必要的话渲染 UI
5. 然后开始下一轮 Event loop，执行宏任务中的异步代码

通过上述的 Event loop 顺序可知，我们实际写的定时器（倒计时）1秒是不确定的。当我们倒计时还在定时器里减1就不准确了。

解决方案：

既然定时器不准，那我们就不能做减1的操作，可以利用时间戳的差值来计算。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

function Test() {
  const [count, setCount] = useState(3600);
  const timer = useRef();
  const time = useRef(0);
  
  useEffect(() => {
    time.current = count;
    if (!timer.current) {
      let start = new Date().getTime();
      let end = 0;
      timer.current = setInterval(() => {
        const s = (end - start) / 1000;
        time.current -= s;
        setCount(time.current);
        start = end;
      }, 1000);
    }
    return () => {
      if (timer.current) {
        clearInterval(timer.current);
        timer.current = null;
        time.current = null;
      }
    }
  }, []);
  
  return <div>{count}</div>;
}

应用退到手机后台后的定时器

在手机端，如果应用被切换到后台（不是关闭应用，是切到后台），那么这时候定时器就会有问题。PC上的Firefox，Chrome和Safari等浏览器，都会自动把未激活页面中的JavaScript定时器（setTimeout，setInterval）间隔最小值改为1秒以上。这是因为间隔很小的定时器一般用来做UI更新（例如用定时器实现的动画），让用户不可见的页面上的定时器跑慢一些，既节省资源又不会影响体验。对移动浏览器来说，内存，CPU，带宽等资源更加宝贵，设备移动的上浏览器往往会直接冻结所有未激活页面上的所有定时器。

解决方案：

通过监听 visibilitychange 方法，如果退到后台记录下当前时间，等切回来，再算一下当前时间，然后计算时间差，最后用当时定格的那个时间去减去这个时间差，再赋值给这个定时器，就ok了。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

let start = 0;
let end = 0;
let startS = 0;
const hiddenProperty =
  'hidden' in document ?
  'hidden' :
  'webkitHidden' in document ?
  'webkitHidden' :
  'mozHidden' in document ?
  'mozHidden' :
  null;
if (hiddenProperty == null) {
  return false;
}
const visibilityChangeEvent = hiddenProperty.replace(/hidden/i, 'visibilitychange');
const onVisibilityChange = function () {
  if (!document[hiddenProperty]) {
    end = new Date().getTime(); // 页面切回来的时间戳
    const s = Math.ceil((end - start) / 1000); // 时间差
    const timeC = startS - s; // 当时定格的那个时间去减去这个时间差 = 最新的倒计时
    if (timeC > 0) {
      setTime(timeC);
    } else {
      setTime(-1);
    }
  } else {
    startS = time; // 当前倒计时时间戳
    start = new Date().getTime(); // 页面退到后台的时间戳
  }
};
document.addEventListener(visibilityChangeEvent, onVisibilityChange);

总结

到这里，基本就针对碰到的定时器的三个问题讲了一遍，不对之处，还请多多指正！

前言：去年的时候针对公司老项目（dva环境）进行了一次优化升级，升级后没出现啥问题，因为疫情的关系，导致一直在家办公，最近针对老项目又加了个需求，用自己的电脑从Gogs上down下来npm install之后运行就报错了。

安装完依赖npm start的时候，就开始报如下的错误：

1
2
3

Failed to compile
./node_modules/history/esm/history.js
Module not found: Can't resolve '@babel/runtime/helpers/esm/extends' in 'xxxx\prong-console-tenant\node_modules\history\esm'

一般删了node_modules重新安装依赖能解决80%的问题，但这次重新安装却不起作用了。于是就开始了折腾之旅了，去Google搜了一圈，找了几个解决方案尝试之后发现都不太行。

最后在Github issues里找到了解决思路：history 版本问题。

按以下步骤检查：

1、npm list history 查看history安装情况；

2、如果版本不是4.7.2，卸载history， npm un history；

3、npm list history 确保history已全部删除；

4、npm install --save history@4.7.2 安装指定版本；

按照如上步骤就把这个错误解决了，运行成功。完美！

1
2

console.log(812782555915911412);
812782555915911400;

原因

这是因为 JavaScript 中数字的精度是有限的，Java 的 Long 类型的数字超出了 JavaScript 的处理范围。JavaScript 内部只有一种数字类型 Number，所有数字都是采用 IEEE 754 标准定义的双精度 64 位格式存储，即使整数也是如此。这就是说，JavaScript 语言的底层根本没有整数，所有数字都是小数（64 位浮点数）。其结构如图：

各位的含义如下：

• 1 位（s） 用来表示符号位，0 表示正数，1 表示负数
• 11 位（e） 用来表示指数部分
• 52 位（f） 表示小数部分（即有效数字）

双精度浮点数(double)并不是能够精确表示范围内的所有数， 虽然双精度浮点型的范围看上去很大: 。 可以表示的最大整数可以很大，但能够精确表示，使用算数运算的并没有这么大。因为小数部分最大是 52 位，因此 JavaScript 中能精准表示的最大整数是 ，十进制即 9007199254740991。

1
2
3

console.log(Math.pow(2, 53) - 1);
console.log(1L<<53);
9007199254740991

JavaScript 有所谓的最大和最小安全值：

1
2
3

console.log(Number.MAX_SAFE_INTEGER);
console.log(Number.MIN_SAFE_INTEGER);
9007199254740991 - 9007199254740991;

安全 意思是说能够 one-by-one 表示的整数，也就是说在范围内，双精度数表示和整数是一对一的，在这个范围以内，所有的整数都有唯一的浮点数表示，这叫做安全整数。

而超过这个范围，会有两个或更多整数的双精度表示是相同的；即超过这个范围，有的整数是无法精确表示的，只能大约(round)到与它相近的浮点数（说到底就是科学计数法）表示，这种情况下叫做不安全整数，例如：

1
2
3
4
5
6
7
8
9

console.log(Number.MAX_SAFE_INTEGER + 1); // 结果：9007199254740992，精度未丢失

console.log(Number.MAX_SAFE_INTEGER + 2); // 结果：9007199254740992，精度丢失

console.log(Number.MAX_SAFE_INTEGER + 3); // 结果：9007199254740994，精度未丢失

console.log(Number.MAX_SAFE_INTEGER + 4); // 结果：9007199254740996，精度丢失

console.log(Number.MAX_SAFE_INTEGER + 5); // 结果：9007199254740996，精度未丢失

而 Java 的 Long 类型的有效位数是 63 位（扣除一位符号位），其最大值为，十进制为 9223372036854775807。

1
2
3
4
5
6
7

public static void main(String[] args) {
    System.out.println(Long.MAX_VALUE);
    System.out.println((1L<<63) -1);
}

9223372036854775807
9223372036854775807

所以只要 java 传给 JavaScript 的 Long 类型的值超过 9007199254740991，就有可能产生精度丢失，从而导致数据和逻辑出错。

和其他编程语言（如 C 和 Java）不同，JavaScript 不区分整数值和浮点数值，所有数字在 JavaScript 中均用浮点数值表示，所以在进行数字运算的时候要特别注意精度缺失问题。容易造成混淆的是，某些运算只有整数才能完成，此时 JavaScript 会自动把 64 位浮点数，转成 32 位整数，然后再进行运算，由于浮点数不是精确的值，所以涉及小数的比较和运算要特别小心。

进一步阅读：JavaScript 教程 - 数据类型 - 数值

解决方法

解决办法就是让 Javascript 把数字当成字符串进行处理。对 Javascript 来说如果不进行运算，数字和字符串处理起来没有什么区别。当然如果需要进行运算，只能采用其他方法，例如 JavaScript 的一些开源库 bignum、bigint 等支持长整型的处理。Java 进行 JSON 处理的时候是能够正确处理 long 型的，只需要将数字转化成字符串就可以了。

前言：前端时间也是应项目的需求开始了h5移动端的折腾之旅，在目前中台的基础上扩展了两个ToC移动端项目，下面就是在h5移动端表单页面键盘弹出收起兼容性的一些总结。

问题

在 h5 项目中，我们会经常遇到一些表单页面，在输入框获取焦点时，会自动触发键盘弹起，而键盘弹出在 IOS 与 Android 的 webview 中表现并非一致，同时当我们主动触发键盘收起时也同样存在差异化。

键盘弹出

• IOS：IOS系统 的键盘处在窗口的最上层，当键盘弹起时，webview 的高度 height 并没有改变，只是 scrollTop 发生变化，页面可以滚动。且页面可以滚动的最大限度为弹出的键盘的高度，而只有键盘弹出时页面恰好也滚动到最底部时，scrollTop 的变化值为键盘的高度，其他情况下则无法获取。这就导致在 IOS 情况下难以获取键盘的真实高度。
• Android: 在Android系统中，键盘也是处在窗口的最上层，键盘弹起时，如果输入框在靠近底部的话，就会被键盘挡住，只有你输入的时候输入框才会滚动到可视化区域。

键盘收起

• IOS：触发键盘上的按钮收起键盘或者输入框以外的页面区域时，输入框会失去焦点，因此会触发输入框的 blur 事件；当键盘收起时，页面底部会出现一个空白区域，页面会被顶起。
• Android: 触发键盘上的按钮收起键盘时，输入框并不会失去焦点，因此不会触发页面的 blur 事件；触发输入框以外的区域时，输入框会失去焦点，触发输入框的 blur 事件。

期望的结果

针对不同系统触发键盘弹出收起时的差异化，我们希望功能流畅的同时，尽量保持用户体验的一致性。

对症下药

上面我们理清了目前市面上两大主要系统的差异性，接下来就需对症下药了。

在 h5 中目前没有接口可以直接监听键盘事件，但我们可以通过分析键盘弹出、收起的触发过程及表现形式，来判断键盘是弹出还是收起的状态。

• 键盘弹出：输入框获取焦点时会自动触发键盘的弹起动作，因此，我们可以监听 focusin 事件，在里面实现键盘弹出后所需的页面逻辑。

• 键盘收起：当触发其他页面区域收起键盘时，我们可以监听 focusout 事件，在里面实现键盘收起后所需的页面逻辑。而在通过键盘按钮收起键盘时在 ios 与 android 端存在差异化表现，下面具体分析：

  • IOS：触发了 focusout 事件，仍然通过该办法监听。
  • Android：没有触发 focusout 事件。在 android 中，键盘的状态切换（弹出、收起）不仅和输入框关联，同时还会影响到 webview 高度的变化，那我们就可以通过监听 webview height 的变化来判断键盘是否收起。

系统判断

在实践中我们可以通过 userAgent 来判断目前的系统：

1
2
3

const ua = window.navigator.userAgent.toLocaleLowerCase();
const isIOS = /iphone|ipad|ipod/.test(ua);
const isAndroid = /android/.test(ua);

IOS 处理

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

let isReset = true; //是否归位

this.focusinHandler = () => {
  isReset = false; //聚焦时键盘弹出，焦点在输入框之间切换时，会先触发上一个输入框的失焦事件，再触发下一个输入框的聚焦事件
};

this.focusoutHandler = () => {
  isReset = true;
  setTimeout(() => {
    //当焦点在弹出层的输入框之间切换时先不归位
    if (isReset) {
        window.scroll(0, 0); //确定延时后没有聚焦下一元素，是由收起键盘引起的失焦，则强制让页面归位
    }
  }, 30);
};

document.body.addEventListener('focusin', this.focusinHandler);
document.body.addEventListener('focusout', this.focusoutHandler);

Android 处理

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

const originHeight = document.documentElement.clientHeight || document.body.clientHeight;

this.resizeHandler = () => {
  const resizeHeight = document.documentElement.clientHeight || document.body.clientHeight;
  const activeElement = document.activeElement;
  if (resizeHeight < originHeight) {
    // 键盘弹起后逻辑
    if (activeElement && (activeElement.tagName === "INPUT" || activeElement.tagName === "TEXTAREA")) {
      setTimeout(()=>{
        activeElement.scrollIntoView({ block: 'center' });//焦点元素滚到可视区域的问题
      },0)
    }
  } else {
    // 键盘收起后逻辑
  }
};

window.addEventListener('resize', this.resizeHandler);

react 封装

在 react 中我们可以写一个类装饰器来修饰表单组件。

类装饰器：类装饰器在类声明之前被声明（紧靠着类声明）。 类装饰器应用于类构造函数，可以用来监视，修改或替换类定义。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45

// keyboard.tsx
/*
 * @Description: 键盘处理装饰器
 * @Author: hzzly
 * @LastEditors: hzzly
 * @Date: 2020-01-09 09:36:40
 * @LastEditTime: 2020-01-10 12:08:47
 */
import React, { Component } from 'react';

const keyboard = () => (WrappedComponent: any) =>
  class HOC extends Component {
    focusinHandler: (() => void) | undefined;
    focusoutHandler: (() => void) | undefined;
    resizeHandler: (() => void) | undefined;
    componentDidMount() {
      const ua = window.navigator.userAgent.toLocaleLowerCase();
      const isIOS = /iphone|ipad|ipod/.test(ua);
      const isAndroid = /android/.test(ua);
      if (isIOS) {
        // 上面 IOS 处理
        ...
      }
      if (isAndroid) {
        // 上面 Android 处理
        ...
      }
    }

    componentWillUnmount() {
      if (this.focusinHandler && this.focusoutHandler) {
        document.body.removeEventListener('focusin', this.focusinHandler);
        document.body.removeEventListener('focusout', this.focusoutHandler);
      }
      if (this.resizeHandler) {
        document.body.removeEventListener('resize', this.resizeHandler);
      }
    }

    render() {
      return <WrappedComponent {...this.props} />;
    }
  };

export default keyboard;

使用

1
2
3
4
5
6
7
8

// PersonForm.tsx
@keyboard()
class PersonForm extends PureComponent<{}, {}> {
  // 业务逻辑
  ...
}

export default PersonForm;

在工作中，我们常常会将一些通用性代码，比如一些工具类、公用业务逻辑代码以及团队定制化的UI库等，发布到私有npm仓库。需要的项目直接安装使用即可。

在一次组件开发完将要上传的私服的时候，通过 npm login 登录私服一直报错，出现了如下两种报错：

登录报错npm ERR! code E401

npm登录时报错：

1
2
3
4
5
6
7
8
9

$ npm login
Username: 你的nexus用户名
Password: 你的nexus用户密码
Email: (this IS public) 你的邮箱
npm ERR! code E401
npm ERR! Unable to authenticate, need: BASIC realm="Sonatype Nexus Repository Manager"

npm ERR! A complete log of this run can be found in:
npm ERR!     C:\Users\Administrator\AppData\Roaming\npm-cache\_logs\XXX-debug.log

这时在我的mac上可以正常登录，说明是客户端的问题。

原因可能是本机使用过其他账号登录过，但是没有退出登录。果然在npm的配置文件 .npmrc 文件中找到了问题。

解决方案，检查 ~/.npmrc 文件，删除 xlab-npm-group 和 xlab-npm-private 相关的token记录：

1
2
3
4
5
6

registry=http://**********:20001/repository/xlab-npm-group/
//**********:20001/repository/xlab-npm-group/:_authToken=XXXX     // 删除这行
//**********:20001/repository/xlab-npm-group/:_authToken=XXXX        // 删除这行
always-auth=true
home=https://www.npmjs.org
//**********:20001/repository/xlab-npm-private/:_authToken=XXXX  // 删除这行

修改后如下：

1
2
3

registry=http://**********:20001/repository/xlab-npm-group/
always-auth=true
home=https://www.npmjs.org

保存后重新登录成功。

登录报错npm ERR! code E500

npm登录时报错：

1
2
3
4
5
6
7
8
9

$ npm login --registry=http://**********:20001/repository/xlab-npm-private/
Username: 你的nexus用户名
Password: 你的nexus用户密码
Email: (this IS public) 你的邮箱
npm ERR! code E500
npm ERR! 500 Server Error -PUT =http://**********:20001/repository/xlab-npm-private/-/user/org.couchdb.user:XXX

npm ERR! A complete log of this run can be found in:
npm ERR!  /Users/XXX/.npm/_logs/XXX-debug.log

这时在另外的机器登录也是同样错误，说明是可能是服务器问题。

解决方案，通知管理员检查服务器是否正常。管理员检查后发现服务器OOM了：

重启服务器容器后，重新登录成功。

忙完公司的工作之后，终于能腾出点时间来学习了，除了将基础和源码的学习补回来，还利用闲余的时间玩了一下flutter。刚开始我觉得Flutter的布局嵌套语法很恶心，内心是及其排斥的，但是在学了之后，我只想说：“真香！”

移动开发的现状

随着移动互联网的高速发展，移动App的开发模式也在快速更迭中发展。
最初，为了能够在不同系统环境上运行，通常要求开发团队进行多平台并行开发。通常，开发Android和iOS App一共需要两个开发团队，维护两套源代码，分别进行测试。

后来，开发者们逐渐意识到，这样的开发效率并不高，成本却不低。因此诞生了一个接一个的跨平台解决方案。比如react-native、weex、cordova、ionic等等。但无一例外地，它们都无法摆脱低性能的JavaScript或者原生代码依赖，或多或少地存在不足。
所以急需一个真正能够打通多平台且高性能的框架来“救场”，Flutter则应运而生。

认识 Flutter

Flutter是谷歌的移动UI框架，可以快速在iOS和Android上构建高质量的原生用户界面。作为一种全新的响应式，跨平台，高性能的移动开发框架。从开源以来，已经得到越来越多开发者的喜爱。其中闲鱼、腾讯、美团、字节跳动等大厂都有自己成熟的团队并有深度实践。赶快学起来！

Flutter 特性

那么，Flutter 究竟有哪些特性吸引着这么多开发者的喜爱呢呢？

1. 热重载（Hot Reload）：有热重载真的太舒服了，可以帮助开发者更高效地进行开发和测试，更利于修复Bug，就这一点比原生安卓制作简直不知道高到哪里去了。
2. 统一的应用开发体验：Flutter拥有丰富的库，帮助开发者快速实现项目需求。同时，大部分的工具和库同时支持Android和iOS；
3. 界面生动：Flutter支持跨平台开发，同样支持Material Design（原生Android设计语言）和Cupertino（原生iOS设计语言）风格的控件。开发者可根据设计需要实现不同风格的UI界面；
4. 原生性能：无论在Android还是iOS环境中，Flutter可以提供与原生应用一样的性能，甚至支持120 HZ的高刷新率；
5. 响应式框架：Flutter支持响应式框架，在某些场景下，开发者无需付出任何代价，即可完成不同屏幕的适配，使UI的构建更加轻松；
6. 混合开发：Flutter可以与平台原生代码相结合，支持较新的Kotlin和Swift开发语言。借助该特性，可以轻松访问Android或iOS上的原生系统功能和系统API。

Flutter 核心思想

一切都是控件（Widget）(Everything’s a Widget)

在Flutter的世界里，包括views,view controllers,layouts等在内的概念都建立在Widget之上。widget是flutter功能的抽象描述。

也就是说，在Flutter中，一个应用就是有许许多多的Widget组合而成的。

Flutter 分层架构

从flutter的架构图中不难看出widget是整个视图描述的基础。

Flutter Framework

这是一个纯 Dart实现的 SDK，它实现了一套基础库，自底向上，我们来简单介绍一下：

• 底下两层（Foundation和Animation、Painting、Gestures）在Google的一些视频中被合并为一个dart UI层，对应的是Flutter中的dart:ui包，它是Flutter引擎暴露的底层UI库，提供动画、手势及绘制能力。

• Rendering层，这一层是一个抽象的布局层，它依赖于dart UI层，Rendering层会构建一个UI树，当UI树有变化时，会计算出有变化的部分，然后更新UI树，最终将UI树绘制到屏幕上，这个过程类似于React中的虚拟DOM。Rendering层可以说是Flutter UI框架最核心的部分，它除了确定每个UI元素的位置、大小之外还要进行坐标变换、绘制(调用底层dart:ui)。

• Widgets层是Flutter提供的的一套基础组件库，在基础组件库之上，Flutter还提供了 Material 和Cupertino两种视觉风格的组件库。而我们Flutter开发的大多数场景，只是和这两层打交道。

Flutter Engine

这是一个纯 C++实现的 SDK，其中包括了 Skia引擎、Dart运行时、文字排版引擎等。在代码调用 dart:ui库时，调用最终会走到Engine层，然后实现真正的绘制逻辑。

聊完架构接下来我们聊一聊flutter的生命周期。

Flutter 生命周期

Flutter的生命周期主要包括两大部分：state和App。

state 生命周期

widget是immutable的，发生变化的时候需要重建，所以谈不上状态。StatefulWidget 中的状态保持其实是通过State类来实现的。State拥有一套自己的生命周期：

生命周期状态图如下：

注意：

• didChangeDependencies有两种情况会被调用。

  • 创建时候在initState 之后被调用
  • 在依赖的InheritedWidget发生变化的时候会被调用

• 正常的退出流程中会执行deactivate然后执行dispose。但是也会出现deactivate以后不执行dispose，直接加入树中的另一个节点的情况。

• 这里的状态改变包括两种可能：1.通过setState内容改变 2.父节点的state状态改变，导致孩子节点的同步变化。

App生命周期

如果想要知道App的生命周期,那么需要通过WidgetsBindingObserver的didChangeAppLifecycleState 来获取。通过该接口可以获取是生命周期在AppLifecycleState类中。常用状态包含如下几个：

一个实际场景中的例子：
在不考虑suspending的情况下：从后台切入前台生命周期变化如下:

AppLifecycleState.inactive -> AppLifecycleState.resumed;

从前台压后台生命周期变化如下：

AppLifecycleState.inactive -> AppLifecycleState.paused;

Flutter 环境搭建

工欲善其事必先利其器，环境搭建可以参考 Flutter实战 一步一步来搭建。

Flutter 实践

经过一个多礼拜的折腾，自己也尝试写了几个小demo：

优秀学习资料

• Flutter中文网
• Flutter World
• Flutter免费视频-技术胖
• 《Flutter 实战》
• 闲鱼技术团队

拓展

• Flutter和RN谁才是更好的跨端开发方案

参考

• 《Flutter 实战》
• 闲鱼技术团队

前段时间被头条hr从库里捞起来了(去年面到三面打入冷宫)，于是就接受了面试邀请，心想进不了也可以查缺补漏自己的不足。

其中就问了一道关于flex的问题：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

面试官：`flex: 1` 是哪些属性的缩写？
 
我：对应三个属性(flex-grow|flex-shrink|flex-basis)。
 
面试官：`1` 对应哪个属性，另外两个属性的默认值是多少？
 
我：当 flex 取值为一个非负数字时，则该数字为 flex-grow 值，flex-shrink 默认为 1，flex-basis 默认 0%。心想幸好当时学的时候看到过。
 
面试官：这三个属性分别表示的什么意思，剩余空间和溢出空间的概念有了解过吗？
 
我：。。。不知道
 
面试官：没关系，我们下一个问题。
 
总结：果然很头条(一个问题问到你不知道为止)。

接下来我就来对flex对应的三个属性做个详解。

首先明确一点是，flex 属性是 flex-grow, flex-shrink 和 flex-basis 的简写，默认值为 0 1 auto。

flex-grow

传统的布局是子容器在父容器中从左到右进行布局，应用 flex 进行布局，那么父容器一定设置 display: flex，子容器要“占有”并且“瓜分”父容器的空间，如何占有、瓜分的策略就是弹性布局的策略。这里就要解释到“剩余空间”的概念：

子容器在父容器的“主轴”上还有多少空间可以“瓜分”，这个可以被“瓜分”的空间就叫做剩余空间。

flex-grow 属性定义弹性盒子项（flex-item）的放大比例(定义子容器的瓜分剩余空间的比例)，默认为0，即如果存在剩余空间，也不放大(不会去瓜分)。

flex-shrink

如果子容器宽度超过父容器宽度，即使是设置了 flex-grow，但是由于没有剩余空间，就分配不到剩余空间了。这时候有两个办法：换行和压缩。由于 flex 默认不换行，那么压缩的话，怎么压缩呢，压缩多少？此时就需要用到 flex-shrink 属性了。

flex-shrink 属性定义了弹性盒子项（flex-item）的缩小比例，默认为1，即如果空间不足，该子容器将缩小。

如果所有子项的 flex-shrink 属性都为1，当空间不足时，都将等比例缩小。如果一个子项的 flex-shrink 属性为0，其他子项都为1，则空间不足时，前者不缩小。

此时，剩余空间的概念就转化成了“溢出空间”。

注意：

• 负值对该属性无效。
• 如果子容器没有超出父容器，设置 flex-shrink 无效

flex-basis

flex-basis 属性定义了在分配多余空间之前，子项占据的主轴空间（main size）。浏览器根据这个属性，计算主轴是否有多余空间。它的默认值为auto，即项目的本来大小。

它可以设为跟 width 或 height 属性一样的值（比如350px），则子项将占据固定空间。既然是跟宽度相关，那么 max-width，min-width，width 和 flex-basis 的大小优先级是怎么样的。

max-width/min-width > flex-basis > width

理解完了这三个属性接下来就看一些我们平时常写的一些简写表示的意义。

flex 简写

flex 的默认值是以上三个属性值的组合。假设以上三个属性同样取默认值，则 flex 的默认值是 0 1 auto。

flex 取三个值

1
2
3
4
5
6
7

.item { flex: 2 1 200px; }
// 等同于
.item {
  flex-grow: 2;
  flex-shrink: 1;
  flex-basis: 200px;
}

flex 取值为 none

当 flex 取值为 none，则计算值为 0 0 auto。

1
2
3
4
5
6
7

.item { flex: none; }
// 等同于
.item {
  flex-grow: 0;
  flex-shrink: 0;
  flex-basis: auto;
}

flex 取值为 auto

当 flex 取值为 auto，则计算值为 1 1 auto。

1
2
3
4
5
6
7

.item { flex: auto; }
// 等同于
.item {
  flex-grow: 1;
  flex-shrink: 1;
  flex-basis: auto;
}

flex 取值为 一个非负数

当 flex 取值为一个非负数字，则该数字为 flex-grow 值，flex-shrink 取 1，flex-basis 取 0%。

1
2
3
4
5
6
7

.item { flex: 1; }
// 等同于
.item {
  flex-grow: 1;
  flex-shrink: 1;
  flex-basis: 0%;
}

flex 取值为 长度或百分比

当 flex 取值为一个长度或百分比，则视为 flex-basis 值，flex-grow 取 1，flex-shrink 取 1。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

.item { flex: 0%; }
// 等同于
.item {
  flex-grow: 1;
  flex-shrink: 1;
  flex-basis: 0%;
}

.item { flex: 20px; }
// 等同于
.item {
  flex-grow: 1;
  flex-shrink: 1;
  flex-basis: 20px;
}

flex 取值为 两个非负数字

当 flex 取值为两个非负数字，则分别视为 flex-grow 和 flex-shrink 的值，flex-basis 取 0%。

1
2
3
4
5
6
7

.item { flex: 1 2; }
// 等同于
.item {
  flex-grow: 1;
  flex-shrink: 2;
  flex-basis: 0%;
}

flex 取值为 一个非负数字和一个长度或百分比

当 flex 取值为一个非负数字和一个长度或百分比，则分别视为 flex-grow 和 flex-basis 的值，flex-shrink 取 1。

1
2
3
4
5
6
7

.item { flex: 2 20px; }
// 等同于
.item {
  flex-grow: 2;
  flex-shrink: 1;
  flex-basis: 20px;
}

最后我们来用一个例子来计算子项的宽度。

栗子🌰

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

<div class="parent">
  <div class="item1"></div>
  <div class="item2"></div>
  <div class="item3"></div>
</div>
 
<style type="text/css">
  .parent {
    display: flex;
    width: 600px;
  }
  .parent > div {
    height: 100px;
  }
  .item1 {
    width: 140px;
    flex: 2 1 0%;
    background: blue;
  }
  .item2 {
    width: 100px;
    flex: 2 1 auto;
    background: darkblue;
  }
  .item3 {
    flex: 1 1 200px;
    background: lightblue;
  }
</style>

当 item-1 的 flex-basis 取 0% 的时候，是把该项目视为零尺寸的，故即便声明其尺寸为 140px，也并没有什么用，形同虚设
而 item-2 的 flex-basis 取 auto 的时候，根据规则基准值使用值是主尺寸值即 100px，故这 100px 不会纳入剩余空间

主轴上父容器总尺寸：600px

剩余空间：
600px - 100px(item2的flex-basis值) - 200px(item3的flex-basis值) = 300px

伸缩放大系数之和(flex-grow值)：
2(item1) + 2(item2) + 1(item3) = 5

每一份比例所占宽度：300 / 5 = 60px;

剩余空间分配如下：

• item1 和 item2 各分配 2/5，各得 120px
• item3 分配 1/5，得 60px

各子项最终宽度为：

• item1 = 0%(0px) + 120px = 120px
• item2 = auto(100px) + 120px = 220px
• item3 = 200px + 60px = 260px

参考

• Flex 布局教程：语法篇

现如今大数据已无所不在，并且正被越来越广泛的被应用到历史、政治、科学、经济、商业甚至渗透到我们生活的方方面面中，获取的渠道也越来越便利。

今天我们就来聊一聊“大屏应用”，说到大屏就一定要聊到数据可视化，现如今，数据可视化由于数据分析的火热也变得火热起来，不过数据可视化并不是一个新技术，可视化数据就是用可视化的方式展现的数据。而数据大屏作为大数据展示媒介的一种，广泛运用于各种展示厅、会展、发布会及各种狂欢节中，其中不乏一些通用的处理方案：阿里的DataV、百度的Suger、腾讯RayData等等。

随着物联网、5G等各种跟连接有关的技术的出现与发展，每个人手中掌握的数据量都呈指数级增长，光看这些数是看不过来也看不懂的，“数据可视化”就是一种简化，让艰难的数据理解过程，变成——看颜色，辨长短，分高低。从而大大缩短理解数据所需的时间。

因公司的自研产品涉及到BI模块，因此数据大屏展示的需求孕育而生（数据大屏需求已经完成）。

下面是本人针对这个数据大屏需求前期做的一些探索实践，数据也是mock的。

技术选型

• React 全家桶（React-Router、React-Redux、React Hooks）
• Webpack 编译打包
• Echarts 图表组件
• Socket.IO 即时通讯、通知与消息推送
• Grid 网格布局

系统搭建

图表选择

六种基本图表涵盖了大部分图表使用场景，也是做数据可视化最常用的图表类型：

• 柱状图 用来反映分类项目之间的比较；
• 饼图 用来反映构成，即部分占总体的比例；
• 折线图 用来反映随时间变化的趋势；
• 条形图 用来反映分类项目之间的比较；
• 散点图 用来反映相关性或分布关系；
• 地图 用来反映区域之间的分类比较。

基本图表类型都有通用的样式，不过多的展开讲解。我们更多的考虑如何选择常用图表来呈现数据，达到数据可视化的目标。基本方法：明确目标 —> 选择图形 —> 梳理维度 —> 突出关键信息。

数据请求推送

当信息一旦准备就绪，我们就需要从服务器获取它们。这里我们需要一种基于推送的方法，例如 WebSocket 协议、轮询、服务器推送事件（SSE）以及最近的 HTTP2 服务器推送。这里我们简单比较一下 WebSocket 与轮询。

轮询需要客户端定时向服务器发送ajax请求，服务器接到请求后返回响应信息。这就需要大量的占据服务器资源。同时在HTTP1.x协议中也存在一些比如线头阻塞、头部冗余等问题。所以这种方案直接pass了。

再来说说 WebSocket，建立在 TCP 协议之上，数据格式比较轻量，性能开销小，通信高效，可以发送文本，也可以发送二进制数据。同时它还没有同源限制，客户端可以与任意服务器通信。还有一点 WebSocket 通常不使用 XMLHttpRequest，因此，当我们每次需要从服务器获取更多的信息时，无需发送头部数据。反过来说，这又减少了数据发送到服务器时需要付出的高昂的数据负载代价。对于数据大屏需要实时获取数据，这无疑是最高效的。

布局

数据大屏的核心就是数据的拼接，具体到展示层可以归纳成数据块的拼接。这里我们采用通用的尺寸1920*108(16:9)。尺寸确立后，接下来要对展示层进行布局和页面的划分。这里的划分，主要根据我们之前定好的业务指标进行，核心业务指标安排在中间位置、占较大面积；其余的指标按优先级依次在核心指标周围展开。一般把有关联的指标让其相邻或靠近，把图表类型相近的指标放一起，这样能减少观者认知上的负担并提高信息传递的效率。

对于这种块状(网格)布局，我们就可以使用我们强大的 CSS 布局方案 – Grid。它将网页划分成一个个网格，可以任意组合不同的网格，做出各种各样的布局。

安利一个grid 布局可视化设计工具 – CSS Grid Generator。可以使用它生成对应的代码，帮助咱们快速布局。

项目结构

聊完这些通用知识我们就可以上手开发了。

我这里使用了我自己开发的脚手架（hzzly-cli）来生成react项目环境。

有兴趣了解脚手架开发的可以看我这篇文章动手开发一个自己的项目脚手架

项目结构如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

├── src
│   ├── assets // 资源目录
│   ├── components // 公共组件目录
│   │   ├── Card // Card组件
│   │   ├── Charts // 图表组件目录
│   │   │   ├── Bar // 柱状图
│   │   │   ├── ChinaMap // 中国地图
│   │   │   ├── Funnel // 漏斗图
│   │   │   ├── Line // 折线图
│   │   │   ├── Pie // 饼图
│   │   │   └── lib // 基础图表组件
│   │   ├── ScrollNumber // 滚动数字组件
│   │   └── SvgIcon // Icon组件
│   ├── global.scss
│   ├── index.js
│   ├── pages // 分块结构目录
│   ├── router // 路由
│   ├── store
│   │   ├── actions
│   │   ├── index.js
│   │   ├── reducers
│   │   ├── sagas
│   │   └── types.js
│   └── utils
│       ├── genChartData.js
│       ├── genMapData.js
│       ├── socket.js
│       └── util.js

知识点

Chart基础组件封装

这里对echarts-for-react进一步封装，其它图表组件可以直接继承使用。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53

// Charts/lib/BaseChart.js
import React, { PureComponent } from 'react';
import PropTypes from 'prop-types';
import Echarts from 'echarts-for-react';

export default class BaseChart extends PureComponent {
  static propTypes = {
    option: PropTypes.object.isRequired,
    data: PropTypes.object.isRequired,
    getOption: PropTypes.func.isRequired,
    style: PropTypes.object,
  };

  static defaultProps = {
    style: {},
  };

  componentDidMount() {
    const { runAction } = this.props;

    if (this.chartRef && runAction) {
      const chartIns = this.chartRef.getEchartsInstance();
      window.setTimeout(() => {
        runAction(chartIns);
      }, 300);
    }
  }

  render() {
    const { option, data, getOption, style } = this.props;

    const finalOption = getOption(option, data);
    const finalStyle = getStyle(style);

    return (
      <Echarts
        ref={ref => {
          this.chartRef = ref;
        }}
        style={finalStyle}
        option={finalOption}
        notMerge
        lazyUpdate
      />
    );
  }
}

function getStyle(style) {
  return Object.assign({ position: 'relative' },
    style
  );
}

使用：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54

// line.js
import BaseChart from '../lib/BaseChart';
import option from './option';
import getOption from './getOption';

export default class Line extends BaseChart {
  static defaultProps = {
    option,
    getOption,
  };
}

// option.js 基础配置
export default {
  // ...
};

// getOption.js 计算配置文件
function seriesCreator(series) {
  return series.map(e => ({
    type: 'line',
    symbol: 'circle',
    smooth: true,
    lineStyle: {
      normal: {
        width: 3,
      },
    },
    ...e,
  }));
}

export default function(option, data) {
  const { tooltip, xAxis, yAxis, yCategory, series = [], ...rest } = data;

  return {
    ...option,
    xAxis: {
      ...option.xAxis,
      ...xAxis,
    },
    tooltip: {
      ...option.tooltip,
      ...tooltip,
    },
    yAxis: {
      ...option.yAxis,
      ...yAxis,
      data: yCategory || [],
    },
    series: seriesCreator(series),
    ...rest,
  };
}

Socket封装SDK

这里对socket.io-client封装成SDK，方便使用。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83

import io from 'socket.io-client';

const socket = {
  wsConn: null,
  config: {
    wsHost: '/', // wesocket host

    onConn() {},
    onDisconn() {},
    onError() {},
    onReceiveMsg() {},
  },

  init(opt) {
    socket.config = { ...socket.config, ...opt };
  },

  getWs() {
    if (socket.wsConn) {
      return socket.wsConn;
    } else {
      socket.initWs();
    }
  },

  getWsStatus() {
    return socket.wsConn ? socket.wsConn.connected : false;
  },

  initWs() {
    if (socket.getWsStatus()) {
      return socket.wsConn;
    }

    const wsUrl = socket.config.wsHost;

    socket.wsConn = io.connect(wsUrl);
    socket.wsConn.on('connect', () => {
      socket.config.onConn(socket.wsConn);
    });

    socket.wsConn.on('message', (...param) => {
      socket.config.onReceiveMsg(...param);
    });

    socket.wsConn.on('disconnect', () => {
      socket.config.onDisconn();
    });
    return socket.wsConn;
  },

  reconnect() {
    if (socket.wsConn) {
      if (socket.wsConn.disconnected) {
        // reconnect ws
      } else {
        // do nothing
      }
    } else {
      socket.initWs();
    }
  },

  disconnect() {
    if (socket.wsConn) {
      if (socket.wsConn.connected) {
        socket.wsConn.disconnect();
      }
    }
  },

  wsEmit(params) {
    if (socket.wsConn) {
      socket.wsConn.emit(params.name, params.data);
    }
  },
};

(function(global) {
  global.socket = socket;
})(window);

export { socket };