所以我们最近在公司里选择了React作为前端技术来构建我们庞大的商业Web应用程序。我说最近，是指我们以前没有任何使用React的经验（我们有AngularJS的巨大背景），我说巨大的应用程序，是指它真的很大，非常动态，有很多很多不同的部分和功能。
因为我们将有许多巨大的组件，它们都扮演着非常重要的角色，并且它们内部具有复杂的逻辑，因为我们希望它们易于插入和重用，所以我们希望它们尽可能地与外部世界和应用程序的其他部分隔离，因为否则的话，由于它们的规模和复杂的功能，几乎不可能开发和维护它们。这就是为什么我们决定不使用Redux的原因，至少在开始的时候是这样，因为我们只开发独立的组件本身，因为当有这么多复杂的组件时，它会损害组件的隔离，并使整个应用程序的数据流逻辑无法理解。尽管我相信我们的选择可能是错误的，因为正如我已经提到的，我们对React没有任何经验。
正如我已经提到的，应用程序是非常动态的。我的意思是，组件实际上是由数据呈现的。我们使用各种配置提供者类与我们的API端点交互，以获得应用程序的配置片段，如导航、页面、各种表单、列表等的配置，然后尝试呈现从该配置读取的组件。
问题是，经过几周的努力，我们发现了正确的模式和常见的解决方案来解决我们的问题，我们已经在我们的团队中讨论，也许React不是适合我们的技术，因为它是一个UI库，而不是一个框架，它没有给我们带来很多帮助。但只是添加了渲染规则，我们有时必须打破这些规则以实现我们想要的动态性和组件独立性。
考虑到组件隔离和数据流管理，我个人听说有一种用于前端开发的语言Elm，它具有非常健壮的数据流架构，其中每个组件都有自己的独立于其他组件的模型，但我不知道是否值得一试，因为它可能很快就落后于我们的大需求。
我在这里写这个问题的原因是，我希望从那些在处理大型前端应用程序方面有扎实背景的人那里得到一些见解，我想知道是否有可能用React开发这样的应用程序，React是否适合这样的复杂性和动态性，我们是否真的需要Redux或其他东西，什么路径、实践我们应该遵循的意识形态。如果你理解我的问题是正确的，我们正在努力的更多的是架构方面，而不是技术。也许我们只是走在导致越来越多的斗争和复杂性的道路上，而不是生产。
9条答案
按热度按时间vlurs2pr1#
毫无疑问，React/Redux可以（并且被广泛地）用于开发您所描述的应用程序类型。您的描述中没有任何内容使您正在构建的应用程序如此独特，以至于无法将React作为构建应用程序的平台。我们正在积极地与一家大型企业客户合作，该客户正在构建其整个前端-使用100 + SPA（单页应用程序）在React。这是一个团队超过100名开发人员超过2 - 3年的项目。
我们的组织方式至关重要-
首先，你要选择一个UI组件库。下面举几个例子：
我们基本上是取其中一个，并根据它们构建了一个组件库，因为我们的组件是非常自定义的样式。
其次，我们创建了一个模块化架构，其中每个模块（SPA）都是一个npm包，带有一个主容器组件和redux存储。
最后，我们有一个中央服务器包，每个模块都在这里注册，服务器包负责身份验证、授权、日志记录、路由等。
这个答案的本质不是建议如何构建大型React应用程序，而是让您知道React可以（并且正在）用于开发与您所描述的类似的应用程序。
njthzxwz2#
我现在也有类似的情况。我有大型桌面应用程序（ERP，LOB - WinForms，WPF）的背景- 1000多个模块，非常动态（超过70%的UI是由输入数据/配置生成的），添加新功能只是扩展一些配置（不接触源代码）。
我正在深入研究当前的Web技术，我越来越确信React并不适合这种技术。（和其他团队成员）“手动”开发每个页面/组件（不是动态生成的），并且您希望有一个全局状态。但是它不能帮助您构建开箱即用的大规模应用程序-它只是UI库（因此不支持模块、路由、表单、绑定、http请求、静态类型（typescript）等），令我惊讶的是，不支持样式Map/封装（例如，您必须自己集成CSS模块）。最后，您不得不不断地为库版本控制而烦恼（使它们始终一起工作确实是费时费力的）。
我对Angular 2/4+有很好的体验，我认为，就目前而言，它是此类应用的最佳技术（如果你知道WPF，它是非常相似的）。它是一个完整的框架，它是准备扩展的盒子。你可以把你的应用程序分成独立的模块（指定哪些组件对外界可见），每个组件都有公共api（静态类型、输入/输出）和封装的css样式（其他人之间没有干涉）。对于全局状态（登录用户、全局配置等），您仍然可以使用库ngrx/store（它实现了Redux模式，并附带了额外的好东西，如“效果”，并非常好地集成到Angular生态系统中）。
我试着在Angular中做一些非常疯狂的事情（从后端配置动态生成整个应用程序），一切都像预期的那样完美。
iyfjxgzm3#
你在问题中抓住了这个问题- react是一个视图库，而不是一个应用框架。真实的的问题是React+Redux（或其他状态管理系统）是否适合大型LOB应用。
我将分享我们团队在这个领域的一些经验。几十年来，大型LOB应用程序一直使用MVC/MVP/MVVM设计模式来开发。这些都是经过实践检验的真正的软件交付模式。将其与依赖注入结合起来，您将拥有一个模块化的、可测试的可维护应用程序. AngularJS（2.0+）是建立在这些原则的基础上，并深入利用它们。因此，我们将AngularJS用于我们所有的企业业务线应用。
另一方面，React是一个轻量级的、灵活的视图渲染器，对于较小的应用程序和面向客户端的部分（例如，进行动态调查或简单的 Jmeter 板）来说非常棒。我们经常在这里求助于React和VueJS，因为完整的AngularJS堆栈太过繁琐。
zwghvu4y4#
开始在React中编写更复杂的应用程序真的很难，我很清楚这是什么感觉！
正如你所说的，React是一个UI库，而不是一个事件框架。这就是为什么你通常需要一个库来处理事件，比如Redux。你清楚地表明你决定不使用Redux（你甚至用大写字母表示not：）。如果我是你，我会后退一步重新考虑这个决定。你说不使用Redux的原因是在使用Redux时你不能保持你的组件易于插入和重用。我认为这不是真的。Redux完全与你的React组件分离。Redux只处理接收事件和管理状态。从React组件的Angular 来看，它只是接收道具中的数据，并通过调用常规函数发送事件。仍然有可能进行单元测试、重用等等。
我建议你考虑到这一点再看看Redux。如果你有更多的问题，我很乐意帮助你！
h79rfbju5#
React，Redux将使事情变得更容易，因为当涉及到复杂的应用程序时，您可以创建结构良好的数据对象。然后您可以通过React及其材料管理完整的UI ......这是正确选择的原因有几个
1.状态管理、
1.树形结构数据处理：
1.减少代码、
1.您将知道在哪里进行了更改（操作、还原器）
1.您的组件将只处理UI的事情
你要做的就是构建你的数据
flseospp6#
当你开始使用React和Redux的时候，完全理解你的感受。当我们在公司开始使用React的时候，我们也处于同样的情况。最初React的方法和其他框架不同。是的，当然它不是框架，它只是库。你必须开始用React的方式思考，那就是：React组件只是渲染状态（这就像你在显卡上渲染场景一样，首先你必须准备场景，然后你才能渲染），组件所能做的就是调度动作，或者更好地调用动作创建者。
你需要一些聪明的方法来存储状态，我建议使用Redux。
我们还使用TypeScript和React、Redux组合。您必须编写比纯JS更多的代码，但是当您处理大型项目时，静态类型控制是无价的。
分离组件逻辑是React的原生方法...你必须编写“虚拟组件”来分离逻辑，然后通过连接或传递值作为道具来重用它。
我们使用Thunk中间件作为动作创建器，这很好，因为连接的组件将调用动作创建器中的方法和逻辑。您可以访问应用程序的整个状态，然后您可以获取一些内容，并根据结果调度不同的动作。
我喜欢react/ redux的是如何实现异步调用等。首先设计组件来Map所有状态
1)像我没有数据2）数据加载3）加载完成4）加载错误
为此，你只需要在状态中有一个信号量，在呈现方法中有一些检查，然后有一个动作创建器，它将加载数据并根据进度调度描述进度的动作。
在react/redux应用程序中，你有一个单一的数据流，这也很酷，当新的开发人员跳到项目中时，这是很好的。
对于UI，我们使用的是Material UI，是的，这个框架有一些问题，但没有什么是你不能处理的。
我们也使用路由器在应用程序中导航。
一开始我将避免服务器端渲染，因为它将更容易为您开始只与客户端渲染和初始状态。
当我们开始为我们是有用的这个模板，其中一切都在一个项目JavaScriptServices
然后关闭课程伟大的Abramov教程。
对于设计组件非常有用Storybook
我们可以写为什么使用或不React很长一段时间...但我能说的是...对我们来说这是一个很好的选择，有一些痛苦的乞讨，但现在我们有很好的回报。
wfsdck307#
我们使用Reactjs作为前端技术开始了一个大规模的商业应用程序。我们的团队有30多人，我们的产品有15个模块。
我的方法是项目是开发一个通用的React项目，只处理认证，授权和路由的应用程序和所有其他组件开发作为单独的npmReact库。
为了开发库，我使用了https://www.npmjs.com/package/create-react-hook
此库生成了一个示例应用程序模板，可用于测试我们的库。
项目结构如下
--库1（使用create-react-hook开发）
--库2（使用create-react-hook开发）
...
--库n
--通用容器应用程序（使用create react应用程序开发，并已使用npm安装使用上述所有库）
这种方法的主要优点是开发人员可以只关注他们的npm包，他们可以单独开发和测试相关的组件。部署也变得非常容易，因为我们可以只更新测试版本的npm包，重建容器应用程序，并在不影响应用程序任何其他部分的情况下进行部署。
我们正在使用这个几个月，并运行一个大型团队的项目没有任何问题。我认为这可能对其他任何人也有帮助。
fjaof16o8#
这只是分享我在企业React应用程序上的工作经验，该应用程序已在多家银行投入生产多年。是的，你没听错。现在你可以想象，如果这个应用与金融科技有关，它会有多大的规模（我知道情况并非总是如此）。我们有巨大的模块（70+），逻辑复杂，几乎可以处理银行所需的大量工作。模块是独立的，可重用。我将给予一个仅包含一个模块的示例，以便您可以想象每个模块的大小。
1.批量卡生成
1.批量卡导出
1.批量卡请求
1.卡操作
1.卡运营批准
1.卡片打印
1.新卡申请
1.引脚生成
1.针印
这个应用程序是一个产品，而不是一个项目，作为一个产品，它是可配置的。甚至UI也是可配置的。我一直在这个应用程序上工作，作为一个完整的堆栈开发人员。因为它是相当旧的状态管理库，我们正在使用的是通量。有了状态管理，开发速度有点慢，但我们不用担心状态管理，这样的权衡比较好。到目前为止，应用程序已经能够处理巨大的变化和似乎无法实现的事情。稳定性也是整个这一时期的关键因素。
在后端，我们使用Dot Net构建Restful服务，它支持MSSQL Server或Oracle，具体取决于客户的需求/可行性。
9rygscc19#
在完成了无数个react.js项目之后，我在博客中总结了一个面向领域的实用架构。
这是我多次应用的绝对最佳实践，享受：
http://denislutz.com/domain-architecture-for-react