我是一名半高级 react 和 JavaScript 开发人员，我制作了几个通用的 react 应用程序。
今天，我们的 CTO 告诉我:您的应用程序是否使用软件架构模式？
我没有答案，他指出 Android 团队在他们的应用程序中使用 MVVM。
我正在贪婪地搜索，但没有找到这种情况的趋势方法或示例。我用过 Redux、Redux-Saga、React-Context 等
我不知道如何向我们的CTO解释或者他的回答是什么？
因此:React 应用真的需要软件架构模式吗？
最佳答案
React 本身对软件架构并不是特别自以为是。它是一个库，可促进可重用组件范例以及管理状态和数据共享(props)等事物的指南。在某个时候，Facebook 将其描述为MVC 中的 V，但此后不再采用这种营销方式，而是将其更抽象地称为用于构建用户界面的 JavaScript 库。
当然，与 React 应用程序相关的典型工具在一起使用时确实适合某种架构。
一些可能的思考方式:
简单的 React 应用可能只是“VVM”或“VC”
在开发领域，MVC 可能是两者中最著名的一个。 Controller (C) 和 View 模型 (VM) 之间的关键概念差异可以归结为: Controller 可以承担许多不同的职责，例如监听事件并将它们路由到正确的方向。它是促进整个应用程序功能的粘合剂。另一方面， View 模型 仅负责将数据的当前状态粘合到模型。
因此 Facebook 最初使用“MVC 中的 V”可能很容易就是“MVVM 中的 V”——术语 Controller 在后端开发领域更有意义。
没有 Redux 的准系统 React 应用程序将数据直接拉入组件(例如 componentDidMount 中的 fetch 或利用 GraphQL)，任何类型的数据处理都有限称为简单的“VVM”模型。
View-Model (VM):管理简单状态的组件相关代码，将数据直接传递到 View，可能直接从 View 传回数据
View (V):视觉效果(JSX、CSS)
增加一些复杂性，你可以称之为“MVVM”/“MVC”
如果您使用 Redux、redux-saga，甚至开始使用简单的 React 组件状态做一些疯狂的事情，那么您就是在引入模型操作。这个模型 (M) 至少可以表示两件事:
- 您的应用程序的实际业务逻辑
- 存储和管理客户的复杂行为
业务逻辑有时在实践中是不可取的:例如，如果您可以控制服务器，那么将所有业务逻辑放在一个地方(在服务器上)可能是值得的，并且只向 UI 提供它需要与之交互的内容用户。但是，如果您的 REST 端点有限并且需要进行一些争论(例如在您的 sagas 中或在组件中)，那将是业务逻辑。
客户端行为管理是可能的，特别是在复杂的应用程序中，您可能会根据用户的 session (例如，他们是未注册用户、用户和管理员)做一些事情，比如向用户显示不同的东西。您可能在仅供客户端使用的任何 redux 存储交互中执行此操作。
免责声明:讨论 MVC、MVVM 等可能会导致对其含义的确切产生许多不同的看法 [1]。在上文中，我试图将我见过的常见模式与它们如何适应 MVC/MVVM 进行比较，但是有很多不同的方法来处理它或更细化的思考方式。只要您的系统易于理解，我就不会太在意给它贴上标签:模块化、DRY、抽象等级别对您的用例和开发规模有意义。
[1] 在answers and comments to this question中讨论了更多篇幅
关于javascript - ReactJS 应用程序的 MVVM 架构模式，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/51506440/