前端開發注意的細節

此博文內容比較淺顯，可是就目前項目開發中，仍然發現這些細節被同窗們所忽略，寫此文權當給給同窗們作個引子，有則改之，無則加勉，作的更好的同窗請在文後作個評論，以供你們學習參考。

js設置默認值

在ES6以前，沒有設置默認值的語法，你們一般使用如下方式設置默認值：

function fn(num) {
    // 設置默認值
    num = num || 1;
    console.log(num);
}

可是問題在於，fn函數的參數num爲0、false、null、undefined、空字符串的時候，num都會被賦予1的默認值，顯然：傳參爲0時，並不是如咱們所願設置爲默認值1。

此時最好以一下判斷方式，來賦予默認值

function fn(num) {
    num = typeof num === 'undefined' ? 1 : num;
    console.log(num);
}

默認值，顧名思義，實在沒有給函數傳遞參數是，爲該參數默認的值，翻譯成js代碼，就是該參數爲undefined的時候，才使用該值。所以，以undefined爲目標來判斷相對比較科學，由於其餘幾個類型的數據，雖然，從其字面值上來說在某些時候確實能夠和undefined相等（==），可是從數據上來說，其實有實質內容的，也能夠說是佔有實際內存空間的，並不能和undefined徹底等價（===）。

多個條件並列

通常在業務比較複雜的地方，常常會出現多個條件並列的if語句，不少同窗的作法是多個條件表達式同是並列顯示一行，這樣執行起來固然沒有問題，可是很是不方便閱讀，編輯器沒有設置代碼自動換行，須要拖動很長的水平滾動條，等看完後面的條件，前面的也忘記的差很少了；也不符合每行不超過80個字符的編碼風格，而且若是配置了eslint等也會提示警告。

其實徹底能夠把多個條件，多行並列顯示，以下：

...
if(
    a === 1 &&
    b === 1 &&
    c === 1 ||
    ....
) {
    // do something
}
...

看上去很是清晰，每一個條件和上下文的關係也很容易閱讀記憶。

同理，在使用web component方式開發時，常常須要向組件傳遞一堆數據，如：

<Component data1={data1} data2={data1} data3={data3} data4={data4} data5={data5}  ... />

把不少數據傳遞寫到一行代碼中，一樣也會形成上述閱讀、記憶不便的問題，稍加改造，分行編寫，就好清晰不少，如：

<Component
    data1={data1}
    data2={data1} 
    data3={data3} 
    data4={data4}
    data5={data5} 
    ...
/>

模板語言縮進問題

如今不少項目使用mvvm的框架來開發，像AngularJS、RegularJS、VueJS都有其本身的模板系統，也自有一套語法規則，通常狀況下，模板語言都將會有處理條件分支的if-else語句，也有遍歷數據的each語句，在開發過程當中，有些同窗爲了體現html的結構，在編寫if-else和each語句是，不縮進其下層代碼，如(模板語法參考RegularJS)：

<div>
    {#each list as item}
    <span>{item}</span>
    {/each}
</div>

有部分同窗，可能爲了體現div和span父子關係，在<span>標籤所在行，並無進行層級縮進，上述代碼只有一層each語句，看起來，還能接受，可是若是再加上條件判斷，如：

<div>
    {#each list as item}
    {#if item < 10}
    <span>小於10的數字：{item}</span>
    {#else}
    <span>小於10的數字：{item}</span>
    {/if}
    {/each}
</div>

一眼看上去，each和if-else攪和在一塊兒，可讀性特別差。從我理解來講，組件模板中，不知能只注意html的結構，由於除了html，邏輯處理也是咱們表達程序目的內容，若是將只爲了程序html結構，致使代碼可讀性不好，代碼總體交給不明瞭，無疑會增長代碼維護成本。特別是對於患有強迫症的程序員，眼裏根本容不得一個多餘的空格，哪怕是在行尾，也要將其幹掉。

我推薦的模板代碼格式，邏輯塊（each、if、else等）和組件標、html標籤層級分明，對於邏輯要輸出的內容一目瞭然。如：

<div>
    {#each list as item}
        {#if item < 10}
            <span>小於10的數字：{item}</span>
        {#else}
            <span>小於10的數字：{item}</span>
        {/if}
    {/each}
</div>

能夠考慮使用一些數據結構

最初學習編程的時候，老師就說：程序設計=數據結構+算法，不事後來在業務開發中，不多去直接使用數據結構和算法，這些東西都被編程語言封裝過了，可是少用並不表明不用，特別是當下雲計算、大數據、人工智能這些技術的星期必然算法密不可分，扯的有點遠了，其實在平常業務開發中，若是能留意仍是能發現一些數據結構的應用場景的。

如二叉樹進行排序、尋找臨界值（最大、最小值），若是有這方面的需求也能夠考慮；還有隊列，在開發買票業務是有排隊場景的時候也能夠用上。還有其餘數據結構，如堆、棧也有其運用的場景。

以前，在開發某個業務系統，有個前端的需求，須要對一個列表（數組）進行拖動排序，如：拖動A到B的位置，其過程是：第一步將A從列表中移除，第二步將A插入到B所在的位置。上述過程，看似簡單，若是純粹使用JS數組來處理的話，此處須要將數組元素A拿掉，A以後的元素向前移動；第二步，將A插入到B的位置，能夠分兩步，第一B包括以後的元素，向後移，而後把A放到B的位置，使用程序處理起來仍是比較複雜的，此處若是將該列表構形成一個鏈表，在移除和插入的位置，只須要修改目標位置的先後和目標元素的先後指針便可，運算次數會下降很多。

固然，數據比較的少的時候，JS數組的API就能簡單的處理，使用數據結構解決問題，有點大炮打蚊子的感受，可是我認爲仍是有必要的，數據是一個動態的東西，如今少將來未必少，好比上述中的需求的，後期列表元素的數量就上升到了幾百個。

局部loading

這個問題多是交互設計的問題，不過也能夠是前端問題。局部loading的名字是我本身起的，和其對應的是全局loading，在當下單頁應用橫行的時代，數據都是先後端分離，全部的數據都是用過ajax請求獲取，爲了交互贊成，不少系統在設計的時候，請求loading的過程都會彈出一個全局遮罩層上面有個loading圖標，在請求時屏蔽頁面上全部的操做，這就是我所謂的全局loading。而局部loading則與之相反，那個操做點發出的請求，只須要在對應的操做點上顯示loading便可如：點擊按鈕A，發送一個請求更新列表，只須要在按鈕A上面顯示loading或者loading的文案。

按照個人觀點是反對全部地方都使用全局loading的，由於這樣違背了異步請求的初衷，異步請求原本就是把請求過程放到後臺，不影響前臺的操做，等拿到響應數據，再把數據更新到前臺，而全局loading，把整個前臺界面所有屏蔽遮罩，沒法進行任何操做，好比：頁面滾動加載數據，此時頁面被全局loading屏蔽、遮擋，頁面內容不能完整查看，全部操做都收到限制，若是請求時間過長，體驗很不好。

XXS攻擊

關於XXS攻擊的內容，網上不少，也是平常web開發中常常要注意的一個安全問題，而且如今不少前端框架對此也有必定的而防範。我要說的，也是一個XXS相關且容易忽略的點：從頁面URL中獲取參數，並把參數的內容輸出到頁面上，好比，URL中有一個a參數，在前端代碼中，使用js直接獲取參數後，沒有經過XSS相關編碼的處理，直接或者間接的輸出到頁面上，此時a參數中含有JS腳本的代碼，就好形成腳本注入的安全隱患，開發過程當中，若是出現此場景仍是，要三思然後行。