所以我有一个使用Backbone路由器的简单React / Flux应用程序。我有一个用户创建对象的情况，路径从/object/new更新为/object/:id。但是，不需要重新呈现页面，因为组件是相同的，并且由于ajax-create调用返回后关联的存储更新，它会更新自身。
目前，我刚刚修补路由器以公开一个只更新网址的方法，并且实际上没有达到路由特定的方法。这感觉很麻烦，并没有真正解决需要添加/删除某些组件（即小部件）的情况（至少它消除了知道哪些组件需要从路由器中呈现出来的责任），但是主UI不需要重新渲染。
所以这给我留下了三个问题：
答案 0 :(得分：12)
React的主要价值主张之一是重新渲染非常便宜。
这意味着您可以过度放弃而不会产生负面影响。这是来自Backbone的完整180，渲染非常昂贵，这导致你正在寻找的逻辑，即如何避免渲染。
在引擎盖下，React通过使用DOM来区分Virtual DOM来为您进行检查。换句话说：当你在React中使用公开的渲染函数时，你并没有真正渲染DOM，而只是用Javascript描述DOM的新状态。
实际上，这意味着如果你不计算很多值，你可以不断地以每秒60帧的速度重新渲染，而无需任何优化步骤。
这使您可以自由地完全“重新渲染”，即使您的应用上只有很少的东西实际发生变化。
所以我的建议是实际上不要尝试任何东西来阻止React重新渲染整个页面，即使没有任何变化。这种逻辑会增加复杂性，您可以通过无条件地重新路由路由更改来免费避免这种复杂性。从概念的角度来看，这也是有道理的，因为路线只不过是全球应用状态。
能够做到这一点的自由是使React变得令人敬畏的主要原因之一。
这是“过早优化是万恶之源”的经典案例。
例如：我有时会在mouseMove事件上全局重新呈现整个DOM层次结构，并且没有可观察到的性能影响。
作为一般规则，将重新定位视为零成本操作。现在你的React组件可能会有一些昂贵的操作。如果是这种情况，您可以使用React的生命周期方法按需执行这些操作。特别要看一下 shouldComponentUpdate ， componentWillReceiveProps 和 componentWillUpdate 。
如果您正在使用Flux而且您遵守不变性范例，那么您可以对状态和道具进行非常便宜的参考平等检查以按需进行工作。有了这个，您可以提高性能。
使用 shouldComponentUpdate 方法，如果需要过多的计算能力，可以阻止渲染调用。但是，如果由于您自己实施的昂贵操作而导致性能提高，我只会这样做。
在你的情况下，我会在根组件中注入路由状态，将它们作为props注入到根的子节点中，并在它们上实现 shouldComponentUpdate 以防止渲染。