React 结合 Redux 时的关注点分离（Clean Architecture）

Question

我有一个问题，我最近正在研究 Clean Architecture。那是：我知道当我想在 React 中使用 Redux 时，我必须这样做：

ReactDOM.render(                 
   <React.StrictMode>               
       <Provider store={store}>                   
            <App />               
       </Provider>           
   </React.StrictMode>,           
document.getElementById('root') )

然后，我使用 useSelector 和 useDispatch（挂钩）到 select 数据并分派一个动作...在我的反应组件中。但是，我看到了一个问题（在我看来）。那就是我的 React 应用程序与这个状态管理工具 (redux) 高度耦合。所以，如果将来 Redux 过时了，或者我不想使用 redux，我想使用 Recoil、MobX 或新的现代状态管理工具等...或者，在我的应用程序中，我想使用 redux与其他人（Recoil，...）结合来管理我的应用程序状态。所以，我想要在 react 和 redux 之间松耦合。

但是，我看到很少有人谈论这个问题。或者，也许我在搜索错误的关键字。还是我对 'Separation of concerns' 在 react 和 redux 中的思考方式有问题。

任何人都可以让我重新审视这个问题吗？

PS: 我的英文不好。我希望每个人都能得到我的问题？非常感谢。

Answer 1

我有两个主要的 React 状态管理器的经验：Redux 和 Mobx 并且遇到了同样的问题。

一种可能的解决方案可能是使用您的自定义挂钩包装状态管理器逻辑，该挂钩将接收 redux 状态并触发操作。但是，如果有一天你决定切换到 Mobx，你会看到：

Mobx 反应性的工作方式与 redux 不同。

首先，您将面临将组件包装在 observer 函数中的必要性，这会增加组件的耦合度。此外，需要一些努力来重构您的组件以使其 Mobx 兼容，因为 Mobx 反应性依赖于 value dereferencing。您可以在 Mobx 文档中阅读相关信息。 https://mobx.js.org/understanding-reactivity.html

如我所见，如果组件依赖于业务逻辑，则无法完全 state-manager-agnostic。无论如何，状态接收和状态更新逻辑将出现在你的 React 组件中，将你的项目放在新的 rails.

上需要一些时间和精力。

我看到的唯一选择是将 React 组件拆分为两种类型：

容器组件。所有 state-manager 逻辑都在这里。它接收应用程序状态块，触发操作，并将道具传递给 UI-components.
UI-component 构建 DOM-elements 的组件。它可能有自己的状态，但主要渲染逻辑是基于组件道具。

这将使您减少将来更改 state-manager 的成本，因为您可以逐渐重写容器组件而不必太担心 UI。

React 结合 Redux 时的关注点分离（Clean Architecture）

The separation of concerns (Clean Architecture) when using React combined with Redux

reactjs

redux

react-redux

clean-architecture