大型业务应用程序的 React 架构 [英] React architecture for a huge business application

问题描述

因此，我们最近在公司中采用了 React 作为前端技术来构建我们庞大的业务 Web 应用程序.说最近，我的意思是我们以前没有任何 React 经验(我们有 AngularJS 的巨大背景)，并且说巨大的应用程序，我的意思是它真的很大而且非常动态，有很多不同的部分和功能.

So we've recently picked up React in our company as the front-end technology to build our huge business web application. By saying recently, I mean we don't have any previous experience with React (we have a huge background of AngularJS), and by saying huge application, I mean it's really huge and very dynamic with lots and lots of different pieces and functionality.

因为我们将拥有很多巨大的组件，它们都扮演着非常重要的角色，并且它们内部具有复杂的逻辑，并且因为我们希望它们易于插拔和可重用，所以我们希望它们尽可能与外部隔离世界和我们应用程序的其他部分，否则由于它们的大小和复杂的功能，几乎不可能开发和维护它们.这就是为什么我们决定不使用 Redux 的原因，至少在开始时，我们只开发单独的组件本身，因为它损害了组件隔离，并且在有这么多复杂的情况下，使整个应用程序数据流逻辑无法理解组件.虽然我相信我们的选择可能是错误的，因为正如我已经提到的，我们没有使用 React 的经验.

Because we will have a lot of huge components that all play a very important role and have complex logic inside them, and because we want them to be easily pluggable and reusable, we want them to be as isolated as possible from the outside world and other parts of our application, because otherwise because of their size and complex functionality it would be pretty much impossible to develop and maintain them. That's the reason why we have decided NOT to use Redux, at least in the beginning, while we are developing just the separate components themselves, because it compromises component isolation and makes the whole application data flow logic impossible to understand when there are so many complex components. Although I believe our choice could be wrong, because as I've already mentioned, we have no experience with React.

正如我已经提到的，应用程序是非常动态的.我的意思是组件实际上是由数据呈现的.我们使用各种与我们的 API 端点交互的配置提供程序类来获取我们应用程序的配置片段，例如导航、页面、各种表单、列表等的配置，然后尝试渲染从该配置中读取的组件.

As I've already mentioned, the application is very dynamic. By that I mean that components are actually rendered by data. We use various configuration provider classes that interacts with our API endpoints to get the pieces of our application's configuration, like configurations of navigation, pages, various forms, lists, etc., and then try to render components that are read from that configuration.

问题是，经过几周努力利用 React 获得动力并找到解决我们问题的正确模式和常见解决方案后，我们一直在团队中讨论，也许 React 不是适合我们的技术，因为它是一个 UI 库，而不是事件框架，它对我们没有多大帮助，只是添加了它的渲染规则，我们有时必须打破这些规则，以实现我们想要的动态和组件独立性.

The problem is, after a couple of weeks struggling to get the momentum with React and discover the right patterns and common solutions to our problems, we've been talking in our crew, that maybe React is not the right technology for us, as it's a UI library, not event a framework, and it doesn't help us a lot, but just adds its rendering rules that we have to break at times to achieve the dynamics and component independence we want.

考虑到组件隔离和数据流管理，我个人听说有一种用于前端开发的语言 Elm 具有非常健壮的数据流架构，每个组件都有自己的模型，与其他组件分离，但我不知道不知道是否值得一试，因为它也可能很快就会落后于我们的大要求.

Considering the component isolation and data flow management, I personally have heard that there is a language for front-end development Elm that has pretty robust data flow architecture where each component has its own model that is separate from others, but I don't know whether it's worth a try, as it may fall behind our big requirements pretty soon too.

我在这里写这个问题的原因是我希望从那些在使用大型前端应用程序方面拥有扎实背景的人那里获得见解.我想知道是否可以用 React 开发这样的应用程序，React 是否适合这种复杂性和动态性，我们是否真的需要 Redux 或其他东西，我们应该遵循什么路径、实践、意识形态.如果您正确理解了我的问题，那么我们正在努力解决的更多是架构方面，而不是技术方面.也许我们只是走在导致越来越多的斗争和复杂性的道路上，而不是走向生产.

The reason I'm writing this question here is that I hope to get an insight from people that have a solid background on working with huge front-end applications. I'd like to know whether it's possible to develop such an application with React, whether React is suitable for such complexity and dynamics, whether we really need Redux or something else, what path, practices, ideologies should we follow. If you understood my question correctly, it's more the architecture side that we are struggling with, than the technological. Maybe we are just walking the path that leads to more and more struggle and complexity but not towards production.

推荐答案

毫无疑问，React/Redux 可以(并且被广泛)用于开发您描述的那种应用程序.您的描述中没有任何东西使您正在构建的东西如此独特，以至于它排除了 React 作为构建它的平台.我们正在积极与正在构建整个前端的大型企业客户合作 - 在 React 中使用 100 + SPA(单页应用程序).这是一个由 100 多名开发人员组成的团队，项目时间为 2-3 年.

There is absolutely no question that React/Redux can (and is widely) used to develop the kind of applications that you describe. Nothing in your description makes what you are building so unique that it excludes React as a platform for building it. We are actively working with a large enterprise customer who is building their entire front end - with 100 + SPA (Single page applications) in React. This is a team of over 100 developers over a 2-3 year project.

我们构建它的方式至关重要 -

The way we structured this has been crucial -

首先，您要选择一个 UI 组件库.下面举几个例子:

First, you want to choose a UI component library. A few examples below :

• MaterialUI - https://github.com/callemall/material-ui
• 反应带 - https://github.com/reactstrap/reactstrap
• React 引导 -https://github.com/react-bootstrap/react-bootstrap
• Khan Academy React 组件https://github.com/Khan/react-components
• https://github.com/elementalui/elemental

我们基本上采用了其中一个并从中构建了一个组件库，因为我们的组件具有非常自定义的样式.

We basically took one of these and built a component library off of them, because our components are very custom styled.

其次，我们创建了一个模块化架构，其中每个模块 (SPA) 都是一个带有主容器组件和 redux 存储的 npm 包.

Second, we created a modular architecture, where each module (SPA) is an npm package with a main container component and redux store.

最后，我们有一个中央服务器包，其中注册了每个模块.服务端包负责鉴权、授权、日志、路由等.

Finally, we have a central server package, where each of the modules is registered. The server package is responsible for authentication, authorization, logging, routing, etc.

这个答案的本质不是就如何构建大型 React 应用程序提供建议，而是让您知道 React 可以(并且正在)用于开发类似于您所描述的应用程序.

The essence of this answer is not to advise on how to structure a large React application, but to let you know that React can be (and is being) used to develop applications similar to what you are describing.

这篇关于大型业务应用程序的 React 架构的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！