js实现超简单setState事务机制

在撰写hst-virtuanl-dom的过程中,和react的setState一样,我希望合并多个短时间内的update操作。比如在极短的时间内执行了两个update,如果每一个update都去刷新界面,这显然是没有必要的。因此,应该考虑一种事务机制,来实现将它们合并的目的,即短时间内的多个update合并为一个视图的更新。

react的setState是一个很难把握的操作,它是完全异步的,导致用setState更新数据之后,不能马上得到新的数据,比如:

this.setState({ name: 'tony' })
console.log(this.state.name) // 不是tony,而是当前的state.name

要得到新的state值,必须在setState的第二个参数中传入一个回调函数,用来得到更新后的state。但是蛋疼的是,如果短时间内执行了多个setState,那么回调中得到的,将是最终的state,而不是当前这个更新的值。

为了解决这个问题,我在写update的时候,分两步走,更新值是同步的,更新视图是异步的。也就是说,在update之后,可以立即使用代码来获取新的值,但是视图不需要马上更新,而如果视图更新了,可以通过promise.then进一步进行操作。使用的代码如下:

update({ name: 'tony' }).then(() => {
  console.log(this.data.name) // susan
})
console.log(this.data.name) // tony
update({ name: 'susan' })

上面这段代码看上去非常简单,但是它蕴含了一定的思想。即多个update之后,它们then内部的data是相同的。这一点极为重要,这也就实现update之后,在then内部去得到更新后的视图的可能性,而这个更新不单单包括当前的update,还包括短时间内的所有更新(当然,这也带来了不可预测问题,也就是执行了一个操作,可能得到非预期的效果)。

那么具体怎么实现呢?其实代码非常简单:

let transactionResolves = []
let transactionPromises = []
let data = {}
let timer

function update(newData) {
  data = merge(data, newData)

  transactionPromises.push(new Promise(resolve => transactionResolves.push(resolve)))

  if (timer) clearTimeout(timer)
  timer = setTimeout(() => {
    updateView(data)

    transactionResolves.forEach(resolve => resolve())
    transactionResolves = []
    transactionPromises = []
  }, 10)

  return Promise.all(transactionPromises)
}

灰色的两个函数需要自己实现,这里只是把思想表达出来。定义了两个数组,用来存放promise和resolve。每一次执行update的时候,先将promise和resolve存放到数组中。然后用一个setTimeout/clearTimeout来控制短时间内的重复操作。当更新视图完成之后,执行数组中存放的所有resolve函数,这时,Promise.all就会进入到resolved的状态,每一个执行过的update返回的promise都会进入then。

这时一个非常简陋的实现方案,由于js是单线程的,因此并不存在transaction被其他程序修改的可能。但是setTimeout会受到性能的影响,如果内部的updateView执行时间过长,就会导致下一个update排队。当然,这对于视觉上而言并没有太大的影响。

2017-10-07 | ,

已有1条评论
  1. […] 把数据保存到服务端也是个话题,但相对于获取数据,是一个相对比较隔离的,但是这里又不得不讨论,因为保存数据是不可避免的。save不参与前面讨论的那几个机制,也就是说,它是独立的一个操作,你只需要提供对应的datasource id和post data,就可以把数据save到对应的url去,因此,如果你一个api设计为restful风格,其实是可以被get和save重用的,这样可以减少register的次数。save的重要机制是一个简单的事务机制,我之前写过js实现超简单setState事务机制可以在这里用上。简单的说,就是短时间内,如果执行了多次save同一个datasource的操作,那么这几个save操作其实可以合并,没有必要每次save都去请求api,而且如果多次请求,还可能导致一些错误现象的出现,比如网路震荡引起前一个request后达到,导致保存的数据反而被前一个数据覆盖。因此,保证每一个保存是所有操作最终的合并结果反而很重要。因此,save实现了这个机制。 […]