我是一名半高级react 和JavaScript 开发人员，我已经制作了几个通用react 应用程序。
今天我们的 CTO 告诉我：您是否为您的应用程序使用软件架构模式？
我没有答案，他指的是Android 团队，他们的应用程序使用MVVM。
我正在贪婪地搜索，但没有找到适合这种情况的趋势方法或示例。我用过Redux、Redux-Saga、React-Context等等。
我不知道如何向我们的 CTO 解释或他的回答是什么？
因此：react 应用真的需要软件架构模式吗？
【问题讨论】：
标签： javascript reactjs mvvm redux redux-saga
React 本身对软件架构并不特别固执己见。它是一个促进可重用组件范式以及管理状态和数据共享 (props) 等内容的指南的库。在某些时候，Facebook 将其描述为 the V in MVC，但此后不再使用该营销方式，而是更抽象地称其为 A JavaScript library for building user interfaces。
当然，与 React 应用程序相关的典型工具在一起使用时确实适合某种架构。
几种可能的思考方式：
MVC 可能是开发世界中两者中知名度更高的一个。控制器 (C) 和视图模型 (VM) 之间的关键概念差异可以归结为：控制器 可以承担许多不同的职责，例如侦听事件并将它们路由到正确的方向。它是促进整个应用程序功能的粘合剂。另一方面，视图模型只是负责将数据的当前状态粘合到模型中。
因此，Facebook 最初使用“MVC 中的 V”很可能是“MVVM 中的 V”——“控制器”一词在后端开发世界中更有意义。
没有 Redux 的准系统 React 应用程序可以将数据直接拉入组件（例如 componentDidMount 中的 fetch 或利用 GraphQL），并且任何类型的数据处理都有限，可以称为简单的“VVM”模型。
View-Model (VM)：管理简单状态的组件相关代码，将数据直接传递到 View，可能直接从 View 传回数据
视图 (V)：视觉效果如何（JSX、CSS）
如果你在 Redux 中折腾，redux-saga，或者甚至开始用简单的 React 组件状态做一些疯狂的事情，你就是在引入模型操作。这个模型（M）至少可以代表两件事：
业务逻辑在实践中有时是不可取的：例如，如果您可以控制服务器，则可能值得将所有业务逻辑保存在一个位置（在服务器上），然后只为 UI 提供需要与之交互的内容用户。但是，如果您的 REST 端点有限并且需要进行一些争论（例如，在您的 sagas 中或在组件中），那将是业务逻辑。
客户端行为管理很有可能，尤其是在复杂的应用程序中，您可能会根据用户的会话向用户显示不同的内容（例如，他们是未注册用户、用户还是管理员）。您可能在包含仅供客户端使用的任何 redux 商店交互中执行此操作。
免责声明：讨论 MVC、MVVM 等可能会导致许多不同的意见，正是他们的意思 [1]。上面，我试图在我见过的常见模式以及它们如何适合 MVC/MVVM 之间进行比较，但是有很多不同的方法来处理它或更细化的方式来思考它。只要您的系统易于理解，我就不会太执着于在其上贴上标签：模块化、DRY、抽象等，在对您的用例和开发规模有意义的级别上。
[1] 更多篇幅在answers and comments to this question中讨论
【讨论】：
一个简单的 Web App 不需要 MVC、MVVM，甚至不需要 React IMO。 一个简单的 ReactJS 应用程序的可能演变，如果它尝试成为 PWA（渐进式 Web 应用程序），它可能会看到对 MVVM/MVC/ 的需求。换句话说 - 如果它试图做一些（应用程序/域）特定的逻辑 - 离线和其他一些 - 在线。这是移动应用程序开发的自然思路。然后，可以从 Local Storage 或 IndexedDB（用于 Web）或 Back-End/Rest/ 检索信息。然后，模型、存储/存储库/信息源/视图模型/或控制器/和视图的分离将是自然的，并且实际上需要所有东西才能正常工作......
【讨论】：