从fullscreen谈谈前端开发

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

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

需求描述

有这样的功能需求：git

有一个大盒子，盒子自己有个全屏按钮；github
盒子里面放了不少卡片（或者理解成容器，面板均可以），卡片上有全屏按钮；web
大盒子全屏后，盒子里的卡片还能够继续全屏；typescript
点ESC所有退出全屏，点按钮，按顺序依次退出全屏。npm

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

需求分析

和咱们常见的全屏不同，需求的特殊点是，须要同时支持两个元素的依次全屏。浏览器

设计实现

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

我也写好了，把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 较难，与新启项目没啥区别
复制代码

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

如何提高本身

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

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

保持对技术的敏感度。

保持对前端的热爱。

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

持续学习，新的技术，新的思想，有机会就多实践，敲几次可以更快速的帮助咱们记忆与理解。

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

制定规范的本质是解决效率问题，一般意义上，知足产品功能的须要，解决实际问题。

规范不会让每一个人满意，没有对错分别，只要团队遵照同一个标准就能够。

再论学不动

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

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

没有人天生很笨，是你本身以为你很笨，而且还深信不疑。