程序的可重用性的概念_可重用的Web应用程序策略：在多个位置运行同一应用程序的三种模式

程序的可重用性的概念

Imagine your team just deployed an amazing todo list app. A month later, another team in your company wants to run your todo app within their invoice app.

想象一下，您的团队刚刚部署了一个了不起的待办事项列表应用程序。 一个月后，您公司中的另一个团队希望在其发票应用程序中运行您的待办事项应用程序。

So now you need to run your todo app in two spots:

因此，现在您需要在两个地方运行待办事项应用程序：

1. By itself
   通过它自己
2. Embedded within the invoice app
   嵌入发票应用程序中

What’s the best way to handle that? ?

处理该问题的最佳方法是什么？ ？

To run an app in multiple spots, you have three options:

要在多个位置运行应用程序，您有三个选择：

1. iframe — Embed the todo app in the invoice app via an <iframe>.

   iframe —通过<iframe>将待办事项应用程序嵌入发票应用程序中。

2. Reusable App Component — Share the entire todo app.

   可重复使用的应用程序组件 —共享整个待办事项应用程序。

3. Reusable UI Component — Share only the todo app’s markup.

   可重用的UI组件 -仅共享待办事项应用程序的标记。

Option 2 and 3 are typically shared via npm for client-side apps.

选项2和3通常通过npm共享给客户端应用程序。

In a hurry? Here’s the summary.

匆忙？ 这是摘要。

Let’s explore the merits of each approach.

让我们探讨每种方法的优点。

选项1：iFrame (Option 1: iFrame)

With an iframe, you can compose two apps together by placing the “child” app in an iframe. So in our example, the invoice app would embed the todo app via an iframe. Easy. But not so fast…

使用iframe，您可以将“子”应用放置在iframe中，从而将两个应用组合在一起。 因此，在我们的示例中，发票应用将通过iframe嵌入todo应用。 简单。 但是没有那么快…

什么时候适合iframe？ (When is an iframe a good fit?)

1. Incompatible tech — If the apps you’re composing use incompatible technologies, this is your only option. For example, if one app is built in Ruby and the other in ASP.NET, an iframe allows the two apps to display side-by-side, even though they are actually incompatible and hosted separately.

   不兼容的技术 -如果您编写的应用使用不兼容的技术，则这是您唯一的选择。 例如，如果一个应用程序是用Ruby构建的，而另一个应用程序是用ASP.NET构建的，则iframe允许两个应用程序并排显示，即使它们实际上是不兼容的并且是单独托管的。

2. Small, static dimensions - The app you’re framing in has a static height and width. Dynamically resizing iframes is doable, but adds complexity.

   较小的静态尺寸-您所构建的应用具有固定的高度和宽度。 动态调整iframe的大小是可行的，但会增加复杂性。

3. Common authentication story - An iframed app shouldn’t require separate authentication. Separate authentication can lead to clunky interactions as the framed app may prompt for separate credentials or timeout at a different time than the hosting app.

   常见的身份验证案例 -iframed应用不应要求单独的身份验证。 分开的身份验证可能会导致笨拙的交互，因为框架应用可能会提示与托管应用不同的时间提供单独的凭据或超时。

4. Runs the same way everywhere — With an iframe, the framed app will run the same way in each spot where it’s framed in. If you need significantly different behavior in different contexts, see the other approaches below.

   在任何地方都以相同的方式运行 -使用iframe，带框架的应用程序将在其所在的每个位置以相同的方式运行。如果您在不同的上下文中需要明显不同的行为，请参见下面的其他方法。

5. No common data — With an iframe, the composed applications should avoid displaying the same data. Framing an app can lead to duplicate, wasteful API calls and out-of-sync issues between the framed app and its parent. Data changes in the iframe must be carefully communicated to the parent and vice-versa, or the user will see out-of-sync data.

   无公共数据 -使用iframe，组成的应用程序应避免显示相同的数据。 对应用程序进行构架可能会导致重复的，浪费的API调用以及框架应用程序与其父级应用程序之间的不同步问题。 必须将iframe中的数据更改仔细传达给父级，反之亦然，否则用户将看到不同步的数据。

