认识达内从这里开始

我们在上文中给大家简单提到了关于微前端开发的一些基础知识和优势特点等内容，今天我们就通过案例分析来了解一下，微前端开发的具体应用范围与表现形式都有哪些。

共享组件库

前文提到微前端的视觉一致性是很重要的。一种实现方法是开发一个共享的、可重用的UI组件库。创建这样一个库的主要好处是通过重用代码和来减少工作量，同时实现视觉一致性。此外，这个组件库可以当作样式指南来用，它可以是开发者和设计人员之间的一个很好的协作桥梁。

但容易犯的一个错误就是过早地搞出来一大堆组件。我们都想创建一个基础框架，其中包含所有应用所需的所有常见视觉效果。但其实我们很难提前判断组件应该用什么API，结果很多组件都是在白费功夫。所以我们更愿意让团队在需要的时候再去创建自己的组件，就算因此产生了一些重复工作也没关系。应该顺其自然，等组件的API都确定下来以后再把重复代码收集到共享库里，这样就不会徒劳无功了。

常见的共享组件是“无声”的视觉基本元素，如图标、标签和按钮等。我们还可以共享可能包含大量UI逻辑的复杂组件，例如自动完成、下拉搜索字段等;或者是可排序、可过滤的分页表。但是，请确保共享组件仅包含UI逻辑，而不包含业务或域逻辑。将域逻辑放入共享库会给应用之间带来高度耦合，改动起来也更困难。例如，一般来说不该共享ProductTable，因为它会包含关于“产品”的定义及表现的各种内容。这种域建模和业务逻辑应该属于微前端的应用代码，不应该放到共享库里。

作为一种内部共享库来说，它的所有权和管理也自然存在一些棘手的问题。一种管理模式是将其视为共享资产，让“每个人”都拥有它——实践中这通常意味着没人能真正拥有它。这个共享库很快就会变成一堆不一致的代码集合，也没有明确的约定或技术愿景。反过来说，如果共享库的开发工作完全中心化，那么组件的创建者与使用者之间就会严重脱节。好的模式应该是允许所有人为库做贡献，但要有一个保管人(一个人或一个团队)负责确保这些贡献的质量、一致性和有效性。维护共享库需要强大的技术技能，还需要能协调众多团队的管理技能。

跨应用通信

关于微前端常见的一个问题是如何让这些微前端互相通信。一般来说，我们建议尽可能减少这类通信需求，因为它通常会重新引入我们本想避免的耦合度。

换句话说，某种程度的跨应用通信是必要的。自定义事件允许微前端之间间接通信，从而尽量减少直接耦合;但它也会让各个微前端之间已有的合约更难确定和增强。另一种方法是将回调和数据向下传递的React模型(这里是从容器应用向下传递到微前端)，它能让模块之间的合约更加明确。三种方法是使用地址栏作为通信机制，我们将在后面详细介绍。

如果你在使用redux，常见方案是为整个应用提供单个全局共享存储。但如果每个微前端都是自包含的应用，那么它们都应该有自己的redux存储。Redux文档甚至给出了“在大型应用中将Redux应用隔离为组件”的说明。

无论选择哪种方法，我们都希望微前端可以彼此发送消息或事件来通信，同时避免任何共享状态。就像在微服务之间共享数据库一样，一旦我们共享了数据结构和域模型就会引入大量的耦合，改动起来也会更困难。

这里也有几种不错的方案选项。重要的是要时刻考虑你正在引入怎样的耦合，以及如何持续维持模块之间的合约。就像微服务之间的集成一样，你需要在不同应用和团队之间协调升级流程，才能对集成做出重大改动。

你还应该考虑如何自动验证集成的工作状态。一种方法是功能测试，但它们的实施和维护成本很高。或者你可以实现某种形式的消费者驱动合约，这样一来，无需在浏览器中集成全部微前端并运行应用，就能让每个微前端确定其他微前端需要哪些内容。

【免责声明】：本内容转载于网络，转载目的在于传递信息。文章内容为作者个人意见，本平台对文中陈述、观点保持中立，不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。