我有一个球员名单，每个球员都有一个状态。我们按状态对玩家进行排序，并通过如下图标显示状态：
我需要这样做，所以当您单击播放器时，它们会立即更改状态图标，但直到延迟后顺序才会更改（出于 UX 原因）。关于最佳方法的任何想法。
以下是一些行不通的想法：
立即更改player.status（您的订单更改）。
使用超时延迟更改player.status（图标不会立即更改，感觉就像什么都没发生）。
执行 #2 并通过 jQuery 更改图标类：如果您进行了一些更改，延迟更新将进行重绘，您将丢失您设置的类。
我有的最好的主意（而且我知道这很糟糕）是：
Session.get("player-$ID-status")) 来存储状态的最新版本。会有一些烦人的管道来完成这项工作，但我认为它会。我很想听听更好的方式（或“流星”方式）来做到这一点。
我认为有几个更微妙的方法来完成你所需要的。一种方式会导致用户行为和不断变化的状态之间存在某种耦合。第二种方式是更解耦和优雅的方式，更符合流星方式。
首先，有些紧密耦合的方法：
您知道，在您的用例中，当用户指示他们希望发生更改时，播放器应该更改为新状态。我认为这里的关键是有一个间隙状态，玩家将改变到一个状态。
鉴于此细分，您可以使用两个属性来建模此行为：
player.status和player.statusWillBe
如果您以这种方式实现它，那么您可以将图标设置为 offplayer.changingToStatus和 ordering off player.status。
这意味着所有玩家都将从player.status和player.statusWillBe- 的相同值开始，然后图标将根据 中的值正确设置player.statusWillBe。
通过这种分解，您可以基于用户交互对行为进行非常细粒度的控制，但您的 ui 响应与用户行为和非 ui 组件紧密耦合。如果您继续使用这种方法，那会很快变得丑陋。您基本上会将模型/状态与 ui 混合。
更复杂的解耦方式（并且符合流星方式）：
为玩家状态更改实现状态机。然后，您可以在更改级别捕获状态更改。在状态更改后，您将使导致您的 ui 重绘的上下文无效。这种方法更简洁，因为它可以将您的 ui 与您的“模型”完全分离。Meteor 上下文及其失效是客户端 ui 重绘的关键，它基于底层模型的变化，而无需将两者紧密耦合。
我还强烈建议您使用以下截屏视频来帮助您更好地理解这种模式：Meteor reactivity with contexts。