6. Few inter-app interactions — There should be very few interactions between the hosting app and the iframed app. Sure, you can use window.postMessage to pass messages between the iframe and the hosting app, but this approach should be used sparingly since it’s brittle.

   应用程序间交互很少 -托管应用程序与iframed应用程序之间的交互应该很少。 当然，您可以使用window.postMessage在iframe和托管应用之间传递消息，但是由于这种方法比较脆弱，因此应谨慎使用。

7. A single team supports both apps — With iframes, the same team should ideally own and maintain both the parent app and the framed app. If not, you must accept an ongoing coordination relationship between the teams that support the applications to assure they remain compatible. Separate teams create an ongoing risk and maintenance burden to maintain a successful and stable integration.

   一个团队支持两个应用程序 -使用iframe，理想情况下，同一团队应该拥有并维护父应用程序和框架应用程序。 否则，您必须接受支持应用程序的团队之间的持续协调关系，以确保它们保持兼容。 单独的团队会产生持续的风险和维护负担，以维持成功且稳定的集成。

8. Only need to do this once — Due to the point above, you should only iframe an app once to avoid creating a significant maintenance burden. The more times an app is framed, the more places you risk breaking when you make changes.

   只需执行一次 -由于以上几点，您仅应对应用程序进行一次iframe部署，以避免造成巨大的维护负担。 构图应用的次数越多，进行更改时面临的风险就越大。

9. Comfortable with deployment risks — With an iframe, you must accept the risk that a production deploy of the framed application may impact the parent app at any time. This is another reason having the same team support both the parent and framed app is useful.

   轻松应对部署风险 —使用iframe，您必须承担以下风险：框架应用程序的生产部署可能随时影响父应用程序。 这是另一个具有相同团队支持父应用程序和框架应用程序的理由。

选项2：共享应用程序组件 (Option 2: Share App Component)

Node’s package manager, npm, has become the defacto way to share JavaScript. With this approach, you create an npm package and place the completed application inside. And it need not be public — you can create a private npm package on npm too.

Node的程序包管理器npm已成为共享JavaScript的实际方法。 使用这种方法，您可以创建一个npm软件包并将完整的应用程序放入其中。 而且不必公开-您也可以在npm上创建一个私有npm软件包。

The process for creating a reusable component library is beyond the scope of this post. I explore how to build your own reusable component library in “Building Reusable React Components”.

创建可重用组件库的过程超出了本文的范围。 我将在“ 构建可重用的React组件 ”中探索如何构建自己的可重用组件库。

Since you’re sharing the entire app, it may include API calls, authentication concerns, and data flow concerns like Flux/Redux, etc. This is a highly opinionated piece of code.

由于您要共享整个应用程序，因此它可能包括API调用，身份验证问题和数据流问题(例如Flux / Redux等)。这是一个颇有见地的代码。

可重用的应用程序组件什么时候适合？ (When is the reusable app component approach a good fit?)

1. Compatible tech — Since you’re sharing a reusable component, the parent app needs to be compatible. For instance, if you’re sharing a React component, the parent app should ideally be written in React too.

   兼容的技术-由于您共享一个可重用的组件，因此父应用程序需要兼容。 例如，如果您要共享一个React组件，那么父应用最好也应该使用React编写。

2. Dynamic size — This approach is useful if your app’s width/height are dynamic so it doesn’t fit well in a statically sized frame.

   动态尺寸 -如果您的应用的宽度/高度是动态的，因此它不适用于静态尺寸的框架，则此方法很有用。

3. Common authentication story — The two applications should ideally utilize the same authentication. Separate authentication can lead to clunky interactions as each app may prompt for separate credentials or timeout at a different time.

   通用身份验证案例 -理想情况下，两个应用程序应使用相同的身份验证。 单独的身份验证可能导致笨拙的交互，因为每个应用程序可能会提示在不同时间输入单独的凭据或超时。

4. You want the app to run the same way everywhere — Since API, authentication, and state management are built in, the app will operate the same way everywhere.

   您希望该应用程序在任何地方都以相同的方式运行 -由于内置了API，身份验证和状态管理，因此该应用程序将在所有地方以相同的方式运行。

