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