简单实现一个 hashtable

这个玩意有无数个别名: map/dict/object/hashTable

需求:

• 具有读写功能, 可以使用setItem(key, value)写入键值对(key-value), 当写入的是相同的键但不同的值时, 为更新, 当重复写入同样的键值对, 不做任何操作(即不会存在重复将一个键值对存两遍, 也不会存在同一个键对应多个不同的值)
• 具有读功能, 可以使用getItem(key)根据键名得到值, 当读取不存在的键名是, 抛出null

思路:
首先需要一个数组来存取所有的 key-value, 取名table

然后最简单的, 写一个函数hashStringToInt(s), 该函数接受字符串为参数, 返回的是经过hash过的数字. 对应到实现 hashTable, 将 key 传入到该函数, 得到的结果即为对应table的索引, 然后在对应索引下存入 value, 如下

// 三个 key-value 以及对应的 hash 值
key    hash    value
name   0       'a' 
age    2       '18'
height 3       169

// table 最后为
['a', undefined, '18', 169, ...]

但是这样做存在两个问题:

• 第一个问题, 初始化table的时候, 一般会固定一个值, 假设为100(有效的索引最多到 99), hashStringToInt(key)很有可能是超过 99 的. 这个时候可以对最后的结果取table.length的模, 即这样无论如何最后 hash 出来的结果都不会超过table.length(这里是 99)
• 第二个问题, 很有可能出现冲突(collide), 理想情况下所有的 key 根据 hash 后的结果均匀分布到各个 index 上, 实际情况可能会出现多个 key 同一个 value, 这时候需要改变存取方法

方法为, 将出现冲突的 index 的位置的元素, 改成一个数组, 该数组存取所有 hash 结果和该索引一样的 key-value, 形式也为一个数组, 如下

// 三个 key-value 以及对应的 hash 值
// 其中 name 和 gae hash 冲突, 均为 0
key    hash    value
name   0       'a' 
age    0       '18'
height 3       169

// table 最后为
[[['name', 'a'], ['age', '18']], undefined, undefined, [[['height', 169]]]]

到这里基本上没有什么问题了, 但是性能还是要考虑一下, 运气不好你甚至可能出现你想存的所有 key-value 对所对应的 hash 都是同一个...那么该 index 下就会存在 n(n 可以是 9999999...) 个 key-value 组合, 然后最坏情况就是你遍历 n 次, 然后找到了最后一个才是你想要的

所以比较好的情况还是能够比较均匀的将 key-value 分布到各个 index, 每个 index 下可能只存 1-3 个 key, value, 那么查找的时候最坏也就查 3 次找到, 相比 9999999 实在好很多

要实现这一功能, 其实很简单, 增加一个loadFactor系数, 为存取的 key-value 数量 / table length, 这里可以设定当loadFactor大于 0.8 的时候, 增加table的容量, 将容量扩大到下一个质数

同时最后还要注意一个问题, 当对同一个 key 进行写入的时候, 如果是不同的 value, 则更新 value, 如果还是同一个 value, 不做任何操作, 因此需要做一些判断

完整代码如下:

class HashTable {
  constructor() {
    this.table = new Array(3)
    this.numItems = 0
  }
  
  hashStringToInt(s, tableSize) {
    let hash = 17
    for (let i = 0; i < s.length; i++) {
      hash = (13 * hash * s.charCodeAt(i)) % tableSize
    }
    return hash
  }
  
  resize() {
    // 使用 Mersenne prime 得到下一个 prime, 肮脏实现
    const newTable = new Array(2 ** this.table.length - 1)
    // rehash all
    for (const e of this.table) {
      if (e) {
        // 存在该 index 下的元素是 undefined 的可能性...
        for (const [key, value] of e) {
          const index = this.hashStringToInt(key, newTable.length);
          if (newTable[index]) {
            newTable[index].push([key, value]);
          } else {
            newTable[index] = [[key, value]];
          }
        }
      }
    }
    this.table = newTable
  }

  getItem(key) {
    const index = this.hashStringToInt(key, this.table.length)
    if (!this.table[index]) {
      return null
    }
    return this.table[index].find(e => e[0] === key)[1]
  }

  setItem(key, value) {
    const loadFactor = this.numItems / this.table.length
    if (loadFactor > 0.8) {
      // resize
      this.resize()
    }
    const index = this.hashStringToInt(key, this.table.length)
    if (this.table[index]) {
      // 判断是否在设置同一个 key
      const item = this.table[index].find(e => e[0] === key)
      if (item) {
        // 相同即更新
        item[1] = value
      } else {
        // 否则添加新元素
        this.numItems++
        this.table[index].push([key, value])
      }
    } else {
      this.numItems++
      this.table[index] = [[key, value]]
    }
  }
}

const hashTable = new HashTable()
hashTable.setItem('A', 'a')
hashTable.setItem('B', 'b')
hashTable.setItem('A', 'a1')
hashTable.setItem('C', 'c')
hashTable.setItem('D', 'd')
console.log(hashTable.numItems) // 4
console.log(hashTable.table.length) // 7
console.log(hashTable.getItem('A')) // a1
console.log(hashTable.getItem('B')) // b
console.log(hashTable.getItem('C')) // c
console.log(hashTable.getItem('D')) // d

参考

• https://gist.github.com/benawad/7a71da878100eec3b0958fbd0882576c
• https://gist.github.com/alexhawkins/f6329420f40e5cafa0a4

简单聊一聊浏览器下的 event-loop, 微任务与宏任务

函数调用栈

函数都是有调用栈的, 大多数程序可以看成函数调用函数不断调用函数, 比如下面这张图:

可以看到, 首先有一个 main(可以看做是入口), 然后依次是fn3()调用fn2(), 再调用fn1(), 最后调用console.log(). 一般出现错误的时候, 就会出现类似栈调用情况, 如下:

event loop

首先推荐观看这个视频What the heck is the event loop anyway?, 以及作者写了一个 event loop 可视化工具: Loupe, 不过目前这个工具支持比较有限, 不支持查看 callback queue 里面具体的 macrotask 和 microtask.

这里还是总结一下基本的 event loop 流程, 首先看这张图:

• 首先 JavaScript 是一门单线程语言, 只有一个主线程, 你可以看成 main, 该线程负责调用函数堆栈, 也就是前面所说的Call Stack
• 其中有一些 API 浏览器是不提供, 所以无法处理, 主线程会把这些 API, 放到另外一个地方(绿色部分)处理, 这些 API 叫作 Web API(也可以称之为调度者), 如上图中的 setTimeout, setTimeInterval, XMLHttpRequest等等
• 这里注意, 在处理这些 Web API 的时候, js 引擎的主线程还是在不断工作的(如果有任务的话), 可以认为两边是互相工作, 互不干扰
• 回到 WebAPI 部分, 假设放到 Web API 部分的这段代码是 setTimeout((_) => console.log(1), 1000), 这里绿色部分所做的是:
  • 等 1000ms
  • 将(_) => console.log(1)这个回调放到 Event Queue(事件队列, 蓝色部分) 里面, 这里注意: 并非是把setTimeout()整个函数放入到事件队列里面, 仅放入其中的回调函数部分
• 也就是说, 调度者在上下文代码中还是同步立即执行, 只不过其随后会将自己里面的回调函数放入任务队列中等待执行.
• 最后对于 Event Queue 部分, 这里会堆积很多 Web API 移动下来的回调函数. 当 js 引擎的 call stack 为空的时候, event queue 会把最先进入到 queue 里面的回调函数推入 call stack 里面执行

给两张张图片描述一下上面的流程, 其中第二张图片的代码为:

const foo = () => console.log("First");
const bar = () => setTimeout(() => console.log("Second"), 500);
const baz = () => console.log("Third");

bar();
foo();
baz();

几个注意点:

• web api 执行 (setTimeout, 请求等), 一旦时间到, 立马就将里面的回调函数放入到 event queue 任务队列中
• 一旦主线程空了, 那么不管 web api 里面是否还有代码在运行, 都会开始执行任务队列里面的任务

所以整个执行过程是相当连贯协调, 大家分工合作, 每个函数都有自己的职责和暂时归属地, 属于哪里以及什么时候被执行都是井井有条. 避免了同步情况下, 一个无关紧要的任务被卡死, 其余任务无法被执行的现象

异步任务和同步任务

• 同步任务: JS 引擎主线程里面立即被推入 call stack 且可以被执行的函数
• 异步任务: 在 event queue 里面的回调函数, 也就是独立于主线程里面的任务

举一个例子:

下面的这个片段, synCb这个回调函数是不会被推入到 event queue 里面执行的, 会被浏览器当做同步任务执行, 所以打印的结果就是按照从上到下面的顺序, 依次进入堆栈输出的

console.log('start')

const syncFun = function(synCb) {
  const v = 100
  synCb(v)
}
syncFun(v => console.log(v))
console.log('end')

// start
// 100
// end

假如我们加入异步任务, 如下, 那么这里的asynCb是会作为异步任务放入 event queue 里面等主线程清空以后(也就是两个 console.log都执行完毕), 才会被推入 call stack 被调用

console.log('start')

setTimeout(function asynCb() {
    console.log(100)
}, 0)

