这是第一篇【偏门药方】,开篇简单介绍一下 -- 本栏目旨在记录平时遇到的稀奇古怪的场景以及解决方案,一般来说大家都是遇不上的,但是一旦遇上那就很容易让人汗流浃背,所以还是有必要记录一下滴。
背景
笔者接手了一个已投产项目,写了一个迭代发现,拿到的是375设计稿,但是写的时候像素怎么都对不上,一看vue.config.js里面,赫然写着414。考虑到马上就到冒烟阶段了,只好硬着头皮把之前375的像素都手动改回414。
后面盘了一下,组内其他项目都是375基准的,就这一个项目刚好被我碰上(该说运气好还是不好呢,既然只有它是异类,那我们肯定得要整改回去啦,万一后面再有同学踩坑就不好了,所以也就有了我们标题上的疑问 -- 页面的宽度基准选错了该怎么办?
方案
项目梳理及评估
因为是已经投产的项目,所以需要评估整改的工作量,看看是否能够在一个迭代周期内一次性整改完,如果无法整改完是否需要过渡方案。
梳理的流程很简单,因为项目本身的结构比较清晰,views目录里都是页面模板,components目录里面都是组件模板,我们只需要跑个脚本把所有文件都列出来即可,后面根据这个文件列表来预估工时以及摊派任务。
随着项目梳理的深入,惊奇的发现一个项目里面既有用414设计稿的页面,又有用375的页面,这基本就把脚本统一修改的路子堵死了。
也许大家会好奇,为啥这么离谱的事情在视觉走查的时候没看出来,因为真正在设备上看的时候是比较难察觉的,375的设计稿在414的基准下会偏小,但是是整个页面的等比变小,所以是很有可能会在视觉走查的时候被忽略的。
既然没法跑脚本批量变更那就只好手动调整了,工时评估其实也很简单,直接算vue模板的文件即可,每个模板大概一个工时可以调整完毕(模板有大有小,平均下来差不多就是一个工时)。
其中有些需要注意的坑
① 写在模板上的内联样式,这类样式一般是没有经过样式预处理的,调整的时候不要忽略这些地方,有可能的话最好都放在style标签里。
② 写在逻辑里的样式,同①,调整的时候不要忽略。
③ 特殊:414页面用了375组件 or 375页面用了414组件,如果有这种情况就尽量一次性改完涉及的组件或者页面,避免误导后续开发的同学;但其实这种情况是不会影响页面展示的,因为我们可以针对不同文件使用不同的转换基准。
过渡方案
笔者实际的落地情况是没有使用过渡方案的,我们专门抽出一个迭代来进行整改,将所有的页面组件都过了一遍。
那如果拆开多个迭代我们还能整改么?可以的,而且成本也不高,前提:使用的css预处理插件是postcss-px-to-viewport
(其他插件大概率也是可以的)。
因为postcss-px-to-viewport
可以配置include
和exclude
,所以我们可以将待整改的页面以及组件维护成一个文件列表,在414的基准配置中include
这个列表,而在375的配置中exclude
它们,这样一来新的页面我们都可以按375基准来开发,旧的页面则可以分期整改。
js
// vue.config.js
const pathArr = ['./src/views/test/index.vue'];
// ...
postcss: {
plugins: [
require("postcss-px-to-viewport")({
// ...
viewportWidth: 375,
exclude: pathArr
}),
require("postcss-px-to-viewport")({
// ...
viewportWidth: 414,
inclue: pathArr
}),
]
}
// ...
尾声
这确实是个很偏门的问题吧:),要是遇到了也没关系,通过预处理插件的重载我们可以让两种设计基准暂时性的共存,既然可以过渡,那后续自然就可以很轻松的排期完成错误基准模板整改。