当使用React与Redux合并时，关注点（干净体系结构）的分离
我有问题，最近我正在研究清洁体系结构。那是： 我知道，当我想在react中使用redux时，我将必须这样做：
ReactDOM.render(
<React.StrictMode>
<Provider store={store}>
<App />
</Provider>
</React.StrictMode>,
document.getElementById('root') )
然后，我使用use -elector和usedispatch（钩子）选择数据并在我的react组件中派遣操作。 但是，我看到一个问题（我认为）。那就是我的React应用程序与此状态管理工具（REDUX）高度相结合。 因此，如果将来，Redux变得过时了，或者我不想使用Redux，我想使用后坐力，MOBX或新的现代状态管理工具等...或者，也许在我的应用中，我想使用Redux结合他人（后坐力，...）来管理我的应用状态。因此，我想要在React和Redux之间进行松散的耦合。
但是，我看到很少有人谈论这个问题。也许我正在寻找错误的关键字。或者我思考“关注点分离”的方式是有问题的。
谁能让我重新看一下这个问题？
PS：我的英语不好。我希望每个人都能得到我的问题吗？多谢。
I have a problem and I'm recently researching about Clean Architecture. That is:
I know that when I want to use Redux in React I will have to do like this:
ReactDOM.render(
<React.StrictMode>
<Provider store={store}>
<App />
</Provider>
</React.StrictMode>,
document.getElementById('root') )
and then, I use useSelector and useDispatch (hooks) to select data and dispatch an action... in my react components.
But, I see an problem (in my opinion). That is my react application is highly coupled with this state management tool (redux).
So, if in the future, Redux becomes outdated or I don't want to use redux, I want to use Recoil, MobX or new modern state management tools, etc... Or maybe, in my app, I want to use redux combined with others (Recoil,...) to manage my app state. So, I want a loose coupling between react and redux.
But, I see very few people talking about this issue. Or maybe I was searching for the wrong keywords. Or is there something wrong with my way of thinking about 'Separation of concerns' in react and redux.
Can anyone give me a fresh look at this issue?
PS: My English is not good. I hope everyone can get my issue? Thanks a lot.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我曾与两个主要的国家经理有经验： redux 和 mobx ，并且在同样的问题上挣扎。
一种可能的解决方案可能是将状态管理器逻辑与您的自定义挂钩包裹，该挂钩将接收Redux状态并触发操作。
But if you one day decide to switch to, say, Mobx, you will see that:
Mobx reactivity works in a different way than in redux.
First, you will face the将组件包裹在观察者功能中的必要性，该功能添加了组件的耦合。此外，由于 mobx 反应性依赖于 value deerectrencing ，因此需要一些精力来重构组件使其 mobx 兼容。您可以在 mobx 文档中阅读有关它。 https://mobx.js.org/understanding-reactivity.html
As i see ，如果您的组件依靠业务逻辑，则无法使其完全状态经理。
无论如何，您的React组件中将存在状态接收和状态更新逻辑，并且将您的项目放在新的轨道上将需要一些时间和精力。
The only option i see is to split React components into two types:
所有州经理逻辑都在这里。它接收应用程序状态块，触发动作，并将道具传递给UI组件。
构建DOM元素的组件。它可能具有自己的状态，但主要是渲染逻辑基于组件道具。
这将使您将来可以从更改州经理的变化中降低成本，因为您可以逐渐重写容器组件，而不必担心UI太多。
I had experience with both main React state managers: Redux and Mobx and struggled with the same question.
One possible solution might be to wrap state manager logic with your custom hooks which will receive redux state and trigger actions.
But if you one day decide to switch to, say, Mobx, you will see that:
Mobx reactivity works in a different way than in redux.
First, you will face the necessity to wrap your components in observer function which adds coupling to your components. Besides, it will take some effort to refactor your components to make it Mobx compatible because Mobx reactivity relies on value dereferencing. You can read about it in Mobx documentation. https://mobx.js.org/understanding-reactivity.html
As i see, you can't make your components fully state-manager-agnostic if they rely on business logic.
Anyway, state receiving and state updating logic will be present in your React components and it will take some time and effort to put your project on the new rails.
The only option i see is to split React components into two types:
All state-manager logic goes here. It receives application state chunks, triggers actions, and passes props to UI-components.
Component that builds DOM-elements. It may have its own state, but mainly render logic is based on component props.
This will allow you to reduce costs from changing state-manager in the future, because you can gradually rewrite your container components without worrying too much about UI.