[前端讨论] 为什么需要乐观更新(optimistic updates )？

[ericgui]

首先，什么是optimistic updates ? 参考资料在下面：

https://stackoverflow.com/questions/33009657/what-is-optimistic-updates-in-front-end-development

第二，我的疑惑是：为什么需要乐观更新？

比如投票，一个用户投票了，投完了就关了页面。过几天他找不到他投的票了，没有成功，也没有记录。。。

这个就很困扰了。。。。

[xcstream]

投没投不重要
重要的是感觉自己已经投票了

[gkiwi]

@ericgui 我觉得你说的乐观更新概念是错误的。并不是说找不到记录了，而是说当时状态。

你看下这个的例子： https://www.jianshu.com/p/154ca94f5209

===
有个乐观更新的典型场景就是微信消息发送：
很显然消息发送出去立即显示发送出去，用户体验更好。

感觉成功率极高的操作，且符合用户脑路预期的事情，都可以考虑下乐观更新。

[ericgui]

@gkiwi 我不是说乐观更新不好，而是什么时候用比较合适？不是所有的场合都用的。

至少在某些时候，数据比较关键，我希望是保守更新，

但在点赞啊，这类的无关紧要的场合，可以用乐观更新

[deathscythe]

没看二楼的说法时, 原来我平时开发做的用户操作“乐观更新”
受教了

[seki]

如果结果很重要，比如你举的投票，那么就还是不用乐观更新了吧

此外就算关了页面，web worker 也能试图帮你把请求发出去

[ericgui]

@seki 但问题是，用户以为自己已经成功了，如果是某些比较重要的数据，用户不知道自己其实没成功，这可比等个一两秒严重得多

[jadec0der]

我感觉微博的点赞、评论都是乐观更新，掉头就找不到自己的评论了，也不知道是没发出去还是被和谐了

[ericgui]

@jadec0der Thank you! 我就这意思。感觉很不爽的。

[no1xsyzy]

如果每个操作都需要先请求个 ticket id，业务也不是很关键（比如点赞、评论），完全可以本地记录+异步请求+乐观更新+收到响应+删除记录。下次登录确认本地记录的是否有成功 —— 不成功的就重传或者提示重传。
不过乐观更新至少比盲目乐观更新好（根本无视服务器的响应内容甚至响应与否，总之提示成功）

[gkiwi]

@ericgui #3
『我不是说乐观更新不好，而是什么时候用比较合适？不是所有的场合都用的。』

我说的不是这个点。这俩肯定各有适合的场景，这个咱们是一致的。

我的点是乐观更新的定义：我理解的乐观更新是说当时的状态更新逻辑，和是否有记录没有关系。

[charlie21]

我认为（在实现方面）乐观更新和非乐观更新的实现 应该是（应该做到）能一键切换的，如果做不到 这反映了软件整体架构里的缺层