React组件库正变得越来越流行，这是有原因的。它们是很好的工具，可以保证数字产品内部和之间的UI元素的一致性和可重用性，同时有可能大大减少开发时间和精力。
在本教程中，我们将概述构建一个自定义组件库的不同方法。但首先，我有一个问题要问你：你真的需要自己的组件库吗？让我们来谈谈定制一个的好处和权衡。
建立一个组件库的好处
代码中的一致性
使用组件库的最大好处之一是，它可以保证我们的组件在整个应用程序中的外观和行为一致。UI的不一致会严重损害用户体验，并成为挫败感的来源。
可重用性
从定义上讲，存在于组件库中的组件是可重复使用的。这在网络应用内部和之间都是如此。如果需要改变，我们只需在组件库中改变一次，然后就会反映在各个地方。
可访问性
确保我们的网络应用尽可能的无障碍是很重要的。通过使用组件库，基本的可访问性水平可以（而且应该）直接建立在我们的组件中。
开发时间
组件库可以成为一个巨大的节省时间的工具。拥有一个随时可用的组件库意味着建立新功能的时间更少。更重要的是，由于UI行为是预先定义的，设计者和开发者之间的沟通开销更少。
文档
组件库是创建有关UI组件的有用和全面的文档的好方法。关于这一点的更多细节，请查看我的文章：React组件的自我文档化。
社区
一个完善的组件库可能对其他人有用。它可以被开源并与Web开发社区分享。
构建一个自定义组件库听起来很不错，不是吗？但总是有反面的。
构建自定义React组件库的权衡因素
资源
构建一个组件库需要大量的跨职能的前期工作，包括设计、产品和开发团队。这是一个巨大的工程，需要适当的资源和专业知识来获得所有的好处。
维护
维护一个自定义组件库是一项持续的工作。它需要持续的关注以保持它的更新。牵涉到一个开源社区会产生更多的开销。
设置
组件库的使用增加了项目设置的复杂性。通常，为了能在不同的项目中重复使用，组件库要与我们的应用程序分开，并作为一个依赖项来安装。这意味着每次有变化时，组件库都需要重新发布，所有依赖的应用程序都要更新。
定制化
组件库在设计上对我们的组件可能做的事情有很多限制。这通常是一件好事。然而，在某些情况下，对定制的需求是不可避免的。在组件API的灵活性和简单性之间取得适当的平衡可能是非常具有挑战性的。
建立还是不建立一个自定义的React组件库？
鉴于上述情况，对于大多数项目来说，从头开始构建自己的组件库似乎根本不值得花时间和精力。好消息是，你可能不需要这样做!
有许多方法可以平衡创建组件库的好处和权衡，React生态系统在这里提供了帮助。
建立React组件库的方法
1.从零开始
正如这个名字所暗示的，在这种方法中，我们自己创造一切--从UI规则和模式到组件本身。我们使用React，也许再加上我们最喜欢的CSS-in-JS库（如果你对这种东西感兴趣的话 ），但其他一切都要靠我们自己来构建。
优点。
- 几乎是无限的自由，可以根据需要进行创建、构建和定制
- 对第三方的依赖性最小
- 对源代码的完全控制
缺点。
- 巨大的跨职能的前期工作
- 持续的维护成本
从头开始构建React组件库主要适用于复杂且有点特立独行的数字产品，跨越多个网络应用，并且有足够大的开发团队能够承受成本。
2.用Tailwind CSS、styled-components和Styled System引入约束条件
当涉及到我们组件库的基本构件时，建立我们自己的结构和约束--颜色、排版、间距、阴影等--既困难又在大多数情况下是不必要的。伟大的解决方案已经存在!
在这种情况下，人们立即想到的是Tailwind CSS。它允许我们用一套有限的、基于约束的样式工具来构建复杂的用户界面。Tailwind很容易被开发人员采用和熟悉，而且还具有极大的可定制性和灵活性。
如果我们选择CSS-in-JS的解决方案，特别是风格化组件，另一种引入一些有用约束的方法是使用风格化系统。有了它，我们可以用极其有用的方式来构造我们的主题，并利用一些实用工具，同时在构建我们的组件时保留重要的控制。
优点。
- 根据需要自由创建、构建和定制
- 基于制约因素的基本构件提供了结构。
缺点。
- 我们在组件库的核心部分引入了一个依赖关系--以后可能无法从它那里迁移。
- 维护成本（虽然有所降低）仍然是我们的责任。
这种方法适用于有UI组件的项目，这些组件需要很大的灵活性和定制自由。在确定解决方案之前，要确保引入的约束条件适合项目的特定用例，并符合设计和开发要求。
3.使用选定的组件，如React日期选择器、react-tippy和Reach UI
有一些React组件是出了名的难以从头创建的。想想一个需要支持搜索、多选、创建自己的选项是不存在的、键盘控制和响应性等功能的选择组件。
一个带有日历、键盘控制、屏蔽输入和验证功能的日期选择器又如何呢？还有一个动画的、可定制的、总是正确定位的工具提示怎么样？即使是像模态和标签这样广泛使用的组件，要从头开始正确创建也是很有挑战性的。
在创建组件库时，节省时间和精力的一个好方法是利用React的生态系统来创建这些更复杂的组件。回到上面的列表中，这里有一些例子。
当涉及到选择组件时，react-select带有所有已经提到的功能和更多开箱即用的功能。对于日期选择器，根据使用情况，也有一些很好的选择，包括react-date-picker、react-datepicker和AirBnB的react-dates。
当涉及到工具提示时，react-tippy也涵盖了我们。最后，Reach UI是一个库的例子，它提供了真正可访问和可定制的组件，如模态、标签、菜单等等。它们都可以单独安装，所以可以选择全部或只选择其中的一部分来添加到你的项目中。
从另一个角度看，将第三方组件添加到你的库中是有一些取舍的。
优点。
- 通过利用经过实战检验的UI来节省时间和资源，同时减少我们自己代码库的复杂性
- 有选择地使用外部组件可以将依赖性的影响降到最低
- 组件库的维护成本有所降低
缺点。
- 对我们所依赖的组件的行为和功能造成了很大的限制
- 引入了一些我们几乎无法控制的第三方依赖关系
- 外部组件有时难以完全定制
使用这种方法可以减轻组件库开发团队的巨大负担。尽管如此，在决定集成第三方组件时，你必须考虑长期的影响，并在可能的范围内确保这些组件与项目需求相对应。
4.高度可定制的React组件库，如Chakra UI
通常的情况是，我们愿意为项目的组件库投入的时间和资源根本不等同于实现上述方法的需要。如果我们的项目范围有限，或者即使是更大的项目，如果我们需要的UI组件是相对标准的，那就可能是这种情况。
我们仍然希望能够对我们的组件进行风格化和某种程度上的定制，但我们很高兴能够依赖由外部基础组件库决定的合理的组件API。幸运的是，在React生态系统中，有几个选项可以选择。虽然React组件库的全面清单可以在其他地方找到，但我认为Chakra UI在绝大多数情况下是这种方法的合适选择。
优点。
- 大大减少了实现组件所需的时间和精力
- 组件的风格很容易定制
- 分担了大部分的维护成本
缺点。
- 我们完全依赖于我们所选择的库，所以要从它那里迁移出去可能是不可能的。
- 随着时间的推移，项目需求有可能与外部库中的内容发生分歧。
如果我们重视开发速度，同时相信未来的需求不会与我们的选择相冲突，那么为我们的项目使用一个现有的组件库就是一个好办法。
5.即用型组件库
最后，我们可以用一个随时可以使用的组件库来建立我们的项目。这些解决方案，虽然在一定程度上是可定制的，但为我们直接提供了我们需要的一切，从颜色模式和主题到全面的组件集合。
这方面的一个典型例子是谷歌的Material UI。这个库确实很广泛，如果你想以最小的设置开始构建你的React应用，这使它成为完美的选择。正因为如此，Material UI毫无疑问是我在构建原型和概念验证时的首选工具。在时间紧迫的情况下，它在面试任务中也很方便。
然而，将一个现实生活中的项目与一个意见强烈的组件库紧密结合起来有很大的缺点。让我们来分析一下。
优点。
- 容易和简单地开始，这意味着需要最小的前期努力
- 最小的维护成本
缺点。
- 从一开始就很难进行定制
- 大部分的功能和风格都是预先定义的。这可能会使我们的用户界面感觉很一般，与其他使用相同库的人相似。
- 设计师和开发人员都必须处理他们无法控制的约束和设计原则。
结论
在构建（或不构建）我们的自定义组件库时，我们选择的方法是一个战略决策，它将从头到尾影响我们的React项目。了解这一选择的意义，并能够充分评估利益和权衡是最重要的。我希望上面的概述能帮助我们更好地迎接挑战。
如果你觉得这篇文章有用，请在Twitter上关注我，了解更多科技内容
The postChoosing when to build a custom React component libraryappeared first onLogRocket Blog.
