预览模式: 普通 | 列表

vite2+vue2.6.12+vant2.12.12提速移动端开发

 试着用网上的一个vite2的脚手架做了个移动端的尝试。vite最大的好处就是--真的快!也可能是我页面比较少,但是每次热更新,基本就是一存盘,浏览器就完成了变更,体验太好了。

换新脚手架,要把所有常用配置都验证一下,并且把原来webpack中的选项都做到在vite中等价实现。

包括:

* px2rem的解决方案,在postcss.config.js中配置,转化为vw单位,比rem方式要先进点。

* vant基础样式定义,在theme.less中。

* lodash及moment全局引入,在/index.html中直接用<script>标签引入的,在vue文件中和.js中直接可用,但是在.ts文件中,如果不做import,会有红色的错误波浪线出现,但不影响使用。

* import后缀为vue的组件时,必须带上vue后缀,但js/ts不用带后缀。

* 有时候大的变化要CTRL+F5强制刷新页面,热更新才会生效。

* 图片引入方式:

<img :src="require('@img/aaa.png')" />

background-image: url("@img/aaa.png");

* 静态资源在/public目录下,在页面中用/images这样的路径引入即可。

* webpack允许的require在此都不能用,要改为import。写法方面,@import "~@/assets/less/_variable.less" vite中要去掉~写成:@import "@/assets/less/_variable.less";

* 控制台过滤。vite会出现一些控制台输出,暂时没有配置方法屏蔽,折中办法,在控制台搜索框输入-vite,可以过滤掉这些输出。

* 运行命令与环境变量。跟webpack略有不同。运行方式看package.json就知道了。环境变量可放在.env.development这样的文件中,跟webpack一致。在所有代码中输出import.meta.env,可以看到环境变量的所有。具体看文档。

 

我本人对于vue3和ts不是很熟悉(学不动了),所以宁愿工作在vue2+js的环境中。在vite脚手架中,这两种方式是可以混用的。所以按自己合适的模式使用就行了。

 

放心去享受vite带来的快速体验吧!

分类:VUE研究 | 固定链接 | 评论: 0 | 引用: 0 | 查看次数: 2616

本次YT项目的一些收获

今年4月1号开始在YT公司参与一个商业管理系统的开发,担任前端开发,跟十几个同事一起工作了二个月时间。

到今天项目已经基本告一段落。写写心得。

一是业务理解能力和抗压能力比较重要。项目刚开始时,碰到比较复杂的逻辑,我心理上有犹豫及抗拒,总觉得理解起来很吃力。尤其是在工期压力下,有时会感到头脑一片空白。
比如第一期开发阶段,需要构造一个自定义的日历。我跟后端同事小刘商量,由他来写算法,我前端只负责渲染。我坦承自己并不擅长日期算法。小刘却认为这个日期运算应该由前端的我来负责,我们两个互不相让,产生了一点分歧。后来组长曾工主动承揽了此算法,他花了较少的时间完成了,解决了这个小矛盾。
后来随着项目的进展,我才逐渐发现项目中有大量的日期运算。我查查文档、问问同事,不知不觉也熟练了这项技能。到二个月后的今天,项目没那么紧张了,我又系统地读了一下moment.js的文档,发现自己居然熟练了大多数常用方法,于是试着重新写一下那个日历,结果只用了大约1小时,就完成了。---这真是一个神奇的变化,也是我此次项目的第一个收获,就是提升了自己面对复杂情况的心理阀值。
 
二、项目进度跟踪。 开发团队有比较成熟的进度管理,每天做了几个页面,调试成功几个接口,都要登记在文档中,早会时组长点评。这样挺好,每个人都会按照工期推进,减少项目风险。我跟其它前端同事的分工也逐渐默契,互相取长补短。
 
三、松散的分工模式。拿前端来说,几个前端同事其实是各写各的,没有公用的规范,也没有共同的JS工具和CSS片段。你愿意怎么写就怎么写,愿意放哪个目录就放哪个目录,只要最终页面逻辑能跑通。--我开始面对这个事实有点吃惊,但后来发现也没啥大问题。这样减少了团队磨合成本,VUE本身的模块化方式,也避免了变量冲突和样式冲突。这样做的缺点,就是每个人的“埋头工作”有时候是重复劳动,写了一大块儿,发现别人早就写过相同的代码了。
另外,有些同事的前端代码效能比较差,对于我这样的"老师傅"来说,总觉得这样做缺乏“工匠精神”,但是事实上并不影响最终使用。将来万一出了问题,会有人去改这些“差代码”,但至少不是我。
当然,这里面少不了梁工这位熟悉全局的神人,他凭一己之力,写了很多公共代码块,经常第二天上班被他告知,几个页面被加上了某个代码块。这家伙简单高效地把帮我们把代码升级了。
 
确实,有些业务逻辑,讲一遍太麻烦,还不如直接帮着写了来得爽快。这种搞法,也适合于我们这种快组快闪的团队。
 
四、隐患。项目交工后,还是要提炼经验,并把一些公共建筑搭建好。比如我们这个项目,我觉得可以固定下一些公共配置及工具,把环境变量的最佳实践方法整理好,写成文档,等等。
当然,我参与的很多外包项目,本来就是雇佣军,打一枪换个地方,成员不固定。既然成员不固定,沉淀经验也就无从谈起。最劳神的,还是公司的留守老员工,象老母亲一样把旧项目缝缝补补,案牍劳形。
 
我自己这次收获颇丰:熟练了GIT操作,深入了VANT组件库,加强了moment运算。最大的收获,是了解了5人以上协作开发的一些普遍做法。
 
当然,团队中坚的年轮人,为了项目做出艰苦赴出:连贯一二个月加班,有人身体出现不适,也还在坚持工作。深夜时他们还在钉钉上提BUG、凌晨时全组人测试跨天逻辑、每天中午所有人都趴在桌上午睡。每当看到这些,我都觉得IT人的谋生不易。

对我这样一个老同志来说,能保证每天按时下班,每天搞搞锻炼,每天中午能在自己的折叠床上小睡一个午觉,真是千金不易的人生甘甜。
分类:开发心得 | 固定链接 | 评论: 0 | 引用: 0 | 查看次数: 2598