从fullscreen谈谈前端开发

927 阅读6分钟

每当脑袋里蹦出一个idea,我都会快速记下来,备忘录+1的常规操作,慢慢的发现就仅仅的是记下来,后来的后来我改成打草稿的形式。对我来说,草稿箱里存放的草稿,和被放在购物车里面的商品一样,总有想清空的欲望,要么被删除,要么被发布。总之,它不再是它了。

image.png

而人又很奇怪,关于本篇,最初的草稿想写一篇关于fullscreen的功能介绍,发现太缺乏营养。思来想去,不如由此来展开谈谈对前端开发的理解,也算对得起你花费在阅读文章上的5分钟。

需求描述

有这样的功能需求:

  1. 有一个大盒子,盒子本身有个全屏按钮;

  2. 盒子里面放了很多卡片(或者理解成容器,面板都可以),卡片上有全屏按钮;

  3. 大盒子全屏后,盒子里的卡片还可以继续全屏;

  4. 点ESC全部退出全屏,点按钮,按顺序依次退出全屏。

我已经写好了,功能示例看这里

image.png

需求分析

和我们常见的全屏不一样,需求的特殊点是,需要同时支持两个元素的依次全屏。

设计实现

这里我们回溯一下,把历史回退到16年,在当时的浏览器背景下,解决这个问题。

我也写好了,把Tab页签切换到【早期API示例

我们要解决的问题还有点复杂,早期的Fullscreen API实现会把这些事件发送给document,而不是调用的元素,所以我们只能让document.body全屏,来保证整个过程中全屏事件流程的准确响应。通过模拟全屏样式(.custom-fullscreen)的方式实现“看起来的”全屏效果,同时定义LIFO栈存储全屏元素,并注意全屏api的浏览器兼容性。

120+行的源码在这github链接

2021-05-14 15.19.11.gif

然而

a3d097fbb3e85d2b44d692fd71fdad66.jpeg

我们现在不用这么麻烦,封装一下的操作都用不着,现代浏览器Document强大的API早已经解决这些问题,我们先看源码,简直不要太幸福,省事省力又省心。(为了少些几个字,请允许我直接上图片,说不允许的,点个赞再走)

image.png

image.png

你说什么?什么爱情都会变,现在又穷又没钱。

  • 不用特别考虑兼容性
  • 不需要自定义容器栈,浏览器内部维护了全屏元素栈
  • 不需要自定义class,提供了伪类:fullscreen
  • 还有伪元素::backdrop

我又写好了,把Tab页签切换到【最新API示例

同时提供了:fullscreen和::backdrop的示例

2021-05-14 16.01.58.gif

全文结束

库的价值是为了解决其在当下的问题,考虑问题要想想它出现的背景。很多时候,我们不够理解为什么当时竟然那么设计,这是没有加上背景的提问。

事儿没变,是时代变了。

‘‘ ‘‘

’’ ’’

到此,结束!

0d9d9aeaf9d278169fa4c84248851efd.jpeg

还有谈谈前端开发呐

欺骗用户工程师

把前端工程师称为欺骗用户工程师更形象一些,我们在做的很多事都是欺骗用户的感情 眼睛,像前面的模拟全屏,等待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 较难,与新启项目没啥区别

没用的代码及时淘汰,不要相信今天注释,明天就会移除注释这样的鬼话。

如何提升自己

关于这点,仁者见仁智者见智。

万变不离基础,把基础知识点掌握牢固,深挖吃透,后面是盖楼、造火箭还是搭窑洞,都用的到。

保持对技术的敏感度。

保持对前端的热爱。

保持对自我代码的吐槽和不断优化,给队友一个美好的明天。

持续学习,新的技术,新的思想,有机会就多实践,敲几回能够更快速的帮助我们记忆与理解。

如何看待团队规范,技术规范,视觉规范

制定规范的本质是解决效率问题,通常意义上,满足产品功能的需要,解决实际问题。

规范不会让每个人满意,没有对错分别,只要团队遵守同一个标准就可以。

再论学不动

前端变化太快,要不要学,跟不上,学不动的问题

入行时,就应该有这个认知力,就应该接受这个事实。况且没有什么学不动,只是不够耐心罢了。

没有人天生很笨,是你自己觉得你很笨,并且还深信不疑。

结束语

e58cf16fadf04727b1dce0d19fd882f2.jpeg