umi入坑

umi学习笔记

在 Ant Design Pro 中，因为我们的底层框架是 umi，而它自带了代理请求功能，通过代理请求就能够轻松处理数据模拟的功能。

配置式路由和约定式路由

Umi的路由既支持配置样式，又支持约定样式。配置样式是对于现实的低头，也是大部分用户在用的，因为他功能强大；约定样式是我们希望走去的方向，因为他简洁优雅。

.umi临时文件

+ .umi
  + core      ＃内部插件生成
  + pluginA   ＃外部插件生成
  +预设B   ＃外部插件生成
  + umi.ts    ＃入口文件

临时文件是Umi框架中非常重要的一部分，框架或插件会根据你的代码生成临时文件，这些原来需要放在项目里的脏乱差的部分都被藏在了这里。

您可以在这里调试代码，但不要在.git仓库里提交他，因为他的临时性，每次启动umi时都会被删除并重新生成。

Umi 在 .umirc.ts 或 config/config.ts 中配置项目和插件，支持 es6。一份常见的配置如下，

配置文件

推荐在 .umirc.ts 中写配置。如果配置比较复杂需要拆分，可以放到 config/config.ts 中，并把配置的一部分拆出去，比如路由。

两者二选一，.umirc.ts 优先级更高。

TypeScript 提示

如果你想在写配置时也有提示，可以通过 umi 的 defineConfig 方法定义配置，

import { defineConfig } from 'umi';
export default defineConfig({
  routes: [
    { path: '/', component: '@/pages/index' },
  ],
});

运行时配置

运行时配置和配置的区别是他跑在浏览器端，基于此，我们可以在这里写函数、jsx、import 浏览器端依赖等等，注意不要引入 node 依赖。

约定 src/app.tsx 为运行时配置。

patchRoutes({ routes })

路由

在 Umi 中，应用都是单页应用，页面地址的跳转都是在浏览器端完成的，不会重新请求服务端获取 html，html 只在应用初始化时加载一次。所有页面由不同的组件构成，页面的切换其实就是不同组件的切换，你只需要在配置中把不同的路由路径和对应的组件关联上。

配置路由

在配置文件中通过 routes 进行配置，格式为路由信息的数组。

export default {
  routes: [
    { exact: true, path: '/', component: 'index' },
    { exact: true, path: '/user', component: 'user' },
  ],
}

wrappers

配置路由的高阶组件封装。

比如，可以用于路由级别的权限校验：

export default {
  routes: [
    { path: '/user', component: 'user',
      wrappers: [
        '@/wrappers/auth',
      ],
    },
    { path: '/login', component: 'login' },
  ]
}

然后在 src/wrappers/auth 中，

export default (props) => {
  const { isLogin } = useAuth();
  if (isLogin) {
    return <div>{ props.children }</div>;
  } else {
    redirectTo('/login');
  }
}

这样，访问 /user，就通过 useAuth 做权限校验，如果通过，渲染 src/pages/user，否则跳转到 /login，由 src/pages/login 进行渲染。

Link 组件

import { Link } from 'umi';
export default () => (
  <div>
    <Link to="/users">Users Page</Link>
  </div>
);

然后点击 Users Page 就会跳转到 /users 地址。

Link 只用于单页应用的内部跳转，如果是外部地址跳转请使用 a 标签
路由组件参数

路由组件可通过 props 获取到以下属性，

• match，当前路由和 url match 后的对象，包含 params、path、url 和 isExact 属性
• location，表示应用当前出于哪个位置，包含 pathname、search、query 等属性
• history，同 api#history 接口
• route，当前路由配置，包含 path、exact、component、routes 等
• routes，全部路由信息

export default function(props) {
  console.log(props.route);
  return <div>Home Page</div>;
}

传递参数给子路由

通过 cloneElement，一次就好（Umi 2 时需要两次）。

import React from 'react';
export default function Layout(props) {
  return React.Children.map(props.children, child => {
    return React.cloneElement(child, { foo: 'bar' });
  });
}

约定式路由

除配置式路由外，Umi 也支持约定式路由。约定式路由也叫文件路由，就是不需要手写配置，文件系统即路由，通过目录和文件及其命名分析出路由配置。

动态路由

约定 [] 包裹的文件或文件夹为动态路由。

src/pages/users/[id].tsx 会成为 /users/:id
src/pages/users/[id]/settings.tsx 会成为 /users/:id/settings


  └── pages
    └── [post]
      ├── index.tsx
      └── comments.tsx
    └── users
      └── [id].tsx
    └── index.tsx

会生成路由配置，

