Sal*_*van 25 architecture frontend dynamic reactjs redux
因此,我们最近在公司中选择了React作为构建我们庞大的业务Web应用程序的前端技术.最近说,我的意思是我们之前没有React的经验(我们有很多AngularJS的背景),并且通过说大量应用程序,我的意思是它非常庞大且非常动态,有很多不同的部件和功能.
因为我们将拥有许多巨大的组件,它们都起着非常重要的作用,并且在它们内部具有复杂的逻辑,并且因为我们希望它们易于插拔和重复使用,所以我们希望它们尽可能地与外部世界隔离.我们应用程序的一部分,因为否则由于它们的大小和复杂的功能,开发和维护它们几乎是不可能的.这就是我们决定不使用Redux的原因,至少在开始时,我们只是自己开发单独的组件,因为它会破坏组件隔离并使得当有如此多的复杂时,整个应用程序数据流逻辑无法理解组件.虽然我认为我们的选择可能是错误的,因为正如我已经提到的,我们没有React的经验.
正如我已经提到的,该应用程序非常动态.我的意思是组件实际上是由数据呈现的.我们使用与我们的API端点交互的各种配置提供程序类来获取应用程序配置的各个部分,例如导航,页面,各种表单,列表等的配置,然后尝试呈现从该配置中读取的组件.
问题是,经过几周努力获得React的动力并发现正确的模式和我们问题的常见解决方案,我们一直在谈论我们的工作人员,也许React对我们来说不是正确的技术,因为它是一个UI库,而不是一个框架事件,它对我们没什么帮助,但只是添加了我们必须打破的渲染规则,以实现我们想要的动态和组件独立性.
考虑到组件隔离和数据流管理,我个人听说有一种语言用于前端开发Elm,它具有非常强大的数据流架构,其中每个组件都有自己独立的模型,但我不知道是否值得一试,因为它很快就会落后于我们的大需求.
我在这里写这个问题的原因是我希望能够从那些拥有大量前端应用程序背景的人那里获得洞察力.我想知道是否可以使用React开发这样的应用程序,无论React是否适合这种复杂性和动态,我们是否真的需要Redux或其他东西,我们应该遵循什么样的路径,实践和意识形态.如果你正确地理解了我的问题,那么我们正在努力解决的架构方面比技术方面更多.也许我们正在走的路上走向越来越多的斗争和复杂性,而不是走向生产.
fle*_*com 14
毫无疑问,React/Redux可以(并且被广泛地)用于开发您描述的那种应用程序.您的描述中没有任何内容使您构建的内容如此独特,以至于它将React排除在构建它的平台之外.我们正积极与正在构建其整个前端的大型企业客户合作 - 在React中使用100 + SPA(单页应用程序).这是一个由超过100名开发人员组成的团队.
我们构建这个的方式至关重要 -
首先,您要选择UI组件库.以下几个例子:
我们基本上采用了其中之一并构建了一个组件库,因为我们的组件是非常自定义的样式.
其次,我们创建了一个模块化架构,其中每个模块(SPA)都是一个带有主容器组件和redux存储的npm包.
最后,我们有一个中央服务器包,其中每个模块都已注册.服务器包负责身份验证,授权,日志记录,路由等.
这个答案的本质不是建议如何构建一个大的React应用程序,而是让你知道React可以(并且正在)用于开发类似于你所描述的应用程序.
我现在也是类似的情况。我有大型桌面应用程序（ERP、LOB - WinForms、WPF）的背景 - 1000 多个模块，非常动态（超过 70% 的 UI 是由输入数据/配置生成的），添加新功能只是为了扩展一些配置（不涉及源代码）。
我正在深入研究当前的 Web 技术，而且我越来越相信 React 不适合这样做。React 在您（和其他团队成员）“手动”（不是动态生成）开发每个页面/组件并且想要拥有一个全局状态的中小型应用程序中确实大放异彩。但它并不能帮助您构建开箱即用的大型应用程序 - 它只是 UI 库（因此不支持模块、路由、表单、绑定、http 请求、静态类型（打字稿）等）和我的令人惊讶的是，不支持样式阴影/封装（例如，您必须自己集成 CSS 模块）。最后，您必须不断为库版本控制而烦恼（让它们始终协同工作确实非常耗时耗力）。
我对Angular 2/4+有丰富的经验，我认为，就目前而言，它是此类应用程序的最佳技术（如果您了解 WPF，它非常相似）。它是一个完整的框架，可以开箱即用。您可以将您的应用程序拆分为独立的模块（指定哪些组件对外界可见），每个组件都有公共 api（静态类型、输入/输出）和封装的 css 样式（其他组件之间没有干扰）。对于全局状态（登录用户、全局配置等），您仍然可以使用库 ngrx/store（它实现了 Redux 模式并带有额外的好东西，比如“效果”，并且非常好地集成到 Angular 生态系统中）。
我尝试在 Angular 中做一些非常疯狂的事情（从后端配置动态生成整个应用程序），一切都按预期完美运行。
当您开始使用 React 和 Redux 时，完全理解您的感受。当我们在公司开始使用 React 时，我们处于同样的情况。起初，React 与其他框架有不同的方法。是的，当然它不是框架，它只是库。你必须开始用 React 的方式思考，那就是：React 组件只是渲染状态（就像你首先在显卡上渲染场景，你必须准备场景然后你才能渲染），组件所能做的就是调度动作，或者更好地调用动作创建者。
你需要一些聪明的方式来存储状态，我建议使用 Redux。
我们还将 TypeScript 与 React、Redux 结合使用。与纯 JS 相比，您必须编写更多代码，但是当您处理大型项目时，静态类型控制是无价的。
分离组件逻辑是 react 的原生方法……您必须分离逻辑编写“虚拟组件”，然后将其与连接重用。或者将值作为道具传递。
我们使用 Thunk 中间件作为动作创建者，这很好，因为连接的组件将只调用方法，逻辑在动作创建者中。您可以访问应用程序的整个状态，然后您可以获取某些内容并根据结果您可以调度不同的操作。
我喜欢 react/redux 是如何实现异步调用等。第一个设计组件来映射所有状态
1) 就像我没有数据 2) 数据加载 3) 加载完成 4) 加载错误
为此，您只需要状态中的一个信号量和渲染方法中的一些检查。然后是一个动作创建者，它将加载数据并基于描述进度的进度分派动作。
在 react/redux 应用程序中，你有一个单一的数据流也很酷，当新开发者进入项目时，这很好。
对于 UI，我们使用的是 Material UI，是的，这个框架有一些问题，但没有什么是你无法处理的。
我们也使用路由器在应用程序中导航。
一开始我会避免服务器端渲染，因为从客户端渲染和初始状态开始对你来说会容易得多。
当我们开始时，这个模板很有用，它可以在一个项目中运行JavaScriptServices
然后当然是伟大的阿布拉莫夫教程。
对于设计组件非常有用的Storybook
我们可以写下为什么长时间使用或不使用 React ......但是我可以说......对我们来说这是一个不错的选择，虽然在乞讨中有些痛苦，但现在我们有了很好的回报。
React 和 Redux将使事情变得更容易，因为当涉及到复杂的应用程序时，您可以创建结构良好的数据对象。那么你可以通过React和它的 材料来管理完整的 UI ......有一些原因为什么这是正确的选择
您必须做的事情是构建您的数据
小智 5
开始在React中编写更复杂的应用程序确实很困难，我确切地知道它的感觉！
如您所说，React是一个UI库，而不是一个事件框架。这就是为什么您通常需要一个库来处理事件，例如Redux。您明确声明您决定不使用Redux（甚至不使用大写字母:)）。如果我是您，我会退后一步，然后重新考虑这个决定。您说不使用Redux的原因是，使用Redux时无法保持组件易于插拔和可重用。我认为那是不正确的。Redux与您的React组件完全脱钩。Redux仅处理接收事件和管理状态。从React组件的角度来看，它只是接收props中的数据并通过调用常规函数来发送事件。仍然可以进行单元测试，重用等。
我建议您再考虑一下Redux。如果您还有其他问题，很高兴为您提供帮助！
您在问题中提到了问题-反应是视图库，而不是应用程序框架。真正的问题是React + Redux（或其他状态管理系统）是否适合大型LOB应用程序。
我将分享我们团队在该领域的经验中的一些见解。数十年来，使用MVC / MVP / MVVM设计模式开发了大型LOB应用程序。这些是交付软件的经过实践检验的真实模式。将其与依赖项注入结合使用，您将获得一个模块化，可测试，可维护的应用程序。AngularJS（2.0+）基于这些原则，并深深地利用了它们。因此，我们将AngularJS用于我们所有的企业业务应用程序。
另一方面，React是轻量级的Sprite视图渲染，对于较小的应用程序和面向客户的组件（例如，进行动态调查或简单的仪表板）来说非常棒。我们经常在这里转向React和VueJS，因为完整的AngularJS堆栈实在是太过强大了。