我有一个简单的React/Flux应用程序，使用Backbone的路由器。我遇到这样一种情况：用户创建一个对象，路径更新从/object/new到/object/:id。但是，没有必要重新呈现页面，因为组件是相同的，并且由于关联存储在ajax-create调用返回后更新自己。
目前，我只是修补了路由器，公开了一个方法，仅更新url，不实际触发特定路由方法。这感觉很hacky，并且并不能真正解决某些组件（即，小部件）需要添加/删除的情况（至少将渲染哪些组件的责任从路由器中移除），但是主要UI不需要重新呈现。
因此，这使我有三个问题：
React的一个主要价值主张是重新渲染非常便宜。
这意味着您可以进行过度的重新渲染而没有负面影响。这与Backbone完全不同，因为渲染非常昂贵，这导致您正在寻找的逻辑，即如何避免渲染。
在幕后，React通过将虚拟DOM和DOM进行差异处理来为您执行此检查。换句话说：当您在React中使用公开的render函数时，您实际上并没有渲染DOM，相反，您只是用Javascript描述了DOM的新状态。
在实践中，这意味着如果您不计算许多值，您可以每秒以60帧的速度不断重新呈现，而无需任何优化步骤。
这使您有自由完全“重新渲染”，即使您应用程序中只有很少的事情实际上发生了变化。
因此，我的建议是实际上不要尝试阻止React重新渲染整个页面，即使没有任何变化。这种逻辑会增加复杂性，您可以通过在路由更改时无条件重新呈现而无需任何成本来避免这种复杂性。从概念上讲，这也是有意义的，因为路由只是全局应用程序状态。
有能力这样做的自由是使React变得强大的主要原因之一。
这是“过早优化是万恶之源”的典型案例。
例如：我有时在mouseMove事件上全局重新呈现整个DOM层次结构，并且没有观察到性能影响。
作为一般规则，将重新呈现视为零成本操作。现在，您可能在React组件中具有一些昂贵的操作。如果是这种情况，您可以使用React的生命周期方法按需执行这些操作。特别是要查看shouldComponentUpdate，componentWillReceiveProps和componentWillUpdate。
如果您正在使用Flux并遵守不可变性范例，则可以对状态和道具进行非常便宜的引用相等性检查以按需执行工作。通过此，您可以提高性能。
通过使用shouldComponentUpdate方法，你可以在需要过多计算资源的情况下防止渲染调用。然而，我建议只有在你已经实现了复杂操作并且能够因此获得性能提升时才这样做。
对于你的情况，我建议将路由状态注入到根组件中，将其作为属性注入到根组件的子组件中，并在它们上面实现shouldComponentUpdate以避免无意义的渲染。
