react 组件名称重复_设计可重复使用的React组件

react 组件名称重复

乐高积木可以教给我们关于React应用中的重用 (What Legos Can Teach Us About Reuse in React Apps)

React is a component library. So React makes it easy to break your UI down into composable pieces. The question is, how granular should the pieces be?

React是一个组件库。 因此，React可以轻松地将用户界面分解为可组合的部分。 问题是， 碎片应该有多细 ？

Let’s consider a specific example that I explored in a previous post.

让我们考虑一下我在上一篇文章中探讨的具体示例。

Imagine your team just deployed a ToDo app, built in React. A month later, another team in your company wants to run your ToDo app within their invoice app, also built in React.

想象您的团队刚刚部署了一个内置于React的ToDo应用。 一个月后，您公司中的另一个团队希望在其发票应用程序(也是内置于React中)中运行您的ToDo应用程序。

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

因此，现在您需要在两个地方运行ToDo应用：

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

What’s the best way to handle that? ?

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

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

要在多个位置运行React应用，您可以使用以下三种选择：

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

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

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

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

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

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

Let’s discuss the merits of each approach.

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

方法1：iFrame (Approach 1: iFrame)

The easiest and most obvious approach is to use an iframe to frame the ToDo app into the invoice app.

最简单，最明显的方法是使用iframe将ToDo应用框架化为发票应用。

But leads to multiple issues:

但是会导致多个问题：

1. If the two apps display the same data, you risk them getting out of sync.
   如果两个应用程序显示相同的数据，则可能会导致它们不同步。
2. If the two apps use the same data, you end up making redundant API calls to fetch the same data.
   如果两个应用程序使用相同的数据，则最终将进行冗余的API调用以获取相同的数据。
3. You can’t customize the iframed app’s behavior.
   您无法自定义iframed应用程序的行为。
4. If a different team owns the framed in app, when they push to production, you’re instantly affected.
   如果其他团队拥有框架内的应用程序，则当他们投入生产时，您会立即受到影响。

Bottom-line: Walk way. Avoid iframes.

底线：步行方式。 避免使用iframe。

方法2：可重用的应用程序组件 (Approach 2: Reusable App Component)

Sharing your app via npm instead of an iframe avoids issue #4 above, but the other issues remain. API, auth, and behavior are all baked in. So I don’t recommend sharing full apps via npm either. The level of granularity is too high, so the user experience suffers.

通过npm而不是iframe共享您的应用可以避免上述问题4，但其他问题仍然存在。 API，身份验证和行为都包含在内。因此，我也不建议通过npm共享完整的应用程序。 粒度级别太高，因此用户体验会受到影响。

方法3：可重用的UI组件 (Approach 3: Reusable UI Components)

I recommend a more granular approach using two flexible building blocks:

我建议使用两个灵活的构建基块，采用更精细的方法：

1. “Dumb” React components (Just UI. No API calls inside.)
   “哑” React组件(仅UI。内部没有API调用。)
2. API wrappers
   API包装器

“Dumb” React components are configurable, unopinionated, and composable. They’re reusable UI. When consuming a “dumb” component like this, you are free to provide the relevant data or specify the API calls the app should make.

“哑” React组件是可配置的，不受限制的和可组合的。 它们是可重用的UI。 当使用这样的“哑”组件时，您可以自由提供相关数据或指定应用程序应调用的API。

However, if you’re going to compose “dumb” components, you need to wire up the same API calls for multiple apps. This is where API wrappers come in handy. What’s an API wrapper? It’s a JavaScript file full of functions that make HTTP calls to your API. My team creates API wrappers. We use Axios behind the scenes to make the HTTP calls.

但是，如果要组成“哑”组件，则需要为多个应用程序连接相同的API调用。 这是API包装器派上用场的地方。 什么是API包装器？ 这是一个JavaScript文件，其中包含可以对您的API进行HTTP调用的功能。 我的团队创建了API包装器。 我们在后台使用Axios进行HTTP调用。

Imagine you have a user API. Here’s how to create a user API wrapper:

假设您有一个用户API。 以下是创建用户API包装器的方法：

1. Create a JS file with public functions like getUserById, saveUser, etc. Each function accepts the relevant parameters and uses Axios/Fetch to make HTTP calls to your API.
   使用公共函数(如getUserById，saveUser等)创建一个JS文件。每个函数均接受相关参数，并使用Axios / Fetch对您的API进行HTTP调用。
2. Share the wrapper as an npm package called userApi.
   将包装器共享为名为userApi的npm包。

Here’s an example.

这是一个例子。

/* This API wrapper is useful because it:1. Centralizes our Axios default configuration.2. Abstracts away the logic for determining the baseURL.3. Provides a clear, easily consumable list of JavaScript functionsfor interacting with the API. This keeps API calls short and consistent. 
*/
import axios from 'axios';let api = null;function getInitializedApi() {if (api) return api; // return initialized api if already initialized.return (api = axios.create({baseURL: getBaseUrl(),responseType: 'json',withCredentials: true}));
}// Helper functions
function getBaseUrl() {// Insert logic here to get the baseURL by either:// 1. Sniffing the URL to determine the environment we're running in.// 2. Looking for an environment variable as part of the build process.
}function get(url) {return getInitializedApi().get(url);
}function post(url, data) {return getInitializedApi().post(url, data);
}// Public functions
// Note how short these are due to the centralized config and helpers above. ?
export function getUserById(id) {return get(`user/${id}`);
}export function saveUser(user) {return post(`user/${user.id}`, {user: user});
}

On my team, we share our React components and API wrappers as private packages on npm, but Artifactory is a nice alternative.

在我的团队中，我们在npm上以私有包的形式共享React组件和API包装器，但是Artifactory是一个不错的选择。

These Lego blocks give us the foundation for quickly building new solutions out of reusable pieces.

这些乐高积木为我们提供了从可重复使用的零件快速构建新解决方案的基础。

A highly composable system provides components that can be selected and assembled in various combinations to satisfy specific user requirements. — Wikipedia

高度可组合的系统提供可以多种组合选择和组装的组件，以满足特定的用户要求。 — 维基百科

So ideally, your “dumb” reusable UI component is composed of other reusable components, also shared on npm!

因此，理想情况下，您的“哑”可重用UI组件由其他可重用组件组成， 这些组件也在npm上共享 ！

With reusable React components and API wrappers published to npm, it’s trivial to build something awesome.

随着可重用的React组件和API包装器发布到npm，构建一些很棒的东西变得微不足道了。

It’s like snapping Lego pieces together. ?

就像将乐高积木拼凑在一起。 ？

I explore the merits and downsides of the approaches above in more detail here. And I recently published a comprehensive course on Creating a Reusable React Component Library on Pluralsight. ?

在这里 ，我将更详细地探讨上述方法的优缺点。 我最近在Pluralsight上发布了关于创建可重用React组件库的综合课程。 ？

Have a different approach you enjoy? Chime in via the comments.

您喜欢其他方法吗？ 通过评论鸣叫。

寻找更多关于React的信息？ ⚛️ (Looking for More on React? ⚛️)

I’ve authored multiple React and JavaScript courses on Pluralsight (free trial).

我已经在Pluralsight上编写了多个React和JavaScript课程 ( 免费试用 )。

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, Microsoft MVP, and trains software developers internationally on front-end development practices. Cory tweets about JavaScript and front-end development on Twitter as @housecor.

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

翻译自: https://www.freecodecamp.org/news/designing-reusable-react-components-1cbeb897b048/

react 组件名称重复