【组件开发】可重用革命：组件开发的最佳实践

编写代码并将其作为组件发布是不够的

每个人都知道，根据定义，一个组件应该是可重用的，否则，你为什么一开始就想把代码变成一个组件，对吧？

好吧，虽然每个人都可能知道，但并不是每个人都知道制作可重用组件的最佳方法。有时最终的结果是一个次优的实现，虽然可以重复使用，但肯定会更好。

所以，让我们来看看我作为一名软件开发人员多年来学习的一些最佳实践。

模块化设计

在考虑如何设计新组件时，你应该想到的第一件事是“模块化”。

换句话说，你的组件应该被视为一块乐高积木，一块更大的结构，虽然它在原地工作得很好，但也可以（比喻）移动到其他有意义的地方，它也会同样工作。

用乐高积木构建应用程序正是像Bit这样的开源工具链所能实现的方法。通过将UI的原子单元提取到组件中，并独立地存储、测试和记录它们，您可以推动可组合的UI设计，使其能够更好地扩展和维护。

从上面的陈述来看，“有意义的地方”部分很重要，因为否则你会要求一个可以放在任何地方的神奇组件。

相反，关注现实世界中可以分享的场景，但要考虑以下内容：

• 不应该有任何不必要的外部依赖关系。例如，根据React，如果你正在构建一个React组件是可以的。但是，当你构建一个处理时间的组件时，依赖MomentJS（举个例子）就不是了。相反，尝试允许使用标准接口对库进行依赖注入，并使用所给的任何东西。
• 确保正确定义了所需的输入和预期的输出。如果您希望您的组件是模块化的，那么设计的一部分包括定义它期望的输入，以便其他人可以围绕它们进行编码，以及它返回的值。这样，其他人就可以确保它与他们现有的业务逻辑兼容。

诚然，我们生活在现实世界中，所以试着根据您的环境限制调整上述理想要求。

记住，它不一定是完美的，它需要尽可能好（两者之间有很大的区别）。

保持简单

通常的KISS原则也适用于此。保持简单愚蠢的想法是，你考虑的是谁将为他们使用你的组件和代码，而不是为你。

换句话说，试着让他们的生活更轻松，改善你的模块的开发人员体验，每个人都会想使用它。

同时，作为KISS原则的一部分，尽量保持您的组件较小。

我喜欢这样想的一种方式是将它与Linux的CLI工具进行比较。Linux终端有很多工具，它们都遵循相同的原则：它们只做一件事，而且做对了。您可以结合各自的功能创建极其复杂的脚本，但单独使用它们只能让您做这么多。

您的组件也应该如此。小的、可组合的组件比大的、无所不能的组件具有更大的灵活性和可重用性。

除此之外，您还可以获得额外的好处，即更小、更简单的组件更容易维护和调试。所以双赢！

文档、文档、文档

我知道这听起来很无聊，但如果你不让人们知道如何使用你的东西，你怎么能指望他们使用你的？

就这么简单，请注意，我不是在谈论自动生成的参考页面，您可以使用一些工具在2秒内构建该页面。这些文档可能对您很有用，但对于那些刚刚了解您的组件并想了解如何使用它、添加了什么样的配置选项以及它是否适合他们的特定用例的人来说就不方便了。这些开发人员需要更多。

他们需要例子，需要人工编写的解释（见鬼，你现在甚至可以使用ChatGPT，它可能会起作用），关于每个功能、每个方法和每个选项。

如果你想让你的组件受到重视，那么这种文档就必须存在。

此外，您还可以允许人们提出问题和提出问题。如果你在那里发布了代码，你可以使用GitHub。但这给新用户在使用你的代码时提供了额外的安全级别（毕竟，他们可以看到你关心你的用户），也让他们能够解决任何疑问，而无需联系你（如果其他人已经问过这个问题）。

你使用的工具取决于你，实际上，它可以是任何东西，从GitHub页面，到手动编写的网站，甚至像Bit.dev这样的东西。它们允许你在文档旁边的平台中发布自己的组件。您甚至可以在文档中添加活动部分，在那里人们可以尝试修改您的代码示例，以了解它们是如何工作的。这是一个很好的加分项，看起来很神奇。

看看我的一个旧组件的文档：

您有一个很好的UI、实时代码示例，甚至可以在页面上直接呈现一个可行的测试。除此之外，您的组件可以通过Bit平台发现。

我知道这听起来可能不好玩，但相信我，从长远来看，您会很高兴为您的组件构建了适当的文档。

彻底测试部件

这一个感觉它甚至不应该成为这个列表的一部分。

不是因为它不重要，而是因为完全相反的原因。我不应该告诉你这一点，你应该已经知道了：无论何时你想共享任何代码，测试都是强制性的。即使您在内部与自己公司内的其他团队共享组件，您唯一能做的负责任的事情就是确保代码按预期工作，这是通过测试来完成的。

单元测试是我的第一个建议，但如果你觉得很慷慨，其他测试，比如端到端甚至集成测试（尤其是如果你正在构建一个需要与专有系统集成的组件）都是不错的主意。

Bit也是一个很好的工具，可以帮助您简化测试实践，特别是如果您不太喜欢编写和运行自己的测试套件。使用Bit，您可以：

