從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 較難，與新啓項目沒啥區別
複製代碼

沒用的代碼及時淘汰，不要相信今天註釋，明天就會移除註釋這樣的鬼話。

如何提高本身

關於這點，仁者見仁智者見智。

萬變不離基礎，把基礎知識點掌握牢固，深挖吃透，後面是蓋樓、造火箭仍是搭窯洞，都用的到。

保持對技術的敏感度。

保持對前端的熱愛。

保持對自我代碼的吐槽和不斷優化，給隊友一個美好的明天。

持續學習，新的技術，新的思想，有機會就多實踐，敲幾次可以更快速的幫助咱們記憶與理解。

如何看待團隊規範，技術規範，視覺規範

制定規範的本質是解決效率問題，一般意義上，知足產品功能的須要，解決實際問題。

規範不會讓每一個人滿意，沒有對錯分別，只要團隊遵照同一個標準就能夠。

再論學不動

前端變化太快，要不要學，跟不上，學不動的問題

入行時，就應該有這個認知力，就應該接受這個事實。何況沒有什麼學不動，只是不夠耐心罷了。

沒有人天生很笨，是你本身以爲你很笨，而且還深信不疑。