清洁架构反应
我正处于企业级应用程序的开始，在我面前开发了2年，我想知道如何组织我的代码，同时牢记该项目将是巨大而漫长的。
我创建了一个我当前认为具有潜力的体系结构，但我不确定，因为我找不到任何以这种方式编写代码的人，而且这与您在Redux-Toolkit文档中可以找到的范式相对。
让我们从简短的解释我要实现的目标开始。我想将来使Redux-Toolkit轻松替换。我想将80％的代码与React和Redux-Toolkit脱钩，只能像外部库一样看它们，一个用于演示层，另一个用于状态管理。 我不会详细介绍应用程序，域和基础架构分离。我认为您可以轻松地找到有关DDD和干净架构的许多文章和博客。 让我们看看我到目前为止的内容，这就是计划：
这是全局，因此UI层（组件）触发Redux-toolkit Action /自定义钩 /自定义操作 /某些hotherlib操作。动作有责任注入SetState和GetState回调（即ISTATENAGMENT域接口需要），还有责任调用某些用户赛。
发生这种情况之后，用户录酶（USERSTROY）从GetState回调中获取状态副本，并实现所有业务逻辑（突变状态副本）和最终呼叫SetState回调。它还对域层具有依赖性，该域包含该模型附加的模型和逻辑。 最终，Reducer检测到从SetState回调发射的动作，并将新状态存储给国家管理层。
我还想分享有关我如何与Redux-Toolkit和Custom Hook Local Store实施的更多信息（我也使用自定义商店实施实施了此功能，但我不会谈论这个，但是您可以在GitHub上找到它）。
我已经故意实施了多个状态管理商店，以测试我可以轻松地将其替换为在我的React组件中。
这是实现派遣（或调用localstate的自定义钩）：
接下来是域状态管理接口，它定义了外部状态管理必须提供的内容：
i.sstatic.net/s0vwy.png“ rel = 正在调用USECASE，动作创建者有责任调用某些用户：
之后，我们有一个用户程序，其中所有业务逻辑都在一个地方实现：
href =“ https://i.sstatic.net/uaka7.png” rel =“ nofollow noreferrer”>
和最后一个减速器来处理setState操作：
您可以在GitHub上找到具有3个不同状态管理的整个项目： https://github.com/wingsdevelopment/react-clean-architection
我知道这一点很多，但我试图分享这一点。 我担心决定走这条路的决定。我不确定这种方法有什么弊端，如果我缺少某些东西，如果是的话，什么？
I am at the beginning of an enterprise level application with 2 years of developing in front of me, and I was wondering how to organize my code while having in mind that the project will be huge and long.
I have created an architecture that I currently believe has potential but I’m not sure since I wasn’t able to find anybody that writes code that way, and also it’s against the paradigm that you can find in redux-toolkit documentation.
Let’s start with a short explanation on what I am trying to achieve. I want to make redux-toolkit easily replaceable in the future. I want to write 80% of my code decoupled from react and redux-toolkit and only look at them like external libraries, one for presentation layer and other for state management.
I won’t go into details about the application, domain and infrastructure separation. I think you can find many articles and blogs easily about DDD and clean architecture.
Let’s see what I have so far, this is the plan:
This is the big picture, so ui layer(component) fires redux-toolkit action / custom hook / custom action/ someOtherLib action. Actions have a responsibility to inject setState and getState callbacks (that IStateManagment domain Interface requires) and also responsibility to call certain usecases.
After this happens, usecase (userStory) gets a copy of the state from getState callback and implements all of the business logic (mutates state copy) and at the end calls setState callback. It also has a dependency on the domain layer, that contains model and logic attached to that model.
And finally reducer detects action fired from setState callback and stores new state to the state management.
I would also like to share more on how I’ve implemented this with redux-toolkit and custom hook local store (I’ve also implemented this with custom store implementation but I won’t talk about that, but you can find it on github).
I’ve implemented multiple state management stores on purpose to test how easily I can replace it inside my react components.
This is the implementation of dispatching (or calling custom hook for localstate):
Next is Domain state management interface, it defines what must be provided by external state management:
Next is calling the usecase, action creators have a responsibility to call certain usecases:
After that we have a usecase where all the business logic is implemented in one place:
And at the end single reducer to handle setState action:
You can find whole projects with 3 different state managements on github:
https://github.com/WingsDevelopment/react-clean-architecture
I know this is much, but I tried to share this as clear as possible.
I am concerned about making the decision to go down this road. I am not sure what are cons of this approach and if I am missing something and if so, what?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论