• 易于与流行的测试框架集成：Bit支持与一些最流行的前端测试框架（如Jest和Mocha）集成。这意味着您可以在平台内轻松配置和运行组件的测试。最重要的是，如果你正在使用另一个测试库，你可以按照这个详细的指南自己集成它。
• 自动化测试和验证：Bit包括一个自动化的构建和验证过程，确保您的组件没有错误并按预期运行。这个过程可以包括运行测试、linting和其他有助于确保组件质量的检查。不仅如此，无论何时准备发布，组件都会被隔离测试（我可以自动添加）。
• 协作测试：Bit允许开发人员测试和审查彼此的组件，从而实现开发人员之间的协作。这有助于识别问题，并确保组件在各种环境中正确工作。

记住：保持测试的更新，并找到一种自动执行测试的方法（比如使用Bit），这样无论何时发布新版本，都不会忘记运行测试。

使用语义版本控制

尤其是如果你正在建造别人会使用的东西。始终尝试将一些标准版本控制系统添加到组件中。

这样，他们就可以很容易地理解新版本对他们的影响。在semver的情况下，这是我最喜欢的一个BTW，如果你想更新，只需简单看一下新版本就可以理解。

基于semver的版本号由3个数字组成：（主版本）。（次要版本）。（修补程序版本）。

• 如果只是补丁版本发生了变化（即第三个数字），那么您肯定想要更新。这意味着作者发布了一个错误修复程序。
• 如果次要版本发生了更改（可能还有补丁版本），您可以选择忽略它或获取它。这通常意味着作者发布了一些向后兼容的新功能。因此，即使您没有使用它们，将组件更新到该版本也不会破坏系统！。
• 如果主要版本发生了更改，那么您最好在更新组件后测试代码。主要的版本更新意味着该组件上有中断性的更改。所以在进行更新之前，请记住这一点。

这些是您应该遵循的常规指南，它们让您的用户了解您的更新，这样他们就可以很容易地决定如何处理您的新版本，而无需向您提问或在文档中查找更多详细信息。

如果你想知道如何在你的组件库中实现这一点，像Bit这样的工具可以极大地简化这个过程，你甚至不必考虑那么多。

您获得的一些惊人好处包括：

• 自动版本控制：Bit为您的组件提供自动版本控制。每次您对组件进行更改时，Bit都会创建组件的新版本并跟踪它。您可以使用Bit标记命令指定实际版本，也可以让Bit自己决定。这意味着您可以很容易地跟踪组件随时间的变化。如果您想了解更多关于Bit如何处理组件版本控制的信息，请阅读本深度教程。
• 语义版本控制：Bit支持语义版本控制（这是我最喜欢的版本控制策略的原因！）。
• 版本管理：Bit提供了用于管理组件版本的工具。您可以查看零部件更改的历史记录，比较零部件的不同版本，并在必要时回滚到以前的版本。您可以通过Bit的开发人员查看此视频，展示如何使用组件比较功能。

通过使用Bit，您可以确保您的组件得到正确的版本控制，并且可以有效地跟踪更改并将其传达给用户。

也就是说，无论何时发布组件的新版本，都发布变更日志也是一个好主意。这会提供更多关于您发布内容的详细信息，以防您的用户需要该级别的详细信息。只要确保它们是有意义的，说“几个错误修复”是不够的，详细说明你改变了什么，如果有公共对话或公共问题是你修复的，请链接到它们，这样其他人就有必要的上下文来了解他们在系统中添加了什么。

约定高于配置

你可能不同意这种做法，但我喜欢这种做法。

它背后的想法是，默认情况下，您的组件应该在不需要任何配置的情况下工作。事实上，您可以提供一些“约定”，比如CSS类、子组件的命名，或者您的代码将学习并“神奇地”使用的其他约定。

当然，您应该始终让用户能够通过配置覆盖这些约定。这样，他们就可以确切地确定自己在做什么，并完全控制它。

不要，永远不要，只提供没有覆盖的第一部分。将功能隐藏在约定后面是一个糟糕的DX，您应该始终避免。它剥夺了使用它的人应该拥有的对组件的控制感，当这种情况发生时，他们不信任它。

所以，是的，提供一些“神奇的默认值”，但总是让开发人员根据需要覆盖它们。

考虑可访问性

组件在“理想”条件下工作并不意味着您的组件已经准备好了。是的，这是一个很好的第一步，但那些与您的组件交互但看不到您的“理想”用户的用户呢？或者，如果他们根本看不见呢？

“我的组件可以访问吗？”

这应该是你在称之为“完成”之前问自己的一个问题。特别是因为如果在开发阶段完成，检查可访问性问题并添加所需的代码以使其可访问性并不是一项困难的工作。

如果你想知道你能做些什么，请查看这篇详细的帖子，了解你可以通过在组件上做一些额外的工作来影响用户体验的所有方式。

在现有组件中改造可访问性非常困难，所以在规划下一个组件时请记住这一点。

最后，由您来决定您的组件何时“完成”。您可以自由发布和共享任何类型的代码，但在这样做时，您应该从开发人员和用户的角度考虑将要使用它的人。

在这两种情况下，您都有几个考虑因素，可以改善或破坏他们的体验，并确保或否定组件的成功和采用。

我是否错过了您在设计自己的组件时需要牢记的“最佳实践”？在评论中分享，让我们一起讨论！

使用可重复使用的组件构建应用程序，就像乐高一样

Bit的开源工具帮助250000多名开发人员使用组件构建应用程序。

将任何UI、功能或页面变成可重用的组件，并在应用程序中共享。协作更容易，构建速度更快。

• → Learn more

将应用程序拆分为组件，使应用程序开发更容易，并享受所需工作流的最佳体验：

best experience for the workflows you want:

• → Micro-Frontends
• → Design System
• → Code-Sharing and reuse
• → Monorepo