最近在做性能优化相关的事情，也比较好奇umi2，umi3这套机制是如何运行的，怎么更好的做性能优化。

umi2和umi3都是一个编译时框架，即先会对本地代码做预编译，然后再交给webpack等打包工具，不然webpack无法直接处理。支付宝小程序也是这样。

干货分享：蚂蚁金服前端框架和工程化实践语言 & 开发陈成_InfoQ精选文章 路由实现

整体是如何构成的

  1. config/routes中写了路由的配置，支持树结构的嵌套
  2. 预编译成src/.umi/core/routes 文件
  3. webpack打包，会打包出多个chunks，
  4. 运行时 👍👍 重点

几个问题

  • 为什么上一个layout执行完，才会加载下一个命中层级的资源，背后的原理是什么？
    • 猜测children是对原组件做了wrapper，背后包含loadable，即要子components先执行load（即去加载资源），执行完才初始化

TODO

  • 弄清楚整个接口
  • 弄清楚整个运行时结构
  • 组件的dynamic代码，还是移动到运行时把？再详细和清晰化一些
  • 为何Router不直接使用，有几种不同的runtime? 服务端的？

1 文件编写

  1. path
  2. wrappers
  3. component
  4. // 即子路由
  5. routes

2 预编译

  1. import { ApplyPluginsType, dynamic } from '/Users/admin/devspace/umiapp3/node_modules/umi/node_modules/@umijs/runtime';
  3. export function getRoutes() {
  4.     const routes = [
  5.         {"path": "/sub-page",
  6.          // 父路由，一般定义layout
  7.          // 注释定义了chunk name
  8.          // dynamic则在下面的4运行时中讲
  9.          "component": dynamic({ loader: () => import(/* webpackChunkName: 'p__layouts__index' */'/Users/admin/devspace/umiapp3/src/pages/layouts/index'), loading: LoadingComponent}),
  10.          "name": "",
  11.          // 子路由
  12.          "routes": [
  13.              {
  14.                  "path": ""
  15.                  "name":
  16.                  "component"
  18.              }
  19.          ]
  20.         }
  21.     ];
  23.     // allow user to extend routes
  24.   plugin.applyPlugins({
  25.     key: 'patchRoutes',
  26.     type: ApplyPluginsType.event,
  27.     args: { routes },
  28.   });
  30.     return routes;
  31. }

umi.ts的运行核心

  1. import { getRoutes } from './core/routes';
  3. const getClientRender = (args: { hot?: boolean; routes?: any[] } = {}) => plugin.applyPlugins({
  4.   key: 'render',
  5.   type: ApplyPluginsType.compose,
  6.   initialValue: () => {
  7.     const opts = plugin.applyPlugins({
  8.       key: 'modifyClientRenderOpts',
  9.       type: ApplyPluginsType.modify,
  10.       initialValue: {
  11.         routes: args.routes || getRoutes(),
  12.         plugin,
  13.         history: createHistory(args.hot),
  14.         isServer: process.env.__IS_SERVER,
  15.         dynamicImport: true,
  16.         rootElement: 'root',
  17.       },
  18.     });
  19.     return renderClient(opts);
  20.   },
  21.   args,
  22. });

dynamic({loader, loading});

dynamic -> Loadable -> createLoadableComponent(执行加载代码，并根据加载的状态，渲染loading或者加载完成的组件，或者null)

3 编译

  1. component: dynamic({
  2.   loader: function loader(){
  3.      return Promise.all([
  4.        __webpack_require__.e('chunk1'),
  5.        __webpack_require__.e('chunk2'),
  6.        __webpack_require__.e('p_chunkName'),
  7.      ]).then(__webpack_require__.bind(__webpack_require__, "./src/");
  8.   },
  9.   loading: 
  10. })

4 运行时 如何递归树层级的路由 👍👍

  • Layout props.children即是子组件？是谁计算出来的？貌似是一个<Switch />组件

plugin-layout -> 递归方式，把路由配置的item.children赋值为item.routes，帮助在layout中执行props.children渲染子组件

  • renderClient 负责组合umi的opts和react-router-config，react-router中的Router提供__RouterContext以及@umi/runtime 并在此变更document.title

使用了reactRouterConfig.matchRoutes并未使用renderRoutes

  • React的树结构是如何的？通过Switch传入下个层次的route配置实现了递归。
  1. <RouterComponent> 路由的根组件，只有一个
  2.     <Router> runtime的router，也即来自react-router-dom的Router，自umi顶部传入进来的opts.history
  3.         <Switch> /**props [Routes] 根据传入的routes，执行match，render不同的Component.**/
  4.                 <Route>
  5.                         <runtime.__RouterContext.Consumer> // 消费上一级别的Consumer
  6.                             <runtime.__RouterContext.Provider> // 提供给下一级别的Provider，新的计算后的props，和Formily的每个层级有点像，基于上一层不断递进的层级。
  7.                                 <xxxLayout> 第一层级，props.children为Switch组件
  8.                                     <Switch> 
  9.                                         <Route>
  10.                                             <xxxPage /> 第二层级，
  11.                                         </Route>
  12.                                     </Switch>
  13.                                 </xxxLayout>
  14.                             </runtime.__RouterContext.Provider>
  15.                         </runtime.__RouterContext.Consumer> 
  16.                 </Route>
  17.         </Switch>
  18.     </Router>
  19. </RouterComponent>

renderRoutes将路由的routes配置，转换为React的树结构

  • 组件的动态加载，dynamic

dynamic有两个参数，loader和loading

dynamic作为一个组件，负责异步加载loader的加载，并且在不同状态时输出不同内容，loading的展示，包加载完成后则展示真正的组件。

  1. component: dynamic({
  2.   loader: function loader(){
  3.      return Promise.all([
  4.        __webpack_require__.e('chunk1'),
  5.        __webpack_require__.e('chunk2'),
  6.        __webpack_require__.e('p_chunkName'),
  7.      ]).then(__webpack_require__.bind(__webpack_require__, "./src/");
  8.   },
  9.   loading: 
  10. })

整个umi的运行时核心和插件机制

.umi/umi.ts 入口文件
@umijs/renderer-react 这个做什么？针对umi的opts配置来渲染，opts.routes等结合react-router-config.
@umi/runtime

  1. import { getRoutes } from './core/routes';
  4. const getClientRender = (args: { hot?: boolean; routes?: any[] } = {}) => plugin.applyPlugins({
  5.   key: 'render',
  6.   // 插件类型compose，还有modify，event
  7.   type: ApplyPluginsType.compose,
  8.   initialValue: () => {
  9.     // 插件
  10.     const opts = plugin.applyPlugins({
  11.       key: 'modifyClientRenderOpts',
  12.       type: ApplyPluginsType.modify,
  13.       initialValue: {
  14.         routes: args.routes || getRoutes(),
  15.         plugin,
  16.         history: createHistory(args.hot),
  17.         isServer: process.env.__IS_SERVER,
  18.         dynamicImport: true,
  19.         rootElement: 'root',
  20.       },
  21.     });
  22.     return renderClient(opts);
  23.   },
  24.   args,
  25. });
  27. const clientRender = getClientRender();
  28. export default clientRender();

有哪些插件事件？

  • render
  • modifyClientRenderOpts

一些插件的运行

  • plugin-antd-icon-config -> patchRoutes 针对icon的配置，patch为antdIcon的element
  • plugin-layout -> 递归方式，把路由配置的item.children赋值为item.routes，帮助在layout中执行props.children渲染子组件

插件哪几种组合类型？compose, modify, event