5. No common data — The two applications mostly work with separate data. Displaying apps side-by-side can lead to duplicate, wasteful API calls as each app makes requests for the same data. It can also lead to out-of-sync issues between the two apps. Data changes in one must be carefully communicated to the other, or the user will see out-of-sync data between the two apps.

   没有通用数据 -这两个应用程序大多使用单独的数据。 并排显示应用程序可能会导致重复的，浪费的API调用，因为每个应用程序都请求相同的数据。 它还可能导致两个应用程序之间出现不同步问题。 一个应用程序中的数据更改必须仔细传达给另一个应用程序，否则用户将看到两个应用程序之间的数据不同步。

6. Few inter-app interactions — There should be few interactions between the two apps. Sure, you can use window.postMessage to pass messages between them, but this approach should be used sparingly since it’s brittle.

   应用程序之间的交互很少 -两个应用程序之间的交互应该很少。 当然，您可以使用window.postMessage在它们之间传递消息，但是由于这种方法比较脆弱，因此应谨慎使用。

7. A single team supports both apps — With this approach, ideally the same team owns and maintains both apps. If not, you must be willing to accept an ongoing coordination relationship between the teams that support the two applications to assure they remain compatible. Separate teams create an ongoing risk and maintenance burden to maintain a successful and stable integration.

   单个团队支持两个应用程序 -使用这种方法，理想情况下，同一团队拥有和维护两个应用程序。 如果没有，您必须愿意接受支持这两个应用程序的团队之间持续的协调关系，以确保它们保持兼容。 单独的团队会产生持续的风险和维护负担，以维持成功且稳定的集成。

选项3：共享UI组件 (Option 3: Share UI Component)

This option is similar to option #2 above, except you share only the markup. With this approach, you omit authentication, API calls, and state management so that the component is basically just reusable HTML.

该选项类似于上面的选项2，不同之处在于您仅共享标记 。 使用这种方法，您可以省略身份验证，API调用和状态管理，因此该组件基本上只是可​​重用HTML 。

Popular examples of simple components like this include Material-UI and React Bootstrap. Of course, a reusable app component has more moving parts, but it operates on the same idea.

诸如此类的简单组件的流行示例包括Material-UI和React Bootstrap 。 当然，可重用的应用程序组件具有更多可移动的部分，但它的操作原理相同。

Before we discuss the merits of this approach, let me address a common question: “Should my reusable components embed API calls and auth?”

在讨论这种方法的优点之前，让我解决一个常见的问题：“我的可重用组件是否应嵌入API调用和身份验证？”

My take? Avoid embedding API, auth, and state management concerns in reusable components.

我拿 避免将API，身份验证和状态管理问题嵌入可重用组件中。

Here’s why:

原因如下：

1. It limits reuse by tying the front-end to a specific API, auth, state management story.
   它通过将前端绑定到特定的API，身份验证，状态管理故事来限制重用。
2. Often, separate developers/teams manage the UI and API. Embedding API calls in a reusable component couples the UI team and the API team together. If one side changes, it impacts the other, which creates an ongoing coordination overhead and maintenance burden.
   通常，由单独的开发人员/团队来管理UI和API。 将API调用嵌入可重用的组件中将UI团队和API团队耦合在一起。 如果一方发生变化，则会影响另一方，从而产生持续的协调开销和维护负担。

But yes, this does mean each time someone uses your reusable component, they have to wire up the API calls and pass them in on props.

但是，是的，这确实意味着每次有人使用您的可重用组件时，他们都必须连接API调用并将其传递给prop。

可重用的UI组件什么时候适合？ (When is the reusable UI component approach a good fit?)

1. Compatible tech — Since you’re sharing a reusable component, the parent app needs to be compatible. For instance, if you’re sharing a React component, the parent app should be written in React too.

   兼容的技术-由于您共享一个可重用的组件，因此父应用程序需要兼容。 例如，如果您共享一个React组件，那么父应用也应该用React编写。

2. Dynamic size — This approach is useful if your app’s width/height are dynamic so it doesn’t fit well in a statically sized frame.

   动态尺寸 -如果您的应用的宽度/高度是动态的，因此不适用于静态尺寸的框架，则此方法很有用。