console.log('end')

// start
// end
// 100

总的来说在这种情况下, js 形成了两个队列: 同步任务队列和异步任务队列, 先执行同步任务队列里面的任务, 所有同步任务执行完毕以后, 再执行异步任务队列里面的任务.

异步回调

普通函数回调

例如setTimeout(callback, timer), 里面的 callback 是异步任务, 最后是会被放入到 event queue 里面的, 这里要注意一个setTimeout的点: 即里面的时间并非真正意义上的执行时间, 考虑如下代码:

setTimeout(() => {
  console.log(8)
}, 5000)

setTimeout(() => {
  console.log(9)
}, 5000)

setTimeout(() => {
  console.log(10)
}, 5000)

// 8
// 9
// 10

上述代码最后会依次打印 8, 9, 10. 这是由于根据执行顺序会依次放入到 event queue 里面, 也就是说, 打印 8 的回调会被先放入到异步任务队列里面, 然后是 9, 10.

所以这里的时间并非指的是这个函数的执行时间, 而指代的是, 异步回调函数几秒后会被放入到任务队列

Promise 和 async/await

Promise

promise中, .then()里面的为异步回调

假设有如下代码:

console.log('start')

new Promise((resolve, reject) => {
  resolve(1)
  console.log('middle')
}).then(v => console.log(v))

console.log('end')

// start
// middle
// end
// 1

上面代码中, v => console.log(v)是异步回调, 注意, new Promise在实例化的过程中所执行的代码都是同步进行的, 所以console.log('middle')会同步执行

async/await

async/await 本质上还是基于 Promise 的一些封装, async函数在await 之前的代码都是同步执行的，可以理解为await之前的代码属于new Promise时传入的代码，await 之后的所有代码都是在Promise.then中的回调

console.log('start')

async function main() {
  console.log('test')
  const v = await Promise.resolve(1)
  console.log(v)
}

main()
console.log('end')

// start
// test
// end
// 1

写法总结

使用request, 写一个getUser函数, 有基本以下写法:

回调写法:

const getUser = function(callback) {
  request('http://www.example.com', function(err, res, body){
    callback(body)
  })
}

getUser(v => console.log(v))

Promise 写法:

const getUser = function() {
  return new Promise((resolve, reject) => {
    request('http://www.example.com', function(err, res, body){
      if (err) {
        return reject(err)
      }
      resolve(body)
    })
  })
}

getUser()
  .then(v => console.log(v))
  .catch(err => console.error(err))

async/await 写法:

const getUser = function() {
  return new Promise((resolve, reject) => {
    request('http://www.example.com', function(err, res, body){
      if (err) {
        return reject(err)
      }
      resolve(body)
    })
  })
}

(async function() {
  try {
    const v = await getUser()
    console.log(v)
  } catch(e) {
    console.error(e)
  }
})()

宏任务与微任务

上面提到的 event queue 里的异步任务还可以细分为: macrotask(宏任务), microtask(微任务). 这里注意, 现在标准称呼可以认为是 tasks 和 jobs, 但本文还是以宏任务和微任务来代指

宏任务:

• script(整体代码, 上下文)
• setTimeout, setInterval
• I/O
• UI rendering

微任务:

• Promise
• process.nextTick

当然上面的任务其实均指的是其中的回调函数, 而上面的 api 前面也提过, 充当调度者的作用

有几个概念需要注意一下:

• promise.then(callback)里面的callback是一个微任务, 且会被推入当前的微任务队列, 当且仅当该promise状态变更为resolved或者rejected, 否则不被推入任务队列
• setTimeout(callback, t)的callback是一个宏任务, 会被推入当前的宏任务队列中, 即使t为 0
• 整个在 script 中的代码也是一个宏任务

模型

关于宏任务和微任务的模型可以看成如下图的形式:

有几个重要的概念:

• 始终只有一条宏任务队列
• 可以有多条微任务队列, 但是每一个宏任务后面仅跟随一条微任务队列, 且只对当前的宏任务"有效"
• 每一次 loop(循环), 都会去执行宏任务里面最前面的一个宏任务, 然后检查是否有微任务队列, 依次执行微任务队列里面的微任务. 执行完毕后开始下一次循环, 和之前一样从宏任务队列里面选取最新的宏任务执行, 不断循环
• 在执行微任务/宏任务的过程中, 如果发现微任务, 那么添加到当前的微任务队列中等待稍后被执行, 而如果发现宏任务, 该宏任务被添加到宏任务队列中等待下一次 loop 被执行. 也就是说: 发现微任务是可以在当前 loop 下被执行的, 而发现的宏任务只能等到下一次循环的时候被执行
• 每一次 loop 都包含: 一个(且只有一个)宏任务被执行, 以及对应的微任务队列, 执行完毕后开启下一个 loop

总结:

1. 运行宏任务队列最先进来的宏任务, 然后移除他(一般第一个宏任务是 script)
2. 依次运行微任务队列中的微任务, 移除他们
3. 开始下一次 loop(返回过程 1)

异步任务模型伪代码可以模拟成如下:

// 第一次 loop
[
  ['宏任务 1', '微任务 1.1', ' 微任务 1.2'],
  ['宏任务 2'],
  ['宏任务 3'],

]

// 第二次 loop
[
  // ['宏任务 1', '微任务 1.1', ' 微任务 1.2'], 执行完毕被清空
  ['宏任务 2', '微任务 2.1'],
  ['宏任务 3'],
]

// 第三次 loop
[
  // ['宏任务 1', '微任务 1.1', ' 微任务 1.2'], 执行完毕被清空
  // ['宏任务 2'], 执行完毕被清空
  ['宏任务 3'],
]

示例

示例 1:

console.log('start')

setTimeout(function() {
  console.log('timeout')
}, 0)

new Promise(function(resolve) {
  console.log('promise')
  resolve()
}).then(function() {
  console.log('promise resolved')
})

console.log('end')

// start
// promise
// end
// promise resolved
// timeout

分析:

1. 建立执行上下文，进入执行栈开始执行代码，打印 start
2. 往下执行，遇到setTimeout，将回调函数放入宏任务队列，等待执行
3. 继续往下，有个new Promise，其回调函数并不会被放入其他任务队列，因此会同步地执行，打印promise，但是当resolve后，.then会把其内部的回调函数放入微任务队列
4. 执行到了最底部的代码，打印出 end, 此时 call stack 被清空, 可以执行异步任务
5. 开始第一次 event loop:
   1. 由于整个 script 算一个宏任务, 因此该宏任务已经被执行完毕
   2. 检查微任务队列, 发现其中有 3 放入的微任务, 执行打印出 promise resolved，第一次循环结束
6. 开始第二次 loop:
   1. 从宏任务开始，检查宏任务队列是否有可执行代码，发现有 2 中放入的一个，打印timeout
   2. 检查微任务队列, 微任务, 第二次循环结束

示例 2:

console.log('start')

setTimeout(function () {
  console.log('event loop2, macrotask')
  new Promise(function (resolve) {
    console.log('event loop2, macrotask continue')
    resolve()
  }).then(function () {
    console.log('event loop2, microtask1')
  })
}, 0)

new Promise(function (resolve) {
  console.log('middle')
  resolve()
}).then(function () {
  console.log('event loop1, microtask1')
  setTimeout(function () {
    console.log('event loop3, macrotask')
  })
})

console.log('end')

// start
// middle
// end
// event loop1, microtask1
// event loop2, macrotask
// event loop2, macrotask continue
// event loop2, microtask1
// event loop3, macrotask

分析:

1. 打印 start, 发现 setTimeout, 回调放入宏任务队列中
2. 发现在初始化 promise 实例, 初始化过程中打印 middle, 初始化完毕后 promise 状态变为 resolve
3. resolve 后因为后面的.then()将回调放当前入微任务队列中
4. 打印 end, script 完成
5. 第一次 event loop:
   1. 由于 script 完成, 相当于完成了宏任务
   2. 检查微任务队列, 发现有一个在第 3 步放入的微任务, 执行打印 event loop1, microtask1, 继续执行, 发现有setTimeout, 将其中回调放入宏任务队列中
6. 第二次 event loop:
   1. 检查宏任务队列, 发现排在最前面的是第 1 步放入的宏任务, 执行打印 event loop2, macrotask
   2. 继续执行, 发现在初始化 promise 实例, 打印 event loop2, macrotask continue
   3. promise 在状态被 resolve 之后回调放入当前微任务队列中
   4. 检查微任务队列, 发现有一个在第 6.3 中的微任务, 执行打印 event loop2, microtask1
7. 第三次 event loop:
   1. 发现在第 5.2 步中放入的最后一个宏任务, 执行并打印 event loop3, macrotask

一个相关问题

前两天在知乎看到的一个问题: JavaScript的DOM事件回调不是宏任务吗，为什么在本次微任务队列触发

console.log('本轮任务');
new Promise((resolve, reject) => {
  resolve(3)
}).then(() => {
  console.log('本轮微任务');
})
document.getElementById('div').addEventListener('click', () => { console.log('click'); })
document.getElementById('div').click()

// 本轮任务
// click
// 本轮微任务

