umi

什么是UMI

它是由dva的开发者云谦编写的一个新的React开发框架。它既是一个框架也是一个工具。简单的理解可以称它为一个类 next.js 的专注性能的前端框架。通过约定、自动生成和解析代码等方式来辅助开发，减少开发者要写的代码量。 umi是通用方案，几乎适用于现在所有的web环境。
Umi，中文可发音为乌米，是可扩展的企业级前端应用框架。Umi 以路由为基础的，同时支持配置式路由和约定式路由，保证路由的功能完备，并以此进行功能扩展。然后配以生命周期完善的插件体系，覆盖从源码到构建产物的每个生命周期，支持各种功能扩展和业务需求。

umi的优势在哪里

umi是一个类next.js的专注性能的前端框架，它的优势是：

• 内置的大量性能优化
• 多端，无缝支持容器和浏览器访问
• 类 webpack 的插件机制
• 针对 antd 和 dva 有友好的支持 之前在使用官方脚手架create-react-app的时候你不光需要了解react的知识还需要懂得redux、react-router，初学者在结合这些知识的时候是很困难的。而UMI是结合了目前市面上流行的dva状态管理工具和文件即路由的方式来开发项目。什么是文件即路由呢？那就是你在page下新建了文件，UMI会自动帮你生成配套的路由

umi 具有以下功能

• 🎉 可扩展，Umi 实现了完整的生命周期，并使其插件化，Umi 内部功能也全由插件完成。此外还支持插件和插件集，以满足功能和垂直域的分层需求。
• 📦 开箱即用，Umi 内置了路由、构建、部署、测试等，仅需一个依赖即可上手开发。并且还提供针对 React 的集成插件集，内涵丰富的功能，可满足日常 80% 的开发需求。
• 🐠 企业级，经蚂蚁内部 3000+ 项目以及阿里、优酷、网易、飞猪、口碑等公司项目的验证，值得信赖。
• 🚀 大量自研，包含微前端、组件打包、文档工具、请求库、hooks 库、数据流等，满足日常项目的周边需求。
• 🌴 完备路由，同时支持配置式路由和约定式路由，同时保持功能的完备性，比如动态路由、嵌套路由、权限路由等等。
• 🚄 面向未来，在满足需求的同时，我们也不会停止对新技术的探索。比如 dll 提速、modern mode、webpack@5、自动化 external、bundler less 等等。

  umi的可扩展性

  作者称“umi有着类webpack般灵活的插件机制，他就是一个架子”。 主要的umi项目，甚至不到700行代码（629行），把骨架搭好，把框架的生命周期钩子暴露出来，然后通过插件让功能丰富起来（包括现有的内部逻辑也是这么实现的）。 我却更喜欢把它形容为一个高达玩具，对于刚入手的玩家，可以根据说明书，一步一步的组装出自己心爱的玩具。而对于高玩来说，官方提供了一个骨架，保证了高达的可动性，然后你自己可以随意的DIY，任意的使用材料和设计方式。 对于umi也是相同，对于刚接触前端的朋友，你可以很好的完成公司的业务需求。对于对前端有一定了解的朋友，你可以随意的修改，包括配置、编译、开发、模板、请求方式、数据流等等，几乎所有你能想到的前端工程化的内容，都允许你自定义。并且在一步步接触这些可配置项的时候，你也对前端工程化有了一步步的认识和理解。

  umi的性能

  对于项目性能方面，UMI也做了很多的优化，包括尺寸，执行效率，首屏加载时间，用户体验等等方面，但这些对于开发者其实是无感知的，可以说有时候你就升级了一下插件版本，你的整个项目就优化了，你根本不需要进行任何的多余操作。作者称“你只管写业务代码，我会负责性能，并且随着umi的迭代，我保证你的应用会越来越快”。 简单的说，umi做到了开箱即用，对于开发者和前端初学者是非常友好的。

  为什么不用CRA (creat-react-app)

create-react-app 是基于 webpack 的打包层方案，包含 build、dev、lint 等，他在打包层把体验做到了极致，但是不包含路由，不是框架，也不支持配置。所以，如果大家想基于他修改部分配置，或者希望在打包层之外也做技术收敛时，就会遇到困难。

.umi 临时文件

.umi 临时目录是整个 Umi 项目的发动机，你的入口文件、路由等等都在这里，这些是由 umi 内部插件及三方插件生成的。
你通常会在 .umi 下看到以下目录，

• .umi
  • core # 内部插件生成
  • pluginA # 外部插件生成
  • presetB # 外部插件生成
  • umi.ts # 入口文件

临时文件是 Umi 框架中非常重要的一部分，框架或插件会根据你的代码生成临时文件，这些原来需要放在项目里的脏乱差的部分都被藏在了这里。
你可以在这里调试代码，但不要在 .git 仓库里提交他，因为他的临时性，每次启动 umi 时都会被删除并重新生成。

关于umi 项目的目录结构

.
├── package.json
├── .umirc.ts
├── .env
├── dist
├── mock
├── public
└── src
├── .umi
├── layouts/index.tsx
├── pages
├── index.less
└── index.tsx
└── app.ts

package.json

包含插件和插件集，以 @umijs/preset-、@umijs/plugin-、umi-preset- 和 umi-plugin- 开头的依赖会被自动注册为插件或插件集。

.umirc.ts

配置文件，包含 umi 内置功能和插件的配置。有config/config.ts文件配置时，将该文件删除

.env

环境变量。

比如：

PORT=8888
COMPRESS=none

dist 目录

执行 umi build 后，产物默认会存放在这里。

mock 目录

存储 mock 文件，此目录下所有 js 和 ts 文件会被解析为 mock 文件。

public 目录

此目录下所有文件会被 copy 到输出路径。

/src 目录

.umi 目录

临时文件目录，比如入口文件、路由等，都会被临时生成到这里。不要提交 .umi 目录到 git 仓库，他们会在 umi dev 和 umi build 时被删除并重新生成。

layouts/index.tsx

约定式路由时的全局布局文件。

pages 目录

所有路由组件存放在这里。

app.ts

运行时配置文件，可以在这里扩展运行时的能力，比如修改路由、修改 render 方法等。

配置文件

如果项目的配置不复杂，推荐在 .umirc.ts 中写配置； 如果项目的配置比较复杂，可以将配置写在 config/config.ts 中，并把配置的一部分拆分出去，比如路由配置可以拆分成单独的 routes.ts：

// config/routes.ts
export default [
    { exact: true, path: '/', component: 'index' },
];
// config/config.ts
import { defineConfig } from 'umi';
import routes from './routes';
export default defineConfig({
  routes: routes,
});

推荐两种配置方式二选一，.umirc.ts 优先级更高.

运行时配置

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

配置方式

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

路由

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

配置路由

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

约定式路由

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

如果没有 routes 配置，Umi 会进入约定式路由模式，然后分析 src/pages 目录拿到路由配置。