因此，我们最近在我们公司选择了React作为构建我们庞大的商业Web应用程序的前端技术。最近说的是，我的意思是我们之前没有任何React的经验（我们有很多AngularJS的背景），并且通过说大量应用，我的意思是它非常庞大且非常有活力，有很多很多很多不同的部分和功能。
因为我们将拥有许多巨大的组件，它们都起着非常重要的作用，并且内部具有复杂的逻辑，并且因为我们希望它们易于插拔和重复使用，所以我们希望它们尽可能地与外部隔离世界和我们应用程序的其他部分，因为否则由于它们的大小和复杂的功能，开发和维护它们几乎是不可能的。这就是为什么我们决定不使用Redux的原因，至少在开始时，我们只是自己开发单独的组件，因为它会破坏组件隔离并使整个应用程序数据流逻辑无法理解是如此多的复杂组件。虽然我认为我们的选择可能是错误的，因为正如我已经提到的那样，我们没有React的经验。
正如我已经提到的，该应用程序非常动态。我的意思是组件实际上是由数据呈现的。我们使用与我们的API端点交互的各种配置提供程序类来获取应用程序的配置，例如导航，页面，各种表单，列表等的配置，然后尝试呈现从中读取的组件那个配置。
问题是，经过几周努力获得React的动力并发现正确的模式和我们问题的常见解决方案后，我们一直在谈论我们的工作人员，也许React不是正确的技术对我们来说，因为它是一个UI库，而不是一个框架事件，它并没有帮助我们很多，但只是添加了我们必须打破的渲染规则，以实现动态和组件独立性我们想。
考虑到组件隔离和数据流管理，我个人听说有一种语言用于前端开发Elm，它具有非常强大的数据流架构，其中每个组件都有自己独立的模型，但我不知道不知道它是否值得一试，因为它很快就会落后于我们的大需求。
我在这里写这个问题的原因是，我希望能够从那些拥有大量前端应用程序背景的人那里获得洞察力。我想知道是否有可能使用React开发这样的应用程序，无论React是否适合这种复杂性和动态，我们是否真的需要Redux或其他东西，我们应该采用什么样的路径，实践和意识形态跟随。如果你正确地理解我的问题，那么我们正在努力解决的架构方面比技术方面更多。也许我们正走的是通向越来越多的斗争和复杂的道路，而不是走向生产。
答案 0 :(得分：13)
毫无疑问，React / Redux可以（并且被广泛地）用于开发您描述的应用程序类型。您的描述中没有任何内容使您构建的内容如此独特，以至于它将React排除在构建它的平台之外。我们正积极与正在构建其整个前端的大型企业客户合作 - 在React中使用100 + SPA（单页应用程序）。这是一个由超过100名开发人员组成的团队。
我们构建这种方式至关重要 -
首先，您要选择UI组件库。以下几个例子：
我们基本上采用了其中之一并从中构建了一个组件库，因为我们的组件是非常自定义的样式。
其次，我们创建了一个模块化架构，其中每个模块（SPA）都是一个带有主容器组件和redux存储的npm包。
最后，我们有一个中央服务器包，其中每个模块都已注册。服务器包负责身份验证，授权，日志记录，路由等。
这个答案的本质并不是建议如何构建一个大的React应用程序，而是让你知道React可以（并且正在）用于开发类似于你所描述的应用程序。
答案 1 :(得分：5)
开始在React中编写更复杂的应用程序真的很困难，我确切地知道它的感觉！
正如您所说，React是一个UI lib而不是一个事件框架。这就是您通常需要一个库来处理事件的原因，例如Redux。你明确表示你决定不使用Redux（你甚至不使用大写字母:)）。如果我是你并重新考虑这个决定，我会退后一步。您说不使用Redux的原因是，在使用Redux时，您无法使组件易于插拔和重用。我认为这不是真的。 Redux完全与您的React组件分离。 Redux仅处理接收事件和管理状态。从React组件的角度来看，它只接收props中的数据并通过调用常规函数来发送事件。它仍然可以进行单元测试，重用等。
我建议你再考虑一下Redux。如果您有更多问题，很乐意提供帮助！
答案 2 :(得分：5)
你在问题中指出了问题 - 反应是一个视图库，而不是一个应用程序框架。真正的问题是React + Redux（或其他状态管理系统）是否适合大型LOB应用程序。
我将从我们团队在这个领域的经验中分享一些见解。几十年来，使用MVC / MVP / MVVM设计模式开发了大型LOB应用程序。这些是运行软件的经过验证的真实模式。结合依赖注入，你有一个模块化，可测试，可维护的应用程序。 AngularJS（2.0+）建立在这些原则的基础上并深入利用它们。出于这个原因，我们将AngularJS用于我们所有的企业级业务应用程序。
另一方面，React是一个轻量级的精灵视图渲染，对于较小的应用程序和面向客户端的部分非常棒（例如，采用动态调查或简单的仪表板）。我们经常在这里转向React和VueJS，因为完整的AngularJS堆栈有点过分和过重。
答案 3 :(得分：4)
我现在处于类似情况。我有大型桌面应用程序（ERP，LOB - WinForms，WPF）的背景 - 1000多个模块，非常动态（超过70％的UI是由输入数据/配置生成的），添加新功能只是扩展一些配置（不涉及源代码）。
我正在深入研究当前的网络技术，而且我越来越相信React并不适合这样做。 React在小型/中型应用程序中非常出色，您（和其他团队成员）可以手动开发每个页面/组件。 （不是动态生成的）并且您希望拥有一个全局状态。但它并不能帮助您构建开箱即用的大规模应用程序 - 它只是UI库（因此不支持模块，路由，表单，绑定，http请求，静态类型（打字稿）等）和令我惊讶的是，不支持样式阴影/封装（您必须自己集成，例如，CSS模块）。最后，你不得不经常使用库版本化（使它们始终协同工作真正耗费时间和精力）。
我对 Angular 2/4 + 有很好的体验，我认为，就目前而言，它是这类应用的最佳技术（如果你知道的话） WPF，它非常相似）。它是一个完整的框架，准备开箱即用。您可以将应用程序拆分为独立模块（指定哪些组件对外界可见），每个组件都具有公共API（静态类型，输入/输出）和封装的CSS样式（其他模块之间没有干扰）。 对于全局状态（登录用户，全局配置等），您仍然可以使用库ngrx / store（它实现了Redux模式，并带有额外的好东西，比如＆＃39;效果＆＃39;并且很好地集成到了角度生态系统）。
我试图在Angular中做一些非常疯狂的事情（从后端配置动态生成整个应用程序），一切都运行正常，如预期的那样。
答案 4 :(得分：3)
React，Redux 会让事情变得更轻松，因为它涉及到 您可以创建复杂的应用程序结构良好的数据对然后，您可以通过 React 及其管理完整用户界面 材料 ......有一些原因为什么这是正确的选择
您需要做的是构建数据
答案 5 :(得分：2)
因此，这仅仅是分享我在多家银行多年生产的企业响应应用程序中工作的经验。是的，你明白我的意思了。现在您可以想象如果它与金融科技有关，那么应用程序将是多么庞大（我知道并非总是如此）。我们有庞大的模块（70多个），具有复杂的逻辑，几乎可以处理银行所需的许多工作。模块既隔离又可重复使用。我将仅给出一个模块的示例，以便您可以想象每个模块的大小。
此应用程序是产品，而不是项目，并且可以配置为产品。甚至UI都是可配置的。我一直以全栈开发人员的身份从事此应用程序的工作。因为它已经很老了，所以我们正在使用的状态管理库是助焊剂。使用状态管理，开发速度会稍慢一些，但权衡会更好，因为我们不必担心状态管理。到目前为止，该应用程序已经能够处理巨大的变化和似乎无法实现的事情。在此期间，稳定性也一直是关键要素。
在后端，我们使用Dot Net构建了Restful服务，该服务根据客户端的需求/可行性支持MSSQL Server或Oracle。
答案 6 :(得分：1)
从React和Redux开始，完全理解您的感受。当我们在公司开始使用React时，我们遇到了同样的情况。起初React与其他框架有不同的方法。是的，当然它不是框架，它只是图书馆。你必须开始以React的方式思考，那就是：React组件只是渲染状态（它就像你在你的图形卡上渲染场景一样，你必须准备场景，然后你才能渲染），所有组件都可以做是派遣行动，或者更好地称之为行动创造者。
你需要一些聪明的方法来存储状态，我建议使用Redux。
我们还将TypeScript与React，Redux结合使用。你必须编写比纯JS更多的代码，但是当你处理大型项目时，静态类型控制是无价的。
分离组件逻辑是本机的反应方法......你必须分离逻辑写＆＃34;虚拟组件＆＃34;然后使用connect重用它。或者将值作为道具传递。
我们使用Thunk中间件作为动作创建者它很好，因为连接组件只调用方法而逻辑是动作创建者。您可以访问整个应用程序状态，然后您可以获取某些内容并根据结果发送不同的操作。
我对react / redux的喜欢是如何实现异步调用等。第一个设计组件来映射所有状态
1）就像我没有数据一样 2）数据加载 3）加载完成 4）加载错误
为此，您只需要一个信号量状态和一些render方法。然后是一个动作创建者，它将加载数据并基于描述进度的进度调度动作。
在react / redux应用程序中你有单个数据流，当新开发人员跳入项目时，它很好。
对于UI，我们使用的是Material UI，是的，这个框架有一些问题，但没有什么是你无法处理的。
我们也在使用路由器在应用程序中导航。
一开始我会避免服务器端渲染，因为只需使用客户端渲染和初始状态就可以更轻松地启动它。
当我们为我们开始时，这个模板很有用，其中一切都在一个项目JavaScriptServices
中运行然后关闭了很棒的Abramov教程。
对于非常有用的设计组件Storybook
我们可以写出为什么使用或不使用React很长时间......但是我可以说...对我们来说这是一个很好的选择，有一些乞讨的痛苦，但现在我们有很好的回报。
答案 7 :(得分：0)
我们使用Reactjs作为前端技术启动了一个大型商业应用程序。 我们的团队有30余人，我们的产品中有15多个模块。
我的方法是在该项目中开发一个通用的react项目，该项目仅处理应用程序以及作为单独的npm react库开发的所有其他组件的身份验证，授权和路由。
要开发我使用过https://www.npmjs.com/package/create-react-hook的库
该库使用示例应用程序生成模板，可用于测试我们的库。
以下是项目的结构
-库1（使用create-react-hook开发）
-库2（使用create-react-hook开发）
...
-库n
-通用容器应用程序（使用create react应用程序开发，并通过npm install使用了上述所有库）
此方法的主要优点是，开发人员只能专注于他们的npm软件包，并且可以分别开发和测试相关组件。 部署也变得非常容易，因为我们可以更新测试版本的npm软件包并重建容器应用程序并进行部署，而不会影响应用程序的任何其他部分。
我们已经使用了几个月，并与一个大型团队一起运行该项目，没有任何问题。我认为这也可能对其他人有帮助。