在Auth0，我们希望客户能够成功地使用我们的身份验证解决方案。客户成功基础架构团队构建面向客户的内部工具，帮助我们实现这一目标。使他们能够在用户界面开发中进行快速迭代的技术之一是React。这个团队构建了各种不同的项目，比如运行Auth0支持中心的软件，以及支持内部支持工作流的其他内部工具。除了React，他们还使用节点.js, 哈皮.js和Redux。这是一个JavaScript重的团队，其动力是快速构建高质量的特性。你愿意加入这样的团队吗？我们目前正在招聘工程师加入客户成功基础设施团队！Guillermo Rodas是客户成功基础架构团队的工程师之一。他最近领导了一个名为"支持中心组件"的项目计划，该项目解决了一个问题，即在我们面向客户的内部工具站点中存在重复的React组件。在这篇博文中，通过Guillermo的见解，我们将探讨Account Center团队如何使用React和Storybook优化UI开发，并通过创建可在不同项目间共享的组件库来促进一致的品牌推广。不要重复你自己（干）Auth0支持中心（一个面向客户的站点）和customer Success Tools（一个内部站点）在它们的界面上有相似的元素。例如，尽管每个接口中有不同的业务上下文，但两个接口中的配额利用率特性使用相同的结构向用户报告数据。我们遇到的问题是，这个结构是作为每个接口的React组件单独实现的，而不是共享实现。开发团队正在复制组件来解决相同的问题。这种方法固有地给开发人员带来了痛苦，因为配额利用率只是我们站点中具有重叠前端架构的少数几个特性之一。有重复代码并不理想。一个版本的代码可能比另一个版本更为更新，这就产生了类似于围绕代码版本控制的竞争条件。如果发现了一个bug，就需要在共享代码的每个地方修复它，同时希望开发人员能够记住它们。一个不一致的错误修复过程可能会增加错误并在代码库中造成严重破坏。"如果你在代码中看到模式，那就说明它是干燥的主要元素。有时，这意味着在你看不懂文本之前要站在屏幕后面，仔细寻找模式解决这个代码重复问题的方法是使代码变干（不要自己重复）。我们需要编写一次表示组件，然后让每个特性/接口从一个单一的事实来源实现它：组件库。正如clearlevt的markperkins在他们关于构建组件库的见解深刻的文章中所解释的那样，组件库是一种有效且健壮的格式，用于向开发人员和客户交付文档化的代码和设计模式。React有助于构建组件库，因为它涉及到以"组件化方式"进行思考和构建的过程，正如Mark所创造的那样。React有助于组件库的架构，因为它涉及到以"组件化方式"进行思考和构建的过程，正如@allmarkedup从@clearleft中创造的一样在推特上留言来源集成组件库在我们的工作流程中实现组件库的概念是一个架构决策，它要求我们进一步制定组件和特性开发过程的战略。例如，在创建组件时，我们开始问以下问题：如何在库中对组件进行分类？我们应该有分类吗？如何展示组件的原型？是否应该使用带有模拟数据的空白页？组件的不同状态是否应该在其原型上呈现？能够以一种有组织的方式直观地回答这些问题对于帮助我们清晰地迭代我们的特性开发过程是至关重要的。该过程通常包括：创建MVP（最小可行产品）或POC（概念证明）。获得关于MVP/POC的反馈。通过开发迭代集成反馈。通过这个过程，我们不断地展示用户界面是如何通过其组件显示数据的，并根据组件可以显示的数据定义组件的状态。我们需要一个可以让我们：创建独立于任何特定功能集成的组件。预览组件及其不同状态。为了便于查找，让我们将每个构件分类到族中。将我们的组件托管在中心位置，以创建库的概念。使用React，我们已经可以定义组件。我们需要一些东西来预览、分类和托管它们。幸运的是，我们能够使用一个工具来满足所有这些需求：故事书。"不要重新发明。要创建可跨项目共享的模块化和可重用组件，请使用React和Storybook构建组件库。"在推特上留言来源故事书：让组件讲述一个故事Storybook是一个UI组件的UI开发环境。它就像一个电路板，在那里我们可以把我们的组件放在不同的状态下可视化，并与它们进行交互，就像它们在一个实时应用程序上一样。因为Storybook运行在我们的应用程序之外，所以这一切都是孤立完成的。Storybook有自己的网页包设置，非常类似于createreact应用程序，但可以配置以满足我们的需要。该平台还提供了一个内置的dev服务器，以帮助我们在本地预览组件。正如我们所描述的，当我们决定使用Storybook创建一个组件库时，我们已经有了一个工作项目。然而，由于其独立的体系结构，向现有项目添加Storybook并不会对现有代码库造成任何负担或更改。我们像其他npm包一样添加了它，然后将我们现有的组件导入到它的平台中。然而，它确实要求我们对组件的创建、维护和维护进行不同的思考，这是一个我们称之为"故事书驱动的开发"的集成过程有了Storybook，我们可以逐步独立地构建React组件，而不必担心从一开始就准备好最终的组件版本或环境。对于我们来说，它已经成为一个舞台和计划工具。"故事书和反应让我们逐步规划、规划和构建组件。这是一本生活方式指南。"在推特上留言记录和测试痛点我们的客户成功基础架构团队还有第二个问题：记录和测试每个项目特性的所有不同场景。在我们的项目中，我们有高覆盖率的测试，这些测试通过Heroku中配置的连续集成管道运行。用吉勒莫的话说："我们有强大的测试和持续的集成，因为我们希望有一个美好的周末，而不必担心我们的生产建设失败。拉取请求（PR）中最常见的短语是：请添加测试。"除了测试之外，我们还高度重视代码的文档化。这是我们留给将来使用我们代码库的人的遗产。幸运的是，拥有像Storybook这样的组件库可以让我们以可视化和声明的方式记录组件。故事书为开发人员提供了理解组件的结构和状态所需的所有信息。测试很难。对于大多数开发人员来说，测试是一个悲伤的故事。好吧，不再是了！有了现代和强大的工具，我们的测试故事是一个愉快的故事。在React中，UI测试有不同的方面。我们将它们及其工具分类如下：结构测试：酶Jest快照测试交互测试：酶CSS/样式测试：图像比较做回归测试使用内联样式的Jest快照其他工具，如BackstopJS、PhantomCSS、Gemini和Happo手动测试Storybook通过名为StoryShots的附加组件与Jest Snapshot集成。通过使用我们的快照测试，将现有的笑话脚本作为快照的输入添加到我们的故事库中。配置好Heroku CI管道后，每当有人针对我们的故事书使用新组件进行公关时，就会触发这种自动测试，并创建我们应用程序的可视化预览。这使我们能够更快地执行结构和样式测试。分享我们的工程知识我们很高兴与大家分享我们的工程过程是什么样的，以及它如何对我们的开发人员在创建、测试和记录用户界面方面的体验产生了积极的影响。您可以通过在Twitter上关注@auth0、订阅我们的时事通讯或时不时查看此博客来与我们保持联系。我们希望你会喜欢我们正在创造的内容。关于Auth0Auth0为应用程序、设备和用户提供了一个验证、授权和安全访问的平台。安全性和应用程序团队依赖Auth0的简单性、可扩展性和专业知识，使身份对每个人都有效。Auth0每月维护超过45亿次登录交易，确保身份安全，从而使创新者能够进行创新，并使全球企业能够为其全球客户提供可靠、卓越的数字体验。更多信息，请访问https://auth0.com或在Twitter上关注@auth0。Auth0文档