[
  { exact: true, path: '/', component: '@/pages/index' },
  { exact: true, path: '/users/:id', component: '@/pages/users/[id]' },
  { exact: true, path: '/:post/', component: '@/pages/[post]/index' },
  {
    exact: true,
    path: '/:post/comments',
    component: '@/pages/[post]/comments',
  },
];

嵌套路由

Umi 里约定目录下有 _layout.tsx 时会生成嵌套路由，以 _layout.tsx 为该目录的 layout。layout 文件需要返回一个 React 组件，并通过 props.children 渲染子组件。

页面跳转

声明式

通过 Link 使用，通常作为 React 组件使用。

import { Link } from 'umi';
export default () => (
  <Link to="/list">Go to list page</Link>
);

命令式

通过 history 使用，通常在事件处理中被调用。

import { history } from 'umi';
function goToListPage() {
  history.push('/list');
}

也可以直接从组件的属性中取得 history

export default (props) => (
props.history.push(‘/list’);}>Go to list page
);

配置模板

模板里可通过 context 来获取到 umi 提供的变量，context 包含：

route，路由信息，需要打包出多个静态 HTML 时（即配置了 exportStatic 时）有效
config，用户配置信息

<link rel="icon" type="image/x-icon" href="<%= context.config.publicPath % />favicon.png" />

Mock 数据

Mock 数据是前端开发过程中必不可少的一环，是分离前后端开发的关键链路。通过预先跟服务器端约定好的接口，模拟请求数据甚至逻辑，能够让前端开发独立自主，不会被服务端的开发所阻塞。

约定式 Mock 文件

Umi 约定 /mock 文件夹下所有文件为 mock 文件。

├── mock
    ├── api.ts
    └── users.ts

/mock 下的 api.ts 和 users.ts 会被解析为 mock 文件。

编写 Mock 文件

如果 /mock/api.ts 的内容如下，

export default {
  // 支持值为 Object 和 Array
  'GET /api/users': { users: [1, 2] },
  // GET 可忽略
  '/api/users/1': { id: 1 },
  // 支持自定义函数，API 参考 express@4
  'POST /api/users/create': (req, res) => {
    // 添加跨域请求头
    res.setHeader('Access-Control-Allow-Origin', '*');
    res.end('ok');
  },
}

然后访问 /api/users 就能得到 { users: [1,2] } 的响应，其他以此类推。

全局样式

Umi 中约定 src/global.css 为全局样式，如果存在此文件，会被自动引入到入口文件最前面。

启用按需加载

常见使用场景：组件体积太大，不适合直接计入 bundle 中，以免影响首屏加载速度。例如：某组件 HugeA 包含巨大的实现 / 依赖了巨大的三方库，且该组件 HugeA 的使用不在首屏显示范围内，可被单独拆出。这时候，dynamic 就该上场了。

为了简化部署成本，按需加载功能默认是关闭的，你需要在使用之前先通过配置开启，

export default {
  dynamicImport: {},
}

使用按需加载

为什么使用 dynamic：封装了使用一个异步组件需要做的状态维护工作，开发者可以更专注于自己的业务组件开发，而不必关心 code spliting、async module loading 等等技术细节。

封装一个异步组件

import { dynamic } from 'umi';
export default dynamic({
  loader: async function() {
    // 这里的注释 webpackChunkName 可以指导 webpack 将该组件 HugeA 以这个名字单独拆出去
    const { default: HugeA } = await import(/* webpackChunkName: "external_A" */ './HugeA');
    return HugeA;
  },
});

使用异步组件

import React from 'react';
import AsyncHugeA from './AsyncHugeA';
// 像使用普通组件一样即可
// dynamic 为你做:
// 1. 异步加载该模块的 bundle
// 2. 加载期间 显示 loading（可定制）
// 3. 异步组件加载完毕后，显示异步组件
export default () => {
  return <AsyncHugeA />;
}

如何判断当前页面是 SSR 还是 CSR？

查看网页源代码，如果

服务端渲染（SSR）

https://www.jianshu.com/p/10b6074d772c
什么是服务端渲染？
服务端渲染（Server-Side Rendering），是指由服务侧完成页面的 HTML 结构拼接的页面处理技术，发送到浏览器，然后为其绑定状态与事件，成为完全可交互页面的过程。
通过SSR 方式的页面：白屏时间上 SSR 较少，因为当 HTML 文档返回时，已经有对应的内容。（见 Network）
综上两图可知，SSR 常用于以下两个场景：
有 SEO 诉求，用在搜索引擎检索以及社交分享，用在前台类应用。
首屏渲染时长有要求，常用在移动端、弱网情况下。
也就是说，如果你是中后台应用（如 antd pro、管理后台等），请谨慎考虑是否使用 SSR。

什么是预渲染？