3. Different authentication stories — Since this approach is basically just reusable HTML, the apps you want to compose can have different auth stories, or the auth story can differ in each place the component is used.

   不同的身份验证故事 -由于此方法基本上只是可​​重用HTML，因此要编写的应用程序可以具有不同的身份验证故事，或者在使用组件的每个位置处，身份验证故事可以有所不同。

4. Different behaviors in each use case — With this approach, you can reuse a front-end, but call different APIs in each use case. Each copy of the front-end can operate completely differently. You can set different props and hit different APIs in each use case to tailor behavior as needed.

   每个用例中的行为不同 —使用这种方法，您可以重用前端，但是在每个用例中调用不同的API。 前端的每个副本可以完全不同地操作。 您可以在每个用例中设置不同的道具并使用不同的API，以根据需要调整行为。

5. Common data — With this approach, the UI you’re composing can utilize and display the parent app’s data. It’s a single, cohesive app. This avoids duplicate API calls and out-of-sync issues, saves bandwidth, and improves performance.

   通用数据 -通过这种方法，您所编写的UI可以利用并显示父应用程序的数据。 这是一个单一的，具有凝聚力的应用程序。 这样可以避免重复的API调用和不同步的问题，节省带宽并提高性能。

6. Many cross-app interactions — If there are significant interactions and shared data between the applications, this approach assures that the two applications feel like a single cohesive experience…because this approach creates a single, cohesive app.

   许多跨应用程序交互 —如果应用程序之间存在重要的交互作用和共享数据，则此方法可确保两个应用程序感觉像是一个单一的内聚体验……因为此方法创建了一个单一的内聚性应用程序 。

7. Discoverability is desirable — You want to publicize the existence of a rich, reusable front-end as a component. You can place this component in your reusable component library and document the props it accepts so that others can easily find and reuse it in different contexts.

   可发现性是可取的 -您想宣传丰富，可重用的前端作为组件的存在。 您可以将该组件放置在可重用的组件库中，并记录其接受的道具，以便其他人可以轻松地在不同的上下文中查找和重用它。

8. Multiple use cases— You plan to deploy this front end in many places. This approach is more flexible than the other approaches since you’re just sharing a highly configurable front-end.

   多个用例 -您计划在许多地方部署此前端。 这种方法比其他方法更灵活，因为您只是共享一个高度可配置的前端。

9. Separate UI and API teams — If you have a separate UI team, tying the UI to the API via the other approaches is unattractive due to the aformentioned coordination overhead. With this approach, you control when to update the npm package. You can deploy a new version of the reusable front end when desired, on a per app basis.

   独立的UI和API团队 -如果您拥有独立的UI团队，则由于上述协调开销，通过其他方法将UI与API绑定是没有吸引力的。 使用这种方法，您可以控制何时更新npm软件包。 您可以根据需要在每个应用程序的基础上部署新版本的可重用前端。

摘要 (Summary)

As usual, context is king. In most cases, I recommend approach #3, but each has valid use cases. Have another way to handle this? Please chime in via the comments.

与往常一样，上下文为王。 在大多数情况下，我建议使用方法3，但每种方法都有有效的用例。 还有另一种方法来解决这个问题？ 请通过评论加入。

Cory House is the author of multiple courses on JavaScript, React, clean code, .NET, and more on Pluralsight. He is principal consultant at reactjsconsulting.com, a Software Architect at VinSolutions, a Microsoft MVP, and trains software developers internationally on software practices like front-end development and clean coding. Cory tweets about JavaScript and front-end development on Twitter as @housecor.

Cory House是JavaScript，React，干净代码，.NET等课程的多本课程的作者，并且还提供了有关Pluralsight的更多课程 。 他是reactjsconsulting.com的首席顾问， VinSolutions的软件架构师，Microsoft MVP，并且在软件开发方面对国际软件开发人员进行了培训，例如前端开发和简洁编码。 Cory在Twitter上以@housecor表示关于JavaScript和前端开发的推文 。

翻译自: https://www.freecodecamp.org/news/reusable-web-application-strategies-d51517ea68c8/

程序的可重用性的概念