Hanruis
Hanruis
使用 gulp-rev-all 确实可以递归查找以来并计算 hash 值。但也存在风险，比如公共部分的模块修改了，因为递归查找以来并计算 hash 的原理，会导致几乎全局的 js 的 hash 会重新计算一遍。在这种情况下达不到增量更新的效果。觉得使用 paths 来说可能会更加合理一些。当然由于频繁更新的问题，会导致资源映射表也常常更新，我觉得可以将这部分两大块，一部分是不常更新的列表，一部分是经常变动的~~
soga，因为不了解 webpack 。可以介绍一些 webpack 对于这一块处理的思路么~
谢谢，刚也看了相关的文章介绍 看了下相关的文章介绍，webpack 增量更新的思路貌似也是通过内置的一个资源表实现。
@arendjr need adds ``` req.on('abort', function () { pendingWrites.decrement() abortWithCode('CLIENT_ABORTED') }) ``` I read node doc and find that 'aborted' means the request aborted by the server, while 'abort' means...
@arendjr thx~~
内存管理方面，感觉 backbone 要哭哈。backbone 没有提供组件的管理，很容易出现 zoombie view 。 而使用 vue ，angular ，react 这些，框架都做好了。所以感觉组件销毁这一块，需要手动处理的场景不多。
看了数值关联计算的文章之后，觉得 Rx 处理操作补偿的场景，应该也很方便。每个操作都描述成一个任务，或者事务并依赖 “父任务” 的操作补偿完成。 感觉像是 saga 的概念。
@jiyinyiyong 再想的细一点。这个刷新的操作要考虑一下，如果还有任务在跑，需要等待优先级比刷新（更新）更高任务的完成。比如连续几步的操作补偿， 上传文件等任务还在执行的时候，需要等待这些完成之再执行更新。
@jiyinyiyong 要是 Rx 支持这类型的场景的话，就容易了（因为飞叔他们在用 Rx）：声明一个任务，该任务依赖于当前 Rx 中正任务队列（仅当前，而不是特定的任务）的完成。
@WingGao 作者已经合并了我的 pull request 了。 等待作者发布新的 npm 包吧。或者如果你等不及，可以先修改对应部分的源码 pull request 在这里 https://github.com/xinchaobeta/px2rem-webpack-plugin/pull/3