主角是誰
在今天這篇文章中，我并不會在這里講一些移動端視口的概念，包括物理像素和邏輯像素，理想視口，dpr等等等等，我只介紹這樣一種非常不錯的移動端適配方案：post-css-to-viewport，如果我說這種方案能解決98%以上的移動端布局痛點，我想整個掘金，應該沒有人會反駁，
痛點在哪里
在之前有一種流行已久的移動端適配方案，那就是rem，我想下面這兩句代碼，有不少老移動端都不會陌生：
const deviceWidth = document.documentElement.clientWidth || document.body.clientWidth;
document.querySelector('html').style.fontSize = deviceWidth / 7.5 + 'px';
沒錯，在那個移動端UI稿尺寸為750*1334滿天飛的時代，這兩句代碼確實給開發者帶來了很大的方便，這樣設定根font-size后，px和rem的轉換比例成了100, 為比如UI稿一個長寬分別為120px*40px，那么開發者對應的寫成1.2rem*0.4rem就可以了
這種換算已經是頗為方便，但是并非所有的專案都能這樣去設定一個方便換算的比例系數，當比例系數為100時，小數點往前面挪兩位就行了，然而有的專案設定的換算系數千奇百怪，有50的，有16的，很多已經嚴重超出口算力所能及的范疇了，所以后來誕生的px-to-rem或者px2rem就是為了解決這個問題
人們希望有這樣一種方案...
- 首先，無論換算方不方便，我都不想換算（就是這么懶??），我也不想去操心什么轉換系數
- 其次，有些屬性或者類選擇器我不想進行轉換
- css代碼要足夠簡潔，我只希望看到一種單位，那就是px
兩種方案都很好，但我偏愛后者
第一種方案是lib-flexible+postcss-pxtorem，在相當長一段時間里，這兩個插件搭配都是解決移動端布局的神器，lib-flexible是阿里手淘系開源的一個庫，用于設定font-size，同時處理一些視窗縮放的問題，其中一位主要貢獻者正是阿里的大神winter，
直到2020年的今天，我仍然可以說，lib-flexible+postcss-pxtorem是解決移動端布局的主流，但是我們可以好好想一想，它是否有什么不足？
從我個人來說，我認為它主要有以下兩個不足：
- 兩個插件需要配套使用，而且rootValue設定的值不好理解
- rem是相對于html元素字體單位的一個相對單位，從本質上來說，它屬于一個字體單位，用字體單位來布局，并不是太合適
翻閱其github地址，可以看到這樣一段有意思的話：
第二種方案是viewport，postcss-px-to-viewport就是這樣一款優秀的插件，它解決了以上提到的痛點，也滿足以上提到的理想要求，它將px轉換成視口單位vw，眾所周知，vw本質上還是一種百分比單位，100vw即等于100%，即window.innerWidth
在vue專案中引入試試
- 我們先把它安裝到專案的開發環境中：
npm i postcss-px-to-viewport -D
- 在專案根目錄下添加
.postcssrc.js檔案 - 添加如下配置：
module.exports = {
plugins: {
autoprefixer: {}, // 用來給不同的瀏覽器自動添加相應前綴，如-webkit-，-moz-等等
"postcss-px-to-viewport": {
unitToConvert: "px", // 要轉化的單位
viewportWidth: 750, // UI設計稿的寬度
unitPrecision: 6, // 轉換后的精度，即小數點位數
propList: ["*"], // 指定轉換的css屬性的單位，*代表全部css屬性的單位都進行轉換
viewportUnit: "vw", // 指定需要轉換成的視窗單位，默認vw
fontViewportUnit: "vw", // 指定字體需要轉換成的視窗單位，默認vw
selectorBlackList: ["wrap"], // 指定不轉換為視窗單位的類名，
minPixelValue: 1, // 默認值1，小于或等于1px則不進行轉換
mediaQuery: true, // 是否在媒體查詢的css代碼中也進行轉換，默認false
replace: true, // 是否轉換后直接更換屬性值
exclude: [/node_modules/], // 設定忽略檔案，用正則做目錄名匹配
landscape: false // 是否處理橫屏情況
}
}
};
- 重新運行專案，使組態檔生效
- 我們寫一段測驗代碼來驗證一下：
<template>
<div class="test-viewport">測驗轉換</div>
</template>
<style lang="less" scoped>
.test-viewport {
width: 750px;
height: 100px;
font-size: 40px;
text-align: center;
line-height: 100px;
background: #13b5b1;
}
</style>
- 打開控制臺，可以看到已經進行了轉換
需要注意的配置
propList: 當有些屬性的單位我們不希望轉換的時候，可以添加在陣列后面，并在前面加上!號，如propList: ["*","!letter-spacing"],這表示：所有css屬性的屬性的單位都進行轉化，除了letter-spacing的selectorBlackList：轉換的黑名單，在黑名單里面的我們可以寫入字串，只要類名包含有這個字串，就不會被匹配，比如selectorBlackList: ['wrap'],它表示形如wrap,my-wrap,wrapper這樣的類名的單位，都不會被轉換
關于兼容第三方UI庫
當然，當我們引入一些第三方庫的時候，比如vant，上面配置的exclude去掉，表示全部內容進行vw轉換，會遇到這樣的問題：
像這個TabBar，變得非常的小，被壓扁了，
其實vant官網也是給出了關于viewport的適配方案，在github找一個名為vant-demo的專案，可以看到其配置如下：
很尷尬，vant團隊的是根據375px的設計稿去做的，理想視口寬度為375px，
那么，我們是否也要叫UI重新出一版375px的設計稿？
或者，我們在書寫的程序心算一下，所有標注的尺寸都除以2？
讓我們回到webpack本身，重新看一下這份.postcssrc.js檔案，它除了暴露一個物件，也可以暴露一個函式，無論暴露什么，在webpack運行時，都會被我們配置的海量檔案讀取并執行，
暴露函式有一個好處，可以拿到webpack運行的當前執行檔案的資訊，
那么我們可以有這樣一個思路：如果讀取的是vant相關的檔案，viewportWidth就設為375，如果是其他的檔案，我們就按照我們UI的寬度來設定viewportWidth，即750，
改寫.postcssrc.js檔案配置如下：
const path = require('path');
module.exports = ({ file }) => {
const designWidth = file.dirname.includes(path.join('node_modules', 'vant')) ? 375 : 750;
return {
plugins: {
autoprefixer: {},
"postcss-px-to-viewport": {
unitToConvert: "px",
viewportWidth: designWidth,
unitPrecision: 6,
propList: ["*"],
viewportUnit: "vw",
fontViewportUnit: "vw",
selectorBlackList: [],
minPixelValue: 1,
mediaQuery: true,
exclude: [],
landscape: false
}
}
}
}
注意：這里使用path.join('node_modules', 'vant')是因為適應不同的作業系統，在mac下結果為node_modules/vant，而在windows下結果為node_modules\vant
重新運行后發現，不僅vant相關組件的單位被轉換成了vw，而且其比例也是完全正確的，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qiye/47755.html
標籤：Html/Css