探索微前端的场景极限

}

}

第二步：通过 MicroApp 组件引入微应用：

import MicroApp from ‘./MicroApp’;

import React from ‘react’;

class App extends React.Component {

render() {

return (

{

this.props.admin

?

}

)

}

}

如果你是 umi 应用，那只需要直接使用插件封装好的组件即可：

import { MicroApp } from ‘umi’;

function MyComponent() {

return (

)

}

这类方式适用于一些可共用的、带业务逻辑的服务型组件（类似于我们以前常说的端对端组件）：比如带聊天交互的客服机器人、带引导功能的 intro 服务等。

如蚂蚁 sofa 产品控制台中的这个使用入门微应用：

通过组件的这种方式，我们可以完全自主的控制微应用的渲染，并与之做一些复杂的交互。不论是在开发者的编码心智，还是用户的体验上，都跟使用一个普通的业务组件无异。

组件的方式非常灵活，几乎解决了所有路由绑定方式渲染微应用的问题，但也有自己的一些局限：比如我们会要求这类微应用必须是不带路由系统的 widget 类型，不然也会出现多实例时路由冲突的问题。

嵌套渲染场景

---

有一些更复杂的场景中，我们可能需要使用到「套娃」的方式集成我们的若干微应用。

比如我们要在应用 A 下集成应用 B 的商品列表页，然后在应用 B 的商品列表页呼出应用 C 的买家详情页，所有应用的唤起都以 弹层/抽屉 这种不刷新的交互来完成。

在有了上面两个场景的实践经验后，我们很容易得出这样的组合逻辑：

在应用 A 中通过调用 loadMicroApp(B) 的方式唤起微应用 B，然后在微应用 B 中通过_loadMicroApp(C)_ 的方式唤起微应用 C，通过这样的调用链路即可很完美的完成产品上的诉求。

但是现实情况往往没有那么简单，前面提到过，若想要 loadMicroApp API 能符合预期的运行，我们需要确保被加载的微应用是不含自己的路由系统，否则会出现多个应用间路由系统互相 抢占/冲突 的情况。

而现实情况是，我们大部分需要复用的页面/组件，都会是某个站点的局部路由页ÿ