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

问题描述

所以我们最近在我们公司拿起了 React 作为前端技术来构建我们巨大的商业网络应用程序。最近，我的意思是我们没有任何以前的经验 React （我们有一个巨大的背景 AngularJS 1 ），通过说大量的应用程序，我的意思是它真的很大，非常动态，有很多不同的部分和功能。

因为我们会有很多巨大的这些组件在其中起着非常重要的作用并具有复杂的逻辑，并且因为我们希望它们容易插拔和可重用，所以我们希望它们尽可能地与外部世界和我们的应用程序的其他部分隔离，因为否则是因为它们的大小和复杂的功能，几乎不可能开发和维护它们。这就是为什么我们决定不使用 Redux 的原因，至少在一开始，我们正在开发单独的组件本身，因为它会损害组件隔离，并使整体当有这么多复杂的组件时，应用数据流逻辑不可能理解。虽然我相信我们的选择可能是错误的，因为我已经提到过，我们没有经验， React 。

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

问题是，经过几周的努力，以 React 获得势头，并发现正确的模式和共同点解决我们的问题，我们一直在讨论我们的团队，也许 React 对我们来说不是正确的技术，因为它是一个UI库，而不是一个框架，它不会帮助我们很多，但只是添加了它的渲染规则，我们必须打破时间来实现我们想要的动态和组件独立性。

考虑到组件隔离和数据流管理，我个人已经听说有一种前端开发的语言 Elm 具有非常强大的数据流架构，每个c omponent有自己的模式，与其他人分开，但我不知道是否值得一试，因为它可能会很快落在我们的大要求之后。

我在这里写这个问题的原因在于，我希望能够深入了解在使用巨大的前端应用程序方面有扎实背景的人。我想知道是否可以使用 React 开发这样一个应用程序，无论 React 是否适合这种复杂性和动态，我们是否真的需要 Redux 或其他东西，我们应该遵循什么路径，做法，意识形态。如果您正确理解我的问题，我们正在努力的架构方面比技术更多。也许我们正在走路径，导致越来越多的斗争和复杂性，但不是生产。

解决方案

绝对没有React / Redux可以（并被广泛地）用于开发您所描述的那种应用程序的问题。您的描述中没有任何内容使您正在构建的内容非常独特，它将反应排除在构建平台之外。我们正在积极与正在构建其整个前端的大型企业客户合作 - 在React中使用100 + SPA（单页应用程序）。这是一个2-3年的项目的100多名开发人员的团队。

我们结构化的方式至关重要 -

首先，您要选择一个UI组件库。以下几个例子：

• MaterialUI - https://github.com/callemall/material-ui


• React Strap - https://github.com/reactstrap/reactstrap


• React Bootstrap - https://github.com/react-bootstrap/react-bootstrap


• 汗学院反应组件 https://github.com/Khan/react-components


• https://github.com/elementalui/elemental

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

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

最后，我们有一个中央服务器包，其中每个模块都已注册。服务器包负责认证，授权，日志记录，路由等。

这个答案的本质不是建议如何构建一个大的React应用程序，而是让您知道React可以（并且正在被）用于开发类似于您所描述的应用程序。

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 1), and by saying huge application, I mean it's really huge and very dynamic with lots and lots of different pieces and functionality.

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.

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.

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.

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.

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.

解决方案

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 -

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

• MaterialUI - https://github.com/callemall/material-ui
• React Strap - https://github.com/reactstrap/reactstrap
• React Bootstrap -https://github.com/react-bootstrap/react-bootstrap
• Khan Academy React Components 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.

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.

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.

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