共计 2874 个字符,预计需要花费 8 分钟才能阅读完成。
一. 如何在 Vue 或 React 我的项目中应用自定义字体
在开发前端我的项目时,常常会遇到 UI 共事心愿在我的项目中应用一个炫酷字体的需要。那么怎么在我的项目中应用自定义字体呢?
其实实现起来并不简单,能够借用 CSS3 @font-face 来实现。
本文着重介绍一下 webpack 我的项目如何正确打包引入的自定义字体。
@font-face 有什么用
总结一下就是:用户借助该规定,能够为引入的字体包命一个名字,并指定在哪里能够找到它(指定字体包的存储门路)后,就能够像应用通用字体那样去应用它了。
具体实现步骤
例如当初的需要是:须要在我的项目中应用 KlavikaMedium-Italic 字体。
则只需以下三个步骤即可。
1. 将字体包放入我的项目目录下
这里放到根目录下的 tool/fonts 文件夹里。
2. 在 index.css 文件中定义
@font-face {
font-family: 'myFont';
src: url(tool/fonts/KlavikaMedium-Italic.otf);
}
3. 应用自定义字体
新建一个 index.vue 文件,引入款式:
import './index.css'
<template>
<h1> 应用自定义字体 </h1>
<style>
h1 {font-family: 'myFont'}
</style>
</template>
成果如下:
二. webpack 我的项目如何正确打包自定义的字体
1. 打包时报错
既然在本地开发环境实现了成果,于是就应用 webpack 打包筹备上线,却发现 webpack 在打包过程中报错:
2. 打包时为什么会报错
咱们在定义自定义字体时应用 URL 指定了字体包的门路,因为 webpack 默认是无奈解决 css 中的 url 地址的,因而这里会报错。
3. 解决报错
3.1 意识 file-loader
这时就须要借助 loader 来大显神通了,解决这个问题须要应用 file-loader,它次要干了两件事儿:
- 依据配置批改打包后图片、字体包的寄存门路;
- 再依据配置批改咱们援用的门路,使之对应引入。
3.2 装置 file-loader
yarn add file-loader
3.3 配置 file-loader
在 webpack.config.js 中,配置 file-loader:
module.exports = {
module: {
rules: [
{
// 命中字体包
test: /.(woff2?|eot|ttf|otf)(?.*)?$/,
// 只命中指定 目录下的文件,放慢 Webpack 搜寻速度
include: [paths.toolSrc],
// 排除 node_modules 目录下的文件
exclude: /(node_modules)/,
loader: 'file-loader',
},
]
}
}
再次执行打包命令,不再报错。
4. 自定义字体为什么不失效
于是将打包进去的 dist 目录重新部署到服务器上后拜访页面,却发现因为找不到字体导致没有失效:
从图中能够看出,http 申请字体包的门路为:根目录下 (打包进去的动态文件 index.html 所在目录) 的 css/620db1b997cd78cd373003282ee4453f.otf。
4.1 字体不失效的起因
看了一下打包命令生成的 dist 目录构造:
├── 620db1b997cd78cd373003282ee4453f.otf
├── css
│ ├── backend.66a35.css
│ └── backend.66a35.css.map
├── favicon.ico
├── images
│ ├── bg.5825f.svg
│ ├── data-baseTexture.c2963.jpg
│ ├── data-heightTexture.6f50d.jpg
│ └── logo.7227a.png
├── index.html
└── js
├── backend.66a35.js
却发现,字体包和 index.html 是在同一级。因而字体无奈失效的起因就很清朗了:
- 因为 http 申请的字体包门路与理论的寄存门路统一,就导致了 404;
- 找不到字体包的理论门路,因而应用的字体无奈失效。
4.2 字体不失效的解决办法
能够通过批改字体包打包后的理论存储门路去解决这个问题,在 webpack.config.js 中,借助 options 参数能够持续给 file-loader 设置更多的配置项:
module.exports = {
module: {
rules: [
{
// 命中字体包
test: /.(woff2?|eot|ttf|otf)(?.*)?$/,
// 只命中指定 目录下的文件,放慢 Webpack 搜寻速度
include: [paths.toolSrc],
// 排除 node_modules 目录下的文件
exclude: /(node_modules)/,
loader: 'file-loader',
// 新增 options 配置参数:对于 file-loader 的配置项
options: {
limit: 10000,
// 定义打包实现后最终导出的文件门路
outputPath: 'css/fonts/',
// 文件的最终名称
name: '[name].[hash:7].[ext]'
}
},
]
}
}
再次打包,生成的 dist 目录构造如下:
├── css
│ ├── backend.66a35.css
│ ├── backend.66a35.css.map
│ └── fonts
│ └── KlavikaMedium-Italic.620db1b.otf
├── favicon.ico
├── images
│ ├── bg.5825f.svg
│ ├── data-baseTexture.c2963.jpg
│ ├── data-heightTexture.6f50d.jpg
│ └── logo.7227a.png
├── index.html
└── js
├── backend.66a35.js
能够看到字体包正如配置时预期的那样存储在 css/fonts 目录上面。
重新部署我的项目,再次查看:
这一次 http 申请的字体包门路与理论的寄存门路统一,因而自定义字体失效。
能够通过上面这个梳理流程图看的更分明一些:
三. 总结
为什么本地开发的时候能够看到字体,部署到服务器后却看不到了呢?
- 因为 webpack 我的项目在本地开发中应用的是 webpack-dev-server,实时编译后的文件都保留到了内存当中,援用字体包的时候应用的是绝对路径,因而在本地开发中应用的自定义字体可能失效;
- 应用 webpack 打包后的 dist 目录,字体包的理论存储门路与 http 申请字体包的门路不统一,因而导致找不到字体包;
- 借助 file-loader 解决 webpack 打包报错,通过应用 options 参数去设置字体包在打包后的理论存储门路,从而解决问题。
四. 更多文章
欢送拜访更多对于 webpack 系列的原创文章:
- webpack 系列之基本概念和应用
- webpack 系列之 loader 及简略的应用
- webpack 系列之 plugin 及简略的应用
关注微信公众号
欢送大家关注我的微信公众号浏览更多原创文章: