每当脑袋里蹦出一个idea,我都会快速记下来,备忘录+1的常规操作,慢慢的发现就仅仅的是记下来,后来的后来我改成打草稿的形式。对我来说,草稿箱里存放的草稿,和被放在购物车里面的商品一样,总有想清空的欲望,要么被删除,要么被发布。总之,它不再是它了。
而人又很奇怪,关于本篇,最初的草稿想写一篇关于
fullscreen
的功能介绍,发现太缺乏营养。思来想去,不如由此来展开谈谈对前端开发的理解,也算对得起你花费在阅读文章上的5分钟。
需求描述
有这样的功能需求:
-
有一个大盒子,盒子本身有个全屏按钮;
-
盒子里面放了很多卡片(或者理解成容器,面板都可以),卡片上有全屏按钮;
-
大盒子全屏后,盒子里的卡片还可以继续全屏;
-
点ESC全部退出全屏,点按钮,按顺序依次退出全屏。
我已经写好了,功能示例看这里
需求分析
和我们常见的全屏不一样,需求的特殊点是,需要同时支持两个元素的依次全屏。
设计实现
这里我们回溯一下,把历史回退到16年,在当时的浏览器背景下,解决这个问题。
我也写好了,把Tab页签切换到【早期API示例】
我们要解决的问题还有点复杂,早期的Fullscreen API实现会把这些事件发送给document,而不是调用的元素,所以我们只能让document.body全屏,来保证整个过程中全屏事件流程的准确响应。通过模拟全屏样式(.custom-fullscreen)的方式实现“看起来的”全屏效果,同时定义LIFO栈存储全屏元素,并注意全屏api的浏览器兼容性。
120+行的源码在这github链接
然而
我们现在不用这么麻烦,封装一下的操作都用不着,现代浏览器Document强大的API早已经解决这些问题,我们先看源码,简直不要太幸福,省事省力又省心。(为了少些几个字,请允许我直接上图片,说不允许的,点个赞再走)
你说什么?什么爱情都会变,现在又穷又没钱。
- 不用特别考虑兼容性
- 不需要自定义容器栈,浏览器内部维护了全屏元素栈
- 不需要自定义class,提供了伪类:fullscreen
- 还有伪元素::backdrop
我又写好了,把Tab页签切换到【最新API示例】
同时提供了:fullscreen和::backdrop的示例
全文结束
库的价值是为了解决其在当下的问题,考虑问题要想想它出现的背景。很多时候,我们不够理解为什么当时竟然那么设计,这是没有加上背景的提问。
事儿没变,是时代变了。
‘‘ ‘‘
’’ ’’
到此,结束!
还有谈谈前端开发呐
欺骗用户工程师
把前端工程师称为欺骗用户工程师更形象一些,我们在做的很多事都是欺骗用户的感情 眼睛,像前面的模拟全屏,等待loading,轮播图,跑马灯,面包屑等等太多例子,还不是因为我们善于挖掘这些优点
- 解决问题的技巧,技术在于解决问题,产品的价值才是技术的价值。
- 看清事务的本质
- 良好的用户体验
保证代码更新频度
如何看待这样的问题,引用的npm包更新很快,产品上应该怎么做,是否要及时更新同步?webpack构建工具动不动就升级,项目环境要不要跟进?vite来了,我们要替换吗?typescript很香,我们啥时候用起来?
看它是否能解决你的什么问题。
能给你带来收益的,就跟上,在恰当的时机选择恰当的方式。
比如有大版本上线的迭代,就可以适当升级各种npm包,因为有足够充分的时间进行测试和bug修复,而小版本迭代的过程中,尽量不要瞎搞,保证产品功能的稳定才是收益点,相信你也不想别人睡觉的时候你在敲bug。步子也不要太大,稳中求胜。干事之前想好退路,一旦出现不可预测问题,能够做到快速回滚或者问题修复。
webpack升级的事,推荐保持使用最新稳定版。我们有个长期迭代的产品,最初使用的webpack2.6.1(当时的最新版就是2.6.1),随着功能的增多,代码量上升,各种效率明显跟不上,启动慢,热更新,打包都跟不上,对于开发效率严重影响。毫不犹豫的就跟进到3.0版本,然后又是一波操作猛如虎,调整配置loader,plugin,tree shaking代码优化等。后来4.x来了,又是一波操作,再后来是5.x。保证代码库不断更新的另外一个好处是,便于后续产品的升级。
webpack4.x -> webpack 5.x 相对容易
webpack2.x -> webpack 5.x 较难,与新启项目没啥区别
没用的代码及时淘汰,不要相信今天注释,明天就会移除注释这样的鬼话。
如何提升自己
关于这点,仁者见仁智者见智。
万变不离基础,把基础知识点掌握牢固,深挖吃透,后面是盖楼、造火箭还是搭窑洞,都用的到。
保持对技术的敏感度。
保持对前端的热爱。
保持对自我代码的吐槽和不断优化,给队友一个美好的明天。
持续学习,新的技术,新的思想,有机会就多实践,敲几回能够更快速的帮助我们记忆与理解。
如何看待团队规范,技术规范,视觉规范
制定规范的本质是解决效率问题,通常意义上,满足产品功能的需要,解决实际问题。
规范不会让每个人满意,没有对错分别,只要团队遵守同一个标准就可以。
再论学不动
前端变化太快,要不要学,跟不上,学不动的问题
入行时,就应该有这个认知力,就应该接受这个事实。况且没有什么学不动,只是不够耐心罢了。
没有人天生很笨,是你自己觉得你很笨,并且还深信不疑。