原理介绍
Optimistic UI 是 Meteor 提出来的一种前端界面快速响应用户交互的概念，之前叫 Latency Compensation，主要作用是在客户端直接响应用户的交互，而不用等信息从客户端发送到服务器，完成更新确认，再从服务器返回客户端这一个来回完成后再做响应。有点类似游戏领域里的 Dead Reckoning，在客户端离线对用户行为进行推测，达到隐藏延时和减少带宽使用的技术。
先看下图理解 Optimistic UI 的原理。
Optimistic UI
魔法就发生在虚线处。简单来说 Method Call 其实有两个，一个在服务器端，这个是起真正作用的；另外一个在客户端，是一个模拟函数（也叫桩函数 stub function）会直接对客户端的 MiniMongo 数据库进行修改，这样用户就可以立即看到界面的更新（Meteor 的 reactive 特性会让界面根据 MiniMongo 更新），而不用等上图下半部分的蓝色 Network latency 和 Data for client-side cache 过程完成了。
再来看看几个例子。
没有使用 Optimistic UI
下图是没有 Optimistic UI 的时候。可以看到任务输入完成后过了大概 2 秒才更新。这 2 秒就是模拟的前面原理图下部的延迟。
noOpti.gif
使用 Optimistic UI
下图是使用了 Optimistic UI。可以看到任务输入完成后列表立即就有了改变，而我们看不到的是服务器端也静静地完成了更新，用户只会感觉这个系统使用起来非常流畅，体验提升。
optimistic.gif
使用 Optimistic UI，但是服务器端更新失败，前端自动回滚
下图是使用了 Optimistic UI，但是服务器端因为种种原因更新失败的过程模拟。可以看到任务输入完成后列表立即就有了更新，但是大概 2 秒后因为服务器确认更新失败，前端界面再次更新，恢复到和服务器端同步后该有的结果。当然这个过程需要更多改进来优化用户在交互失败时的体验，而不是简单粗暴的回滚回初始值。
failedOpti.gif
这就是 Meteor 的 Optimistic UI，一种积极乐观的界面更新策略，它是基于我们大部分的用户互动都是成功的预测之上。如果追求极致的用户体验，达到实时更新，可以使用 Meteor 来轻松做到，别的框架得另外写很多代码来维护这一套机制，增加工作量和出错机会。