服务端渲染，首先得有后端服务器（一般是 Node.js）才可以使用，如果我没有后端服务器，也想用在上面提到的两个场景，那么推荐使用预渲染。
预渲染与服务端渲染唯一的不同点在于渲染时机，服务端渲染的时机是在用户访问时执行渲染（即实时渲染，数据一般是最新的），预渲染的时机是在项目构建时，当用户访问时，数据不是一定是最新的（如果数据没有实时性，则可以直接考虑预渲染）。
预渲染（Pre Render）在构建时执行渲染，将渲染后的 HTML 片段生成静态 HTML 文件。无需使用 web 服务器实时动态编译 HTML，适用于静态站点生成。

Umi 服务端渲染特性

Umi 3 结合自身业务场景，在 SSR 上做了大量优化及开发体验的提升，具有以下特性：

• 开箱即用：内置 SSR，一键开启，umi dev 即 SSR 预览，开发调试方便。
• 服务端框架无关：Umi 不耦合服务端框架（例如 Egg.js、Express、Koa），无论是哪种框架或者 Serverless 模式，都可以非常简单进行集成。
• 支持应用和页面级数据预获取：Umi 3 中延续了 Umi 2 中的页面数据预获取（getInitialProps），来解决之前全局数据的获取问题。
• 支持按需加载：按需加载 dynamicImport 开启后，Umi 3 中会根据不同路由加载对应的资源文件（css/js）。
• 内置预渲染功能：Umi 3 中内置了预渲染功能，不再通过安装额外插件使用，同时开启 ssr 和 exportStatic，在 umi - build 构建时会编译出渲染后的 HTML。
• 支持渲染降级：优先使用 SSR，如果服务端渲染失败，自动降级为客户端渲染（CSR），不影响正常业务流程。
• 支持流式渲染：ssr: { mode: ‘stream’ } 即可开启流式渲染，流式 SSR 较正常 SSR 有更少的 TTFB（发出页面请求到接收到应答数据第一个字节所花费的毫秒数） 时间。
• 兼容客户端动态加载：在 Umi 2 中同时使用 SSR 和 dynamicImport（动态加载）会有一些问题，在 Umi 3 中可同时开启使用。

• SSR 功能插件化：Umi 3 内置的 SSR 功能基本够用，若不满足需求或者想自定义渲染方法，可通过提供的 API 来自定义。

  页面级数据获取

  每个页面可能有单独的数据预获取逻辑，这里我们会获取页面组件上的 getInitialProps 静态方法，执行后将结果注入到该页面组件的 props 中，例如：
  getInitialProps 中有几个固定参数：
  match： 与客户端页面 props 中的 match 保持一致，有当前路由的相关数据。
  isServer：是否为服务端在执行该方法。
  route：当前路由对象
  history：history 对象

  配置层

  Umi 3 在配置层做了大量精简，以下修改以字母排序，便于查找。

• 删除 browserslist，和 targets 重复了

• 删除 babel，基本用不上
• 修改 cssLoaderOptions 命名为 cssLoader
• 删除 cssLoaderVersion，只保留 css-loader@2 的版本
• 删除 cssPublicPath，css 引用的资源文件用相对路径 ./ 可满足所有场景，没有必要再配
• 删除 disableGlobalVariables，始终无全局变量，无需配置
• 删除 disableRedirectHoist，始终不再做 redirect hoist
• 删除 disableCSSModules 和 cssModulesWithAffix，Umi 3 自动识别 css modules 的使用，无需配置
• 删除 extraBabelIncludes 和 es5ImcompatibleVersions，node_modules 也走 babel 编译后就没有意义了，无需配置
• 修改 history 格式为 { type, options } ，不再支持 string 格式
• 修改 lessLoaderOptions 命名为 lessLoader
• 删除 minimizer，只保留 terserjs
  修改 plugins 的格式为字符串，需要先确保依赖的插件是否升级到 Umi 3，然后修改方式参考前面 umi-plugin-react 的修改方式
• 删除 sass，不再支持，后续会以插件的方式提供
• 删除 treeShaking，已内置，无需配置
• 删除 tsConfigFile，没有必要
• 删除 typescript，TypeScript 编译交给 babel 处理后，之前 ts-loader 的配置就没有意义了
• 删除 uglifyJSOptions，没有必要
• 删除 urlLoaderExcludes，没有必要

  前端请求流程

  在 Ant Design Pro 中，一个完整的前端 UI 交互到服务端处理流程是这样的：
  UI 组件交互操作；
  调用 model 的 effect；
  调用统一管理的 service 请求函数；
  使用封装的 request.ts 发送请求；
  获取服务端返回；
  然后调用 reducer 改变 state；
  更新 model。