这里注意: click()和dispatchEvent()等人工合成事件是同步触发的, 其回调并非会被放入宏任务队列中, 而是直接作为同步任务执行, 具体答案可以参考这个回答 和补充

参考

• https://zhuanlan.zhihu.com/p/75572565
• https://juejin.im/post/5b73d7a6518825610072b42b
• https://blog.sessionstack.com/how-javascript-works-event-loop-and-the-rise-of-async-programming-5-ways-to-better-coding-with-2f077c4438b5
• https://stackoverflow.com/questions/25915634/difference-between-microtask-and-macrotask-within-an-event-loop-context
• https://jakearchibald.com/2015/tasks-microtas
• https://www.zhihu.com/question/362096226/answer/944729236

该篇文章主要使用一个 demo, 针对使用传统 props&state, context, redux 做状态管理来进行性能优化.

Demo 效果大致如下:

三种方法均尝试实现同一个效果, 有三个 room, 每个 room 是一个组件, 可以通过点击按钮改变背景颜色, 并且原则上改变其中一个 room 的背景颜色时其他 room 不会被重新渲染, 可以通过 console 里的输出查看.

完整代码如下: https://stackblitz.com/edit/react-tqmejp

一些基本总结

首先放一些有关 React 渲染和 Context 的总结:

• React 默认递归式的渲染组件, 所以当一个父组件被渲染时, 所有子组件默认也会被渲染
• Class 组件的 this.setState(), this.forceUpdate(), hooks 组件的 useState 的 setters, useReducer 的 dispatches 都会触发该组件的 re-render
• React.memo() 可以跳过一些无必要渲染, 如果该组件的 props 和上一次对比没有改变
• Context providers 会比较提供的 value 的引用, 这个 value 可以是任意类型, 比如一个字符串, 一个对象, 但注意的是如果该 value 的引用发生改变, 所有 consumers 会 re-render, 即使该 consumer 只用到了 value 的一部分, 比如 value 对象的某个属性值.
• 一个好的建议是, 在 context provider 下的子组件用 React.memo() 包裹, 这样即使 context value 发生了改变导致 re-render, 或者因为 React 本身递归式的渲染, 这些被包裹的组件可能能避免 re-render

更详细的说明和总结可以查看这两篇文章:

• Blogged Answers: A (Mostly) Complete Guide to React Rendering Behavior
• Blogged Answers: Why React Context is Not a "State Management" Tool (and Why It Doesn't Replace Redux)

Props & State

先看最简单的使用 props 和 state 实现的 demo:

import React, { useState } from 'react';

const Room = ({ isLit, flipLight, index }) => {
  console.log('render room', index);

  return (
    <div className={`room ${isLit ? 'lit' : 'dark'}`}>
      Room {index} is {isLit ? 'lit' : 'dark'}
      <br />
      <button onClick={() => flipLight(index)}>Flip</button>
    </div>
  );
};

export default function PropsStateDemo() {
  const [lights, setLights] = useState([true, false, false]);

  const flipLight = (index) => {
    setLights((lights) =>
      lights.map((light, i) => (i === index ? !light : light))
    );
  };

  return (
    <div>
      <p className="title">Props and State Demo</p>
      {[0, 1, 2].map((index) => (
        <Room
          key={index}
          isLit={lights[index]}
          flipLight={memoedFlipLight}
          index={index}
        />
      ))}
    </div>
  );
}

虽然功能上实现了, 但是存在性能问题, 每当点击其中一个 room 的 flip 按钮, 其余 room 组件一样会被重新渲染, 具体效果大致如下:

原因也很简单, 每次点击按钮触发 flipLight 方法, 都会触发父组件 PropsStateDemo 里的 setLights, lights 状态改变. 由于默认行为是父组件被渲染时, 子组件也会默认被渲染. 因此所有 Room 组件都被渲染了一次

优化也很简单, Room 组件的 props 分别是 isLit, flipLight, index. 每一个 Room 组件的 isLit 都应该是独立的, 也就是说当某个 Room 改变了 isLit 状态, 虽然这会导致 lights 状态变更, 且确实无法避免, 因为 lights 状态是一个数组, 但单个的 isLit 状态是独立的, 别的 Room 的 isLit 状态是不会影响到其他 Room 的. 同理 index 也是独立的. 而 flipLight 这个函数每次在父组件渲染的时候都会被传一份新的引用, 那尝试保证引用不变就行了.

所以只要用 React.memo() 包裹 Room 组件, 同时使用 useCallback 保证每次 flipLight 引用一样即可

优化后的代码:

import React, { useState, useCallback } from 'react';

const MemoedRoom = React.memo(({ isLit, flipLight, index }) => {
  console.log('render room', index);

  return (
    <div className={`room ${isLit ? 'lit' : 'dark'}`}>
      Room {index} is {isLit ? 'lit' : 'dark'}
      <br />
      <button onClick={() => flipLight(index)}>Flip</button>
    </div>
  );
});

export default function PropsStateDemo() {
  const [lights, setLights] = useState([true, false, false]);

  const memoedFlipLight = useCallback((index) => {
    setLights((lights) =>
      lights.map((light, i) => (i === index ? !light : light))
    );
  }, []);

  return (
    <div>
      <p className="title">Props and State Demo</p>
      {[0, 1, 2].map((index) => (
        <MemoedRoom
          key={index}
          isLit={lights[index]}
          flipLight={memoedFlipLight}
          index={index}
        />
      ))}
    </div>
  );
}

效果即是开头贴的示例效果, 就不重复放了.

Context

虽然这里完全没有必要使用到 Context, 但为了演示模拟一下.

import React, { useState, useContext } from 'react';

const RoomContext = React.createContext();

const RoomProvider = ({ children }) => {
  const [lights, setLights] = useState([false, true, false]);

  const flipLight = (index) => {
    setLights((lights) =>
      lights.map((light, i) => (i === index ? !light : light))
    );
  };

  const value = {
    lights,
    flipLight,
  };

  return <RoomContext.Provider value={value}>{children}</RoomContext.Provider>;
};

const Room = ({ index }) => {
  const { lights, flipLight } = useContext(RoomContext);
  const isLit = lights[index];

  console.log('render room', index);

  return (
    <div className={`room ${isLit ? 'lit' : 'dark'}`}>
      Room {index} is {isLit ? 'lit' : 'dark'}
      <br />
      <button onClick={() => flipLight(index)}>Flip</button>
    </div>
  );
};

export default function ContextDemo() {
  return (
    <div>
      <p className="title">Context Demo</p>
      <RoomProvider>
        {[0, 1, 2].map((index) => (
          <Room key={index} index={index} />
        ))}
      </RoomProvider>
    </div>
  );
}

和之前一样, 当更改其中一个 Room 的背景颜色后, 其余 Room 也会被重新渲染. 原因为, flipLight 会导致 RoomProvider 重新渲染, 导致每次产生一份新的 value, value 引用变化导致所有 Room 作为 consumer 都被重新渲染了

如果按照之前的做法, 尝试用 React.memo, useMemo 和 useCallback 进行性能优化, 代码大致如下:

const RoomProvider = ({ children }) => {
  const [lights, setLights] = useState([false, true, false]);

  const memoedFlipLight = useCallback((index) => {
    setLights((lights) =>
      lights.map((light, i) => (i === index ? !light : light))
    );
  }, []);

  const memoedValue = useMemo(
    () => ({
      lights,
      flipLight: memoedFlipLight,
    }),
    [lights, memoedFlipLight]
  );

  return <RoomContext.Provider value={value}>{children}</RoomContext.Provider>;
}

const Room = React.memo(({ index }) => {
  const { lights, flipLight } = useContext(RoomContext);
  // ...
})

仍旧失败, 原因在于, 虽然使用 React.memo 包裹了 Room 组件, 但由于内部又使用了 useContext, 同时 lights 状态其实每次都是变化的, 因此即使使用了 useMemo, 每次 value 还是不一样, 这样 Room 组件作为消费者又被迫重新被渲染.

要解决这个问题需要将 useContext 抽出来, 也就是不能再 React.memo 里使用, 因为 React.memo 优化只针对 props. 同时因为 lights 一直变化的缘故, 传递的状态最好和之前一样是 isLit 这种单一的状态, 而非整个完整的状态. 修改后的代码如下:

import React, { useState, useContext, useCallback, useMemo } from 'react';

const RoomContext = React.createContext();

const RoomProvider = ({ children }) => {
  const [lights, setLights] = useState([false, true, false]);

  const memoedFlipLight = useCallback((index) => {
    setLights((lights) =>
      lights.map((light, i) => (i === index ? !light : light))
    );
  }, []);

  const memoedValue = useMemo(
    () => ({
      lights,
      flipLight: memoedFlipLight,
    }),
    [lights, memoedFlipLight]
  );

  return <RoomContext.Provider value={memoedValue}>{children}</RoomContext.Provider>;
};

const withRoom =
  (Component) =>
  ({ index }) => {
    const { lights, flipLight } = useContext(RoomContext);

    return (
      <Component index={index} isLit={lights[index]} flipLight={flipLight} />
    );
  };

const MemoedRoom = withRoom(
  React.memo(({ index, isLit, flipLight }) => {
    console.log('render room', index);

    return (
      <div className={`room ${isLit ? 'lit' : 'dark'}`}>
        Room {index} is {isLit ? 'lit' : 'dark'}
        <br />
        <button onClick={() => flipLight(index)}>Flip</button>
      </div>
    );
  })
);

export default function ContextDemo() {
  return (
    <div>
      <p className="title">Context Demo</p>
      <RoomProvider>
        {[0, 1, 2].map((index) => (
          <MemoedRoom key={index} index={index} />
        ))}
      </RoomProvider>
    </div>
  );
}

这里新抽出一个高阶函数 withRoom, 在这个高阶组件里进行 context 的消费, 然后返回需要的组件, 传递的 props 均为单一的属性, 而非一直会变化的 lights 状态, 这样 React.memo 就能进行优化了.

可以看到这样的优化代码非常丑陋, 而且可能会需要花费一些时间.

Redux

如果使用 Redux 来编写一般就不需要考虑这些性能优化的问题, 因为 Redux 内部其实都有做好这些脏活. 这里使用 Redux Toolkit 实现:

import React from 'react';
import { configureStore, createSlice } from '@reduxjs/toolkit';
import { Provider, useSelector, useDispatch } from 'react-redux';

const {
  actions: { flipLight },
  reducer: roomReducer,
} = createSlice({
  name: 'room',
  initialState: {
    lights: [false, false, true],
  },
  reducers: {
    flipLight: (state, action) => {
      state.lights[action.payload] = !state.lights[action.payload];
    },
  },
});

const store = configureStore({
  reducer: {
    room: roomReducer,
  },
});

function Room({ index }) {
  const isLit = useSelector((state) => state.room.lights[index]);
  const dispatch = useDispatch();

  console.log('render room', index);

  return (
    <div className={`room ${isLit ? 'lit' : 'dark'}`}>
      Room {index} is {isLit ? 'lit' : 'dark'}.
      <br />
      <button onClick={() => dispatch(flipLight(index))}>Flip</button>
    </div>
  );
}

function ReduxDemo() {
  return (
    <div>
      <p className="title">Redux Demo</p>
      {[0, 1, 2].map((index) => (
        <Room key={index} index={index} />
      ))}
    </div>
  );
}

export default function Root() {
  return (
    <Provider store={store}>
      <ReduxDemo />
    </Provider>
  );
}

这里使用了 useSelector 进行状态的获取, useSelector 默认行为是在一个 action 被 dispatch 之后, 会对返回的选取状态进行严格比较, 如果相同组件不渲染, 否则重新渲染. isLit 作为 primitive type, 能够进行严格地址比较, 因此不再触发重新渲染.

当然也可以使用 connect 和 mapState, 而且性能方面会比 useSelector 更好, 因为做的是浅比较, 且 connect 返回的组件是用 React.memo 包裹的. 这里不多细究, 细节方面可以查阅官方文档

总结

这篇文章的示例参考的是一个视频: React Context API vs. Redux 有兴趣可以观看视频, 印象可能更深

参考

• https://blog.isquaredsoftware.com/2020/05/blogged-answers-a-mostly-complete-guide-to-react-rendering-behavior
• https://www.youtube.com/watch?v=giSbnDTJ8Ao

水文一篇...

其实这里要讲两个事情, 但是由于这两个东西可以写的东西都不多, 所以就用一篇文章了. 另外这两个东西几乎没有任何关联性

window resizing

业务上碰到的一个需求, 我需要监听 window 在什么时候 resizing 结束, 在结束的那一刻我可以做一个标记, 比如最简单的进行一次 setState

错误思路

一开始没想太多, 直接写. 写到一半发现不对了. 代码可能长这样:

import React, { useState, useEffect } from "react";

export default function WindowResize() {
  const [windowResizing, setWindowResizing] = useState(false);

  const handleWindowResize = e => {
    setWindowResizing(true);
  };

  useEffect(() => {
    window.addEventListener("resize", handleWindowResize);

    return () => window.removeEventListener("resize", handleWindowResize);
  }, []);

  return <div>{JSON.stringify({ windowResizing })}</div>;
}

很明显, 最后的结果就是一旦开始 resize, windowResizing 就会一直保持 true, 即使我已经停止了 resize. 原因也很简单, resize 这个事件只会去监听 change 时候的变化, 至于什么时候 stop, 他没有暴露任何 API, 他只知道变了, 但不知道这个变了啥时候停止

但我恰恰就需要知道啥时候停止

防抖

先考虑另外一种场景, 我需要监听 resize 时候 window 的 width 变化, 但我不需要在 resize 发生每一帧都去监并显示变化, 这是一个高频率触发的事件. 比如 resize 到一半的时候, 停顿了一下, 这个频率是比正常 resize 频率低一些的, 那我在这个时候是可以去获得或者说监听到 width 变化.

实际上说了这么多就是要对 resize 事件做一个防抖(debounce)...

import React, { useState, useEffect } from "react";

const WindowWidth = () => {
  const [windowWidth, setWindowWidth] = useState(window.innerWidth);

  useEffect(() => {
    let timerId;

    const handleResize = () => {
      clearTimeout(timerId);
      timerId = setTimeout(() => {
        setWindowWidth(window.innerWidth);
      }, 200);
    };

    window.addEventListener("resize", handleResize);

    return () => window.removeEventListener("resize", handleResize);
  }, []);

  return <div>{JSON.stringify({ windowWidth }, null, 2)}</div>;
};

export default WindowWidth;

理解起来也不难, 这里我给了 200ms 的限制, 也就是说低于 200ms 速率的 resize 操作, handleResize 这个回调函数里的 setWindowWidth 操作还没等到 200ms, 就被 clearTimeout 掉了, 然后 timerId 又存了最新的一次操作的 id, 只要 resize 速率是低于 200ms 的, 那么一定是出现上一次操作还没来得及执行就被 clear 掉, timerId 被(下一次)最新一次的操作给覆盖. 所以 windowWidth 永远还是最初的, setState 也就不会被高频触发

直到某次 resize 操作后有大于 200ms 的停顿, 这个时候 setWindowWidth 等到了时间, 可以执行一次 setState, 虽然再开始 resize 的时候 timerId 还是被 clear 掉, 但是 setWindowWidth 已经执行过了, 因此不影响.

总结就是上一次 resize 和 下一次 resize 之间间隔在 200ms 以内, 限制对应操作, 否则允许操作函数执行

解决方案

扯了很多防抖, 其实去监听 window resize 什么时候停止, 也是类似的方案

首先要明确, 什么时候才算 resize 停止, 我可以认为没有 resize 事件后的 10s 算停止(有点长), 我也可以认为是 0.000001ms 之后算停止(太短了), 所以我还是用 200ms 作为界限, 上一次 resize 和下一次 resize 之间间隔在 200ms 以内的, 都算还在 resizing, 超过 200ms 的, 记为 resize 停止了.

代码如下:

import React, { useState, useEffect } from "react";

const WindowResize = () => {
  const [windowResizing, setWindowResizing] = useState(false);

  useEffect(() => {
    let timerId;
    const handleResize = () => {
      clearTimeout(timerId);
      setWindowResizing(true);
      timerId = setTimeout(() => {
        setWindowResizing(false);
      }, 200);
    };

    window.addEventListener("resize", handleResize);

    return () => window.removeEventListener("resize", handleResize);
  }, []);

  return <div>{JSON.stringify({ windowResizing }, null, 2)}</div>;
};

export default WindowResize;

从代码上来看, windowResizing 这个状态是一直在 true 和 false 之间切换, 但 false 状态是有延迟的. 所以可以模拟出 resize 停止的那个状态

reduce

这个函数也用的很多了, 面试也经常考让手写一个简易的.

这里想记录的是做项目时遇到的一个 immutable 或者 mutable 的写法问题, 由于真实项目的数据还要复杂和繁琐, 这里只做模拟实现

目标

[['abcde', 0.9], ['fghij', 0.8], ...] 

用 reduce 将上面的二位数组转成下面这种格式

{ abcde: 0.9, fghij: 0.8, ... }

二位数组里的数据至少有 3000 条

两种做法

直接看代码:

import React, { useState } from "react";

const arr = Array.from(Array(3000)).map(v => [
  Math.random()
    .toString(36)
    .substring(7),
  Math.random()
]);

export default function App() {
  const [data1, setData1] = useState("immutable");
  const [data2, setData2] = useState("mutable");

  const handleR1 = () => {
    console.time("immutable in reduce");
    const r1 = arr.reduce(
      (r, v) => ({
        ...r,
        [v[0]]: v[1]
      }),
      {}
    );
    console.timeEnd("immutable in reduce");
    setData1("r1 finish");
  };

  const handleR2 = () => {
    console.time("mutable in reduce");
    const r2 = arr.reduce((r, v) => {
      r[v[0]] = v[1];
      return r;
    }, {});
    console.timeEnd("mutable in reduce");
    setData2("r2 finish");
  };

  return (
    <div>
      <div>
        <button onClick={handleR1}>{data1}</button>
      </div>
      <div>
        <button onClick={handleR2}>{data2}</button>
      </div>
    </div>
  );
}

handleR1 和 handleR2 分别是两种写法, 结果都是一样的, 对应 immutable 和 mutable. 我个人是倾向第一种. 但是第一种有一些性能问题

这里我用 console.time 和 console.timeEnd 分别记录两种操作所需要的时间, 第一种 immutable 写法的时间大致为 2000ms, 第二种 mutable 写法时间大致为 2ms, 2000 倍的差距...

效果图如下:

点击 immutable 的按钮花了很久才显示结束, 卡顿非常明显, 而 mutable 的按钮秒结束...

所以 immutable 的写法有时候可能不一定那么好?

前言

上一篇文章讲了讲如何用 TypeScript + Redux 实现 Loading 切片部分的状态, 这篇文章主要想聊一聊关于 Todo 和 Filter 这两个切片状态的具体实现, 以及关于 Redux Thunk 与 TypeScript 的结合使用.

想跳过文章直接看代码的: 完整代码

最后的效果:

Todo

首先思考一下 Todo 应该是怎样的状态, 以及可能需要涉及到的 action.

页面上的每一个 todo 实例都对应一个状态, 合起来总的状态就应该是一个数组, 这也应该是 reducer 最后返回的状态形式. 同时, 考虑 action, 应该有以下几种操作:

• 初始化页面的时候从服务端拿数据设置所有的 todos
• 增加一个 todo
• 删除一个 todo
• 更新一个 todo
• 完成 / 未完成一个 todo

这里需要注意的是, 所有的操作都需要和服务端交互, 因此我们的 action 是 "不纯的", 涉及到异步操作. 这里会使用 Redux Thunk 这个库来加持一下. Action Creator 写法也会变成对应的 Thunk 形式的 Action Creator

types

每一个 todo 的状态类型应该如下:

// store/todo/types.ts

export type TodoState = {
  id: string;
  text: string;
  done: boolean;
};

id 一般是服务端返回的, 不做过多解释. text 是 todo 的具体内容, done 属性描述这个 todo 是否被完成

actions

actionTypes

还是和之前一样, 在写 action 之前先写好对应的类型, 包括每一个 action 的 type 属性

根据上面的描述, type 有如下几种:

// store/todo/constants.ts

export const SET_TODOS = "SET_TODOS";
export type SET_TODOS = typeof SET_TODOS;

export const ADD_TODO = "ADD_TODO";
export type ADD_TODO = typeof ADD_TODO;

export const REMOVE_TODO = "REMOVE_TODO";
export type REMOVE_TODO = typeof REMOVE_TODO;

export const UPDATE_TODO = "UPDATE_TODO";
export type UPDATE_TODO = typeof UPDATE_TODO;

export const TOGGLE_TODO = "TOGGLE_TODO";
export type TOGGLE_TODO = typeof TOGGLE_TODO;

对应的 actionTypes, 就可以引用写好的常量类型了:

// store/todo/actionTypes.ts

import { TodoState } from "./types";
import {
  SET_TODOS,
  ADD_TODO,
  REMOVE_TODO,
  UPDATE_TODO,
  TOGGLE_TODO
} from "./constants";

export type SetTodosAction = {
  type: SET_TODOS;
  payload: TodoState[];
};

export type AddTodoAction = {
  type: ADD_TODO;
  payload: TodoState;
};

export type RemoveTodoAction = {
  type: REMOVE_TODO;
  payload: {
    id: string;
  };
};

export type UpdateTodoAction = {
  type: UPDATE_TODO;
  payload: {
    id: string;
    text: string;
  };
};

export type ToggleTodoAction = {
  type: TOGGLE_TODO;
  payload: {
    id: string;
  };
};

export type TodoAction =
  | SetTodosAction
  | AddTodoAction
  | RemoveTodoAction
  | UpdateTodoAction
  | ToggleTodoAction;

actionCreators

这里需要注意, todo 部分的 actions 分为同步和异步, 先来看同步的:

// store/todo/actions.ts

import {
  AddTodoAction,
  RemoveTodoAction,
  SetTodosAction,
  ToggleTodoAction,
  UpdateTodoAction
} from "./actionTypes";
import {
  ADD_TODO,
  REMOVE_TODO,
  SET_TODOS,
  TOGGLE_TODO,
  UPDATE_TODO
} from "./constants";
import { TodoState } from "./types";

export const addTodo = (newTodo: TodoState): AddTodoAction => {
  return {
    type: ADD_TODO,
    payload: newTodo
  };
};

export const removeTodo = (id: string): RemoveTodoAction => {
  return {
    type: REMOVE_TODO,
    payload: {
      id
    }
  };
};

export const setTodos = (todos: TodoState[]): SetTodosAction => {
  return {
    type: SET_TODOS,
    payload: todos
  };
};

export const toggleTodo = (id: string): ToggleTodoAction => {
  return {
    type: TOGGLE_TODO,
    payload: {
      id
    }
  };
};

export const updateTodo = (id: string, text: string): UpdateTodoAction => {
  return {
    type: UPDATE_TODO,
    payload: {
      id,
      text
    }
  };
};

同步部分没什么好说的, 核心是异步部分, 我们用 Redux Thunk 这个中间件帮助我们编写 Thunk 类型的 Action. 这种 Action 不再是纯的, 同时这个 Action 是一个函数而不再是一个对象, 因为存在往服务端请求数据的副作用逻辑. 这也是 Redux 和 Flow 的一个小区别(Flow 规定 Action 必须是纯的)

首先我们需要配置一下 thunk, 以及初始化一下 store

// store/index.ts

import { combineReducers, createStore, applyMiddleware } from "redux";
import thunk from "redux-thunk";
import { loadingReducer } from "./loading/reducer";
import { todoReducer } from "./todo/reducer";

const rootReducer = combineReducers({
  todos: todoReducer,
  loading: loadingReducer,
  // filter: filterReducer,
});

export type RootState = ReturnType<typeof rootReducer>;

export const store = createStore(rootReducer, applyMiddleware(thunk));

Thunk Action Creator

不考虑类型, 如果纯用 JavaScript 写一个 Thunk ActionCreator, 如下:

export const setTodosRequest = () => {
  return dispatch => {
    dispatch(setLoading("加载中..."));
    return fetch(baseURL)
      .then(res => res.json())
      .then(data => {
        dispatch(setTodos(data));
        dispatch(unsetLoading());
      });
  };
};

这里的 baseURL 在我第一章有说, 用了 mock api 模拟后端的数据, 具体地址可以看文章或者看源码, 同时为了方便, 我直接用浏览器原生的 fetch 做 http 请求了, 当然用 axios 等别的库也是可以的

关于这个函数简单说明一下, 这里的 setTodosRequest 就是一个 Thunk ActionCreator, 返回的 (dispatch) => {} 就是我们需要的 Thunk Action, 可以看到这个 Thunk Action 是一个函数, Redux Thunk 允许我们将 Action 写成这种模式

下面为这个 Thunk ActionCreator 添加类型, Redux Thunk 导出的包里有提供两个很重要的泛型类型:

• ThunkDispatch
• ThunkAction

首先是 ThunkDispatch, 具体定义如下

/**
 * The dispatch method as modified by React-Thunk; overloaded so that you can
 * dispatch:
 *   - standard (object) actions: `dispatch()` returns the action itself
 *   - thunk actions: `dispatch()` returns the thunk's return value
 *
 * @template TState The redux state
 * @template TExtraThunkArg The extra argument passed to the inner function of
 * thunks (if specified when setting up the Thunk middleware)
 * @template TBasicAction The (non-thunk) actions that can be dispatched.
 */
export interface ThunkDispatch<
  TState,
  TExtraThunkArg,
  TBasicAction extends Action
> {
  <TReturnType>(
    thunkAction: ThunkAction<TReturnType, TState, TExtraThunkArg, TBasicAction>,
  ): TReturnType;
  <A extends TBasicAction>(action: A): A;
  // This overload is the union of the two above (see TS issue #14107).
  <TReturnType, TAction extends TBasicAction>(
    action:
      | TAction
      | ThunkAction<TReturnType, TState, TExtraThunkArg, TBasicAction>,
  ): TAction | TReturnType;
}

至于具体怎么实现我不关心, 我关心的是这个东西是啥以及这个泛型接受哪些类型参数, 整理一下如下:

• 这个 dispatch 类型是由 Redux Thunk 修改过的类型, 你可以用它 dispatch:
  • 标准的 action(一个对象), dispatch() 函数返回这个对象 action 本身
  • thunk action(一个函数), dispatch() 函数返回这个 thunk action 函数的返回值
• 接受三个参数: TState, TExtraThunkArg, TBasicAction
  • TState: Redux store 的状态(RootState)
  • TExtraThunkArg: 初始化 thunk 中间件时, 传个 thunk 的额外参数(这个项目我们没用到)
  • TBasicAction: 非 Thunk 类型的 action, 即标准的对象 action 类型

再看一下 ThunkAction:

/**
 * A "thunk" action (a callback function that can be dispatched to the Redux
 * store.)
 *
 * Also known as the "thunk inner function", when used with the typical pattern
 * of an action creator function that returns a thunk action.
 *
 * @template TReturnType The return type of the thunk's inner function
 * @template TState The redux state
 * @template TExtraThunkARg Optional extra argument passed to the inner function
 * (if specified when setting up the Thunk middleware)
 * @template TBasicAction The (non-thunk) actions that can be dispatched.
 */
export type ThunkAction<
  TReturnType,
  TState,
  TExtraThunkArg,
  TBasicAction extends Action
> = (
  dispatch: ThunkDispatch<TState, TExtraThunkArg, TBasicAction>,
  getState: () => TState,
  extraArgument: TExtraThunkArg,
) => TReturnType;

整理一下参数类型和代表的意思:

• ThunkAction 指代的是一个 thunk action, 或者也叫做 thunk inner function
• 四个类型参数: TReturnType, TState, TExtraThunkArg, TBasicAction
  • TReturnType: 这个 thunk action 函数最后的返回值
  • TState: Redux store 的状态(RootState)
  • TExtraThunkArg: 初始化 thunk 中间件时, 传个 thunk 的额外参数(这个项目我们没用到)
  • TBasicAction: 非 Thunk 类型的 action, 即标准的对象 action 类型

看完发现, 其实 ThunkAction 和 ThunkDispatch 真的很像, 对应到具体的参数类型:

• TState 我们是有的, 即之前写过的 RootState
• TExtraThunkArg 我们没有用到, 可以直接给 void 或者 unknown
• TBasicAction 我们还没定义, 我见过有用 Redux 的 AnyAction 来替代, 但是 AnyAction 这个 any 有点过分...我搜索了一下没找到官方的最佳实践, 就打算用所有的 Redux 的 Action 类型集合

以及, Redux 官网的 Usage with Redux Thunk 其实已经有写怎么配置类型了. 现在需要做的事情其实就很简单:

• 增加一个 RootAction 类型, 为所有的非 Thunk 类型的 Action 的类型的集合
• 给 ThunkDispatch 这个泛型传入正确类型
• 给 ThunkAction 这个泛型传入正确类型

store 部分的代码如下:

// store/index.ts

import { combineReducers, createStore, applyMiddleware } from "redux";
import { todoReducer } from "./todo/reducer";
import { loadingReducer } from "./loading/reducer";
import thunk, { ThunkDispatch, ThunkAction } from "redux-thunk";
import { LoadingAction } from "./loading/actionTypes";
import { TodoAction } from "./todo/actionTypes";

const rootReducer = combineReducers({
  todos: todoReducer,
  loading: loadingReducer,
  // filter: filterReducer,
});

export type RootState = ReturnType<typeof rootReducer>;
export type RootAction = LoadingAction | TodoAction;

export const store = createStore(rootReducer, applyMiddleware(thunk));

export type AppDispatch = ThunkDispatch<RootState, void, RootAction>;
export type AppThunk<ReturnType = void> = ThunkAction<
  ReturnType,
  RootState,
  void,
  RootAction
>;

为了方便, 这里给了两个 alias, 也是根据官网来的, 分别为 AppDispatch 和 AppThunk

现在可以完善之前的 Thunk ActionCreator 的类型了:

export const setTodosRequest = (): AppThunk<Promise<void>> => {
  return dispatch => {
    dispatch(setLoading("加载中..."));
    return fetch(baseURL)
      .then(res => res.json())
      .then(data => {
        dispatch(setTodos(data));
        dispatch(unsetLoading());
      });
  };
};

这里注意一下, 由于我们的 thunk action, 是有返回值的, 这里是 return fetch() 返回的是一个 promise, 不过这个 promise 并没有 resolve 任何值, 所以即为 Promise<void>

最后完善一下所有的 actionCreator:

// store/todo/actions.ts

import {
  AddTodoAction,
  RemoveTodoAction,
  SetTodosAction,
  ToggleTodoAction,
  UpdateTodoAction
} from "./actionTypes";
import { setLoading, unsetLoading } from "../loading/actions";
import {
  ADD_TODO,
  REMOVE_TODO,
  SET_TODOS,
  TOGGLE_TODO,
  UPDATE_TODO
} from "./constants";
import { TodoState } from "./types";
import { AppThunk } from "../index";
import { baseURL } from "../../api";

// https://github.com/reduxjs/redux/issues/3455
export const addTodo = (newTodo: TodoState): AddTodoAction => {
  return {
    type: ADD_TODO,
    payload: newTodo
  };
};

export const removeTodo = (id: string): RemoveTodoAction => {
  return {
    type: REMOVE_TODO,
    payload: {
      id
    }
  };
};

export const setTodos = (todos: TodoState[]): SetTodosAction => {
  return {
    type: SET_TODOS,
    payload: todos
  };
};

export const toggleTodo = (id: string): ToggleTodoAction => {
  return {
    type: TOGGLE_TODO,
    payload: {
      id
    }
  };
};

export const updateTodo = (id: string, text: string): UpdateTodoAction => {
  return {
    type: UPDATE_TODO,
    payload: {
      id,
      text
    }
  };
};

export const setTodosRequest = (): AppThunk<Promise<void>> => {
  return dispatch => {
    dispatch(setLoading("加载中..."));
    return fetch(baseURL)
      .then(res => res.json())
      .then(data => {
        dispatch(setTodos(data));
        dispatch(unsetLoading());
      });
  };
};

export const addTodoRequest = (text: string): AppThunk<Promise<void>> => {
  return dispatch => {
    return fetch(baseURL, {
      method: "POST",
      headers: {
        "Content-Type": "application/json"
      },
      body: JSON.stringify({ text, done: false })
    })
      .then(res => res.json())
      .then((data: TodoState) => {
        dispatch(addTodo(data));
      });
  };
};

export const removeTodoRequest = (todoId: string): AppThunk<Promise<void>> => {
  return dispatch => {
    return fetch(`${baseURL}/${todoId}`, {
      method: "DELETE"
    })
      .then(res => res.json())
      .then(({ id }: TodoState) => {
        dispatch(removeTodo(id));
      });
  };
};

export const updateTodoRequest = (
  todoId: string,
  text: string
): AppThunk<Promise<void>> => {
  return dispatch => {
    return fetch(`${baseURL}/${todoId}`, {
      method: "PUT",
      headers: {
        "Content-Type": "application/json"
      },
      body: JSON.stringify({ text })
    })
      .then(res => res.json())
      .then(({ id, text }: TodoState) => {
        dispatch(updateTodo(id, text));
      });
  };
};

export const toogleTodoRequest = (
  todoId: string,
  done: boolean
): AppThunk<Promise<void>> => {
  return dispatch => {
    return fetch(`${baseURL}/${todoId}`, {
      method: "PUT",
      headers: {
        "Content-Type": "application/json"
      },
      body: JSON.stringify({ done })
    })
      .then(res => res.json())
      .then(({ id }: TodoState) => {
        dispatch(toggleTodo(id));
      });
  };
};

这里说一点题外话, 其实 Redux 不用 Thunk 这种 middleware 来做异步请求也是可以的, 但是为啥还会有 Redux Thunk 这些库存在呢. 具体细节我之前写过一个回答, 有兴趣可以看一看: redux中间件对于异步action的意义是什么？

reducer

编写完复杂的 ActionCreator, reducer 相比就简单很多了, 这里直接贴代码了:

// store/todo/reducer.ts

import { Reducer } from "redux";
import { TodoAction } from "./actionTypes";
import {
  ADD_TODO,
  REMOVE_TODO,
  SET_TODOS,
  TOGGLE_TODO,
  UPDATE_TODO
} from "./constants";
import { TodoState } from "./types";

const initialState = [];

export const todoReducer: Reducer<Readonly<TodoState>[], TodoAction> = (
  state = initialState,
  action
) => {
  switch (action.type) {
    case SET_TODOS:
      return action.payload;
    case ADD_TODO:
      return [...state, action.payload];
    case REMOVE_TODO:
      return state.filter(todo => todo.id !== action.payload.id);
    case UPDATE_TODO:
      return state.map(todo => {
        if (todo.id === action.payload.id) {
          return { ...todo, text: action.payload.text };
        }
        return todo;
      });
    case TOGGLE_TODO:
      return state.map(todo => {
        if (todo.id === action.payload.id) {
          return { ...todo, done: !todo.done };
        }
        return todo;
      });
    default:
      return state;
  }
};

写完 reducer 记得在 store 中写入 combineReducer()

selectors

最后是 selectors, 由于这部分是需要和 filter 切片进行协作, filter 部分下面会讲, 这里先贴代码, 最后可以再回顾

// store/todo/selectors.ts

import { RootState } from "../index";

export const selectFilteredTodos = (state: RootState) => {
  switch (state.filter.status) {
    case "all":
      return state.todos;
    case "active":
      return state.todos.filter(todo => todo.done === false);
    case "done":
      return state.todos.filter(todo => todo.done === true);
    default:
      return state.todos;
  }
};

export const selectUncompletedTodos = (state: RootState) => {
  return state.todos.filter(todo => todo.done === false);
};

todo 部分基本完成了, 最后有一个点, Redux 文档中其实一直有提到, 不过之前我一直忽略, 这次看了 redux 文档到底说了什么（上） 文章才有注意到, 就是 Normalizing State Shape. 这部分是关于性能优化的, 我自己的项目包括实习的公司项目其实从来都没有做过这一部分, 因此实战经验为 0. 有兴趣的可以去看看

Filter

最后一个状态切片 filter, 这部分主要是为了帮助选择展示的 todo 部分. 由于这部分较为简单, 和 loading 部分类似, 居多为代码的罗列

types

回顾之前想要实现的效果, TodoApp 底部是一个类似 tab 的组件, 点击展示不同状态的 todos. 总共是三部分:

• 全部(默认)
• 未完成
• 已完成

编写一下具体的类型:

// store/filter/types.ts

export type FilterStatus = "all" | "active" | "done";

export type FilterState = {
  status: FilterStatus;
};

actions

actionTypes

// store/filter/constants.ts

export const SET_FILTER = "SET_FILTER";
export type SET_FILTER = typeof SET_FILTER;

export const RESET_FILTER = "RESET_FILTER";
export type RESET_FILTER = typeof RESET_FILTER;

// store/filter/actionTypes.ts

import { SET_FILTER, RESET_FILTER } from "./constants";
import { FilterStatus } from "./types";

export type SetFilterAction = {
  type: SET_FILTER;
  payload: FilterStatus;
};

export type ResetFilterAction = {
  type: RESET_FILTER;
};

export type FilterAction = SetFilterAction | ResetFilterAction;

actions

// store/filter/actions.ts

import { SetFilterAction, ResetFilterAction } from "./actionTypes";
import { SET_FILTER, RESET_FILTER } from "./constants";
import { FilterStatus } from "./types";

export const setFilter = (filterStatus: FilterStatus): SetFilterAction => {
  return {
    type: SET_FILTER,
    payload: filterStatus
  };
};

export const resetFilter = (): ResetFilterAction => {
  return {
    type: RESET_FILTER
  };
};

reducer

import { Reducer } from "redux";
import { FilterAction } from "./actionTypes";
import { SET_FILTER, RESET_FILTER } from "./constants";
import { FilterState } from "./types";

const initialState: FilterState = {
  status: "all"
};

export const filterReducer: Reducer<Readonly<FilterState>, FilterAction> = (
  state = initialState,
  action
) => {
  switch (action.type) {
    case SET_FILTER:
      return {
        status: action.payload
      };
    case RESET_FILTER:
      return {
        status: "done"
      };
    default:
      return state;
  }
};

Store

最后将所有 store 底下的 actions, reducers 集成一下, store 文件如下:

import { combineReducers, createStore, applyMiddleware } from "redux";
import { todoReducer } from "./todo/reducer";
import { filterReducer } from "./filter/reducer";
import { loadingReducer } from "./loading/reducer";
import thunk, { ThunkDispatch, ThunkAction } from "redux-thunk";
import { FilterAction } from "./filter/actionTypes";
import { LoadingAction } from "./loading/actionTypes";
import { TodoAction } from "./todo/actionTypes";

const rootReducer = combineReducers({
  todos: todoReducer,
  filter: filterReducer,
  loading: loadingReducer
});

export type RootState = ReturnType<typeof rootReducer>;
export type RootAction = FilterAction | LoadingAction | TodoAction;

export const store = createStore(rootReducer, applyMiddleware(thunk));

export type AppDispatch = ThunkDispatch<RootState, void, RootAction>;

export type AppThunk<ReturnType = void> = ThunkAction<
  ReturnType,
  RootState,
  void,
  RootAction
>;

总结

至此所有关于 store 部分的代码已经全部完成了. 下一篇文章也就是最后一篇文章会完成 UI 部分, 讲一讲关于 React, Hooks 和 TypeScript 以及 React Redux 里相关 Hooks 的使用

参考

• https://zhuanlan.zhihu.com/p/270583963
• https://github.com/learn-redux/learn-redux
• https://redux.js.org/recipes/usage-with-typescript
• https://react-redux.js.org/using-react-redux/static-typing
• https://redux-toolkit.js.org/usage/usage-with-typescript

noUncheckedIndexedAccess

其实没啥聊的, 这个配置属于 4.1 版本的一个新 feature, 该属性的作用在于使用索引访问某类型属性时, 该类型属性会被加上 undefined 类型:

Turning on noUncheckedIndexedAccess will add undefined to any un-declared field in the type.

举个例子: 在没有该配置的情况下, 访问一个普通的 array 的类型如下:

const arr = [1, 2, 3] // `arr` type is `number[]`

const x = arr[0] // `x` type is `number`
const y = arr[1000] // `y` type is `number`

实际上这样的类型是不特别准确的, 由于 arr 这个数组长度没有限制, ts 没有足够的信息去判断其元素到底有多少个, 因此即使索引超过初始化定义的长度, ts 还是认为该元素"存在"

noUncheckedIndexedAccess 这一配置能够在使用索引访问时, 添加 undefined 类型:

const arr = [1, 2, 3] // `arr` type is `number[]`

const x = arr[0] // `x` type is `number | undefined`
const y = arr[1000] // `y` type is `number | undefined`

可以看到开启配置之后, 任何索引的访问都会带上 undefined 类型, 毕竟 ts 此时也不确定 arr 具体的形状是啥样了, 甚至是一个空 array 都是有可能的.

Tuple & const assertions

那如何定义固定长度的 array 类型呢? 一种方法是定义为 Tuple 类型:

const x: [number, number, number] = [1, 2, 3]

const x = arr[0] // `x` type is `number`
const y = arr[1000] // error: Tuple type '[number, number, number]' of length '3' has no element at index '9'.

当索引溢出时, 直接编译报错

第二种方法是使用 const assertions, 即断言成字面量类型:

const arr = [1, 2, 3] as const // `arr` type is `readonly [1, 2, 3]`

const x = arr[0] // `x` type is `number`
const y = arr[1000] // error: Tuple type '[number, number, number]' of length '3' has no element at index '9'.

使用这种类型断言之后, 类型会自动加上 readonly 关键字, ts 编译器就知道这种数据类型是 immutable 的, 自然长度也不会变了

以上两种方法不管 noUncheckedIndexedAccess 有没有配置, 都能正确识别索引溢出的错误

自定义类型

然而有一种情况下识别出的元素类型还是存在 undefined 类型的.

这里保持 noUncheckedIndexedAccess 配置开启, 有以下代码:

type A = [1, 2, 3]

const a: A = [1, 2, 3]

declare const i: number

const b = a[i] // `b` type is `1 | 2 | 3 | undefined`

我们仍旧使用 Tuple 类型声明数组, 并且严格规定其元素. 但访问的索引给定一个比较宽泛的类型 number, 这时候去拿数组里的元素时发现他的类型又给出了 undefined 类型

真实的场景会有, 当使用 map(), forEach() 这些方法时, 可能会有(其实并没有)如下代码:

a.forEach((v, i) => {
  const b = a[i] // `b` type is `1 | 2 | 3 | undefined`
})

这时候 v 类型是 1 | 2 | 3, 但是我自己用索引拿到的元素 b 类型却是 1 | 2 | 3 | undefined, 有点困惑...

我想 ts 编译器应该也困惑吧, 毕竟索引类型是 number 了, 它也不知道具体是哪个索引, 所以我只能又给一个 undefined, 虽然我数组的类型是严格的 Tuple

所以这里的索引 i 需要更加准确, 如果手动给的话, 即为 0 | 1 | 2. 但是该如何根据已知的数组 a 和它的类型 A 自动推断出对应的索引类型呢?

比较通用并且容易想到的一种做法是用 keyof:

declare const i: Exclude<keyof A, keyof typeof Array.prototype> // "0" | "1" | "2"

虽然最后的结果类型是 string, 但是对于索引已经够用了

IndexOf

另一种做法就是自定义一个类型, 这里叫 IndexOf, 该类型接受一个类型参数, 即数组的类型, 返回值是该数组的索引类型, 这里先看实现:

type IndexOf<
  T extends any[],
  S extends number[] = []
> = T["length"] extends S["length"]
  ? S[number]
  : IndexOf<T, [...S, S["length"]]>;

使用就非常简单了

type A = [1, 2, 3]

const a: A = [1, 2, 3]

declare const i: IndexOf<A> // 0 | 1 | 2

const b = a[i] // `b` type is `3 | 1 | 2`

最后得到的类型顺序不重要(我觉得...)

简单讲一下过程:

• T 和 S 是两个泛型参数, T 的形状是一个 array, S 类型为数字数组, 默认为一个空数组类型. 这个 S 存放了每次递归的状态, 这里后面会讲
• 第一个条件, 也就是 ? 前的 extends 语句, 这个语句是递归的终止条件, 满足条件为当 T 的长度和 S 的长度一样
• 然后是 ? 后的第一条语句, 这条语句为返回结果, 返回的是 S[number], 也就是对 S 取里面所有元素的 union 的值
• 最后是递归触发, 每次递归发生时让 S 自增, 从一开始的 [], 一直到每次递增添加一个数字, 所以最后的 S 值为 [0, 1, 2]

最后发现了一个可以做类型体操的地方: type-challenges

参考

• https://www.youtube.com/watch?v=nNse0r0aRT8

前言

上一篇文章讲了讲如何结合 Redux Thunk 完成 store 中核心 Todo 切片的状态编写. 由于关于 store 部分已经全部完成了, 这篇主要谈一谈如何使用 React-Redux 结合 React Hooks 来完成 UI 部分

该篇也是本系列最后一篇文章

想跳过文章直接看代码的: 完整代码

最后的效果:

思路

这里我简单就分为三个组件:

• App
• TodoApp
• TodoItem

组件分的多细其实完全看个人偏好, 比如这个项目, 完全可以抽成粒度更细致的, 比如添加 Todo 的输入框可以是单独一个组件, Todo 列表也可以是一个组件, 底下的 Footer 也可以成为一个独立的. 这里为了方便就不抽成很细的了

所有的组件都是用 hooks 编写, 包括 react-redux 部分. 所以关于 class 组件以及相关 react-redux 使用(比如 conntect) 可能需要自行谷歌了

App

先从最基本的开始, 这个组件需要配置一下 Store, 以及引入一下样式:

// components/App.tsx

import React from "react";
import TodoApp from "./TodoApp";
import { Provider } from "react-redux";
import { store } from "../store";
import "../style.css";
import "antd/dist/antd.css";

export default function App() {
  return (
    <Provider store={store}>
      <TodoApp />
    </Provider>
  );
}

这里提一下 css, 主要会用 antd 的一些组件, 同时有自定义一些样式, 都在 style.css 文件下, 有兴趣可以自己去查看, 不做深究

至此这个组件就写完了. 唯一的作用就是提供一个 store, 所有在该 provider 下的子组件都可以拿到里面的状态, 同时有别于原生的 context, 组件可以根据自己拿到的状态按需重新渲染, 不会出现有部分状态更新之后, 所有组件都重新渲染而造成性能问题.

TodoItem

一个 TodoItem 应该具有对应 store 上的如下操作:

• 左边有一个 checkbox 能够进行勾选 toogleTodo
• 右边有一个图标点击可以删除该 todo
• 正常情况下中间显示 todo 的内容, 但是点击可以进行修改更新内容

而一个 TodoItem 里面的数据是无法单独在这个这个组件里连接 Redux 获取的(你咋知道你要的 todo 是哪个 todo). 所以正确做法应该是在父组件(也就是 TodoApp) 里面获取数据, 通过 props 传给 TodoItem, 包括对 redux 里面 action 操作也是如此

代码如下:

// components/TodoItem.tsx

import React, { useState } from "react";
import { TodoState } from "../store/todo/types";
import { Checkbox, Input, List } from "antd";
import CloseOutlined from "@ant-design/icons/CloseOutlined";

export type TodoItemProps = {
  todo: TodoState;
  handleToogle: (todoId: string, done: boolean) => void;
  handleUpdate: (todoId: string, text: string) => Promise<void>;
  handleRemove: (todoId: string) => void;
};

const TodoItem: React.FC<TodoItemProps> = props => {
  const { todo, handleToogle, handleUpdate, handleRemove } = props;
  const [updating, setUpdating] = useState(false);
  const [text, setText] = useState(todo.text);

  const handlePressEnter = () => {
    handleUpdate(todo.id, text).then(() => setUpdating(false));
  };

  return (
    <List.Item className="todo-item" onDoubleClick={() => setUpdating(true)}>
      <span className="todo-left">
        <Checkbox
          className="todo-check"
          checked={todo.done}
          onChange={() => handleToogle(todo.id, !todo.done)}
        />
        {updating ? (
          <Input
            value={text}
            onChange={e => setText(e.target.value)}
            autoFocus
            onPressEnter={handlePressEnter}
            onBlur={() => setUpdating(false)}
          />
        ) : (
          <span className={`todo-text ${todo.done ? "done" : ""}`}>
            {todo.text}
          </span>
        )}
      </span>
      <span className="todo-right" onClick={() => handleRemove(todo.id)}>
        <CloseOutlined />
      </span>
    </List.Item>
  );
};

export default TodoItem;

TodoApp

核心组件, 需要去 Redux 里面取数据以及对应的 action, 同时初始化的时候要向服务端请求数据, 所以结构可能是这样的:

// components/TodoApp.tsx

const TodoApp: React.FC = () => {
  const dispatch = useDispatch()
  const todos = useSelector(selectFilteredTodos);

  useEffect(() => {
    dispatch(setTodosRequest());
  }, [dispatch]);

  return (
    // ...
  )
}

然而很可惜, 这样很有可能 ts 编译器会报错...直接谷歌了一下发现一个类似的问题: type-safe useDispatch with redux-thunk. 其实原因很简单, 我们现在 Dispatch 的方法不是一个标准的 Action, 这个 Action 是被 Thunk 包装过的. 包括我们直接去看一下源码:

/**
 * A hook to access the redux `dispatch` function.
 *
 * Note for `redux-thunk` users: the return type of the returned `dispatch` functions for thunks is incorrect.
 * However, it is possible to get a correctly typed `dispatch` function by creating your own custom hook typed
 * from the store's dispatch function like this: `const useThunkDispatch = () => useDispatch<typeof store.dispatch>();`
 *
 * @returns redux store's `dispatch` function
 *
 */
export function useDispatch<TDispatch = Dispatch<any>>(): TDispatch;
export function useDispatch<A extends Action = AnyAction>(): Dispatch<A>;

可以看到源码的注释也非常清晰的解释了如果用到了 Thunk 那么需要自己传入泛型类型

当然包括 React Redux 官网也有写使用套路.

所以我们只需改一下:

// components/TodoApp.tsx

import { AppDispatch } from "../store";

const TodoApp: React.FC = () => {
  const dispatch = useDispatch<AppDispatch>()
  const todos = useSelector(selectFilteredTodos);

  useEffect(() => {
    dispatch(setTodosRequest());
  }, [dispatch]);

  return (
    // ...
  )
}

后面就没什么好说的了, 要拿数据只需要 useSelector(), dispatch 一个 action 不管是不是 Thunk Action 现在类型都不会有问题了. Reac Redux 和 TypeScript 的结合相比原生的 Redux 还是好很多的

最后贴一下代码:

import React, { useEffect, useState, useCallback } from "react";
import { Input, List, Radio, Spin } from "antd";
import { useDispatch, useSelector } from "react-redux";
import { AppDispatch } from "../store";
import {
  addTodoRequest,
  removeTodoRequest,
  setTodosRequest,
  toogleTodoRequest,
  updateTodoRequest
} from "../store/todo/actions";
import { setFilter } from "../store/filter/actions";
import { FilterStatus } from "../store/filter/types";
import {
  selectFilteredTodos,
  selectUncompletedTodos
} from "../store/todo/selectors";
import { selectLoading } from "../store/loading/selectors";
import TodoItem from "./TodoItem";

const TodoApp: React.FC = () => {
  const dispatch = useDispatch<AppDispatch>();
  const todos = useSelector(selectFilteredTodos);
  const uncompletedTodos = useSelector(selectUncompletedTodos);
  const loading = useSelector(selectLoading);
  const [task, setTask] = useState("");

  useEffect(() => {
    dispatch(setTodosRequest());
  }, [dispatch]);

  const handleAddTodo = () => {
    dispatch(addTodoRequest(task)).then(() => setTask(""));
  };

  const handleToogleTodo = useCallback(
    (id: string, done: boolean) => {
      dispatch(toogleTodoRequest(id, done));
    },
    [dispatch]
  );

  const handleRemoveTodo = useCallback(
    (id: string) => {
      dispatch(removeTodoRequest(id));
    },
    [dispatch]
  );

  const handleUpdateTodo = useCallback(
    (id: string, text: string) => {
      return dispatch(updateTodoRequest(id, text));
    },
    [dispatch]
  );

  const handleFilter = (filterStatus: FilterStatus) => {
    dispatch(setFilter(filterStatus));
  };

  return (
    <div className="todo-app">
      <h1>Todo App</h1>
      <Input
        size="large"
        placeholder="新任务"
        value={task}
        onChange={e => setTask(e.target.value)}
        onPressEnter={handleAddTodo}
      />
      <Spin spinning={loading.status} tip={loading.tip}>
        <List
          className="todo-list"
          footer={
            <div className="footer">
              {uncompletedTodos.length > 0 && (
                <span className="todo-needed">
                  还剩 {uncompletedTodos.length} 项
                  <span role="img" aria-label="Clap">
                    🎉
                  </span>
                </span>
              )}
              <Radio.Group
                onChange={e => handleFilter(e.target.value)}
                size="small"
                defaultValue="all"
                buttonStyle="solid"
              >
                <Radio.Button className="filter-item" value="all">
                  全部
                </Radio.Button>
                <Radio.Button className="filter-item" value="done">
                  已完成
                </Radio.Button>
                <Radio.Button className="filter-item" value="active">
                  待完成
                </Radio.Button>
              </Radio.Group>
            </div>
          }
          bordered
          dataSource={todos}
          renderItem={todo => (
            <TodoItem
              handleRemove={handleRemoveTodo}
              handleToogle={handleToogleTodo}
              handleUpdate={handleUpdateTodo}
              todo={todo}
            />
          )}
        />
      </Spin>
    </div>
  );
};

export default TodoApp;