不見的Function Name

在某日時，被指派查看一個Bug，第一步驟當然是打開本地端的開發環境囉~

但神奇的事情發生了，在上線的產品中的Bug卻不能夠照著同樣的步驟reproduce。

當時第一個念頭想的就是，該不會兩者版本不一致吧，但是在經過比較後發現是一致。

於是又仔細看了一次整個邏輯，發現在本地端跑出來的結果的確是我們預期的。

只好在本地端Build出Production環境的檔案，直接用http-server跑起來，賓果!

Bug成功出現，所以接下來比對之後發現Bug是出現使用Function name這個功能。

1
2
3
4
5

const a = function test() {
    .....
}
console.log(a.name)
//

在dev環境的時候會如我們預期的印出name(也就是test)，但是在Prod環境的時候

卻發現name變成另一個名字。於是範圍縮小到在Webpack打包的時候。在看過整個

打包流程之後發現最有嫌疑的應該就是uglifyjs這邊，於是查看文檔之後果然看到

有這個選項。

1
2

--keep-fnames               Do not mangle/drop function names.  Useful for
                                code relying on Function.prototype.name.

在uglifyjs的時候，會把Function的名稱給替換掉，達到壓縮的效果，所以如果

Code裡面有依賴function.name這種用法的時候，記得要確保任何最佳化Js的工

具不會把名稱搞掉。但相對應的，打包過後的體積也會相對應增加一些，所以在

經過取捨之後，最後還是決定把原本的寫法更改，不調整設定了!

Reference

MDN

Resilient CSS - CSS瀏覽器相容最佳化

在前端開發上，調整CSS往往是讓人頭痛的事情，主要原因是因為各家瀏覽器對CSS的實作展現方式都不一，或者是因為瀏覽器版本沒有辦法支持現有的CSS語法。而以下有幾種做法可以用來幫助解決這些問題。

1.使用 can I use來搜尋特定的CSS語法在各家瀏覽器的支援度，所以當看到想要使用新的語法時請先來這個網站查詢相容度避免大多數的用戶無法使用!

2.但當你看到一個新的語法覺得不試試看不行的話又該如何是好呢? CSS是一行一行被執行，所以當瀏覽器看到不支持的CSS語法的時候，會直接略過不執行，而且後面的會覆蓋前面的屬性。

1
2
3
4

.test {
	display: inline-block;
	display: grid;
}

所以依上面這種情況的話，當瀏覽器是同時支援inline-block&grid的時候就會顯示grid，但在其他不支持grid的瀏覽器上只會呈現inline-block，所以可以把優先希望顯示的屬性放在較後面

3.用第二種寫法的話長期來看會造成Code很難維護，這時候可以使用@supports來判斷該瀏覽器是否支援

1
2
3
4
5
6
7

@supports (display: 100vh) {
  // 支援vh的瀏覽器
}
@supports not (height: 100vh) {
  // 不支援vh的瀏覽器
}

這樣對於後續維護工作也清楚許多，但是假如遇到連supports都不支援的瀏覽器，最後的寫法可以變這樣

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

/*共用樣式(給連supports都不支援的瀏覽器)*/
.test{
	 /* some style */
}
@supports (height: 100vh) {
  // 支援vh的瀏覽器
  .test{
	  /* some style */
  }
}
@supports not (height: 100vh) {
  // 不支援vh的瀏覽器
  .test{
	  /* some style */
  }
}

Reference

Resilient CSS