“有客戶投訴,說在刪除指定的某條記錄時,結果刪掉的卻是另外一條記錄!”
看起來是個很嚴重的BUG。 有一次我們在工作中碰到了這個問題。 要定位這個BUG非常麻煩, 因為客戶也不清楚如何重現這個問題。
後來發現這個Bug是由於在 ng-repeat 中使用了 $index 引發的。下麵一起來看看這個錯誤是如何引發的, 以及如何避免這種bug產生,然後說說我們從中得到的經驗和教訓。
一個簡單動作(action)的串列
先來看看一個完整有效的ng-repeat示例。
- {{item.name}}
對應的控制器(controller)如下:
app.controller(‘ListCtrl’, [‘$scope’, function($scope) {
//items come from somewhere, from where doesn’t matter for this example
$scope.items = getItems();
$scope.remove = function(index) {
var item = $scope.items[index];
removeItem(item);
};
}]);
看起來沒什麼問題,對嗎? 這段程式碼也沒有任何特別值得註意的。
新增一個過濾器(filter)
然後,讓我們來做一個小小的修改: 給串列新增一個過濾器。 這是很常見的做法,如果串列很長的話,例如允許使用者進行搜尋。
為了方便起見, 假設我們透過 searchFilter 來查詢串列中的記錄。
- {{item.name}}
控制器的程式碼保持不變。 看起來仍然沒有問題,是吧?
事實上,有一個bug藏在裡面。 如果我不說, 你能找到嗎? 如果能找到,你就已經是Angular大牛了.
請儘量不要使用 $index
BUG其實是在控制器裡面:
$scope.remove = function(index) {
var item = $scope.items[index];
removeItem(item);
};
這裡使用了 index引數, 然後就遇到了BUG: 過濾後的索引(indexs)不匹配原始串列的索引。
幸運的是,有一個很簡單的方法來避免這種問題: 不要使用$index,而改成實際的item物件。
- {{item.name}}
控制器如下所示:
$scope.remove = function(item) {
removeItem(item);
};
註意, 這裡將 remove($index) 改成 remove(item), 並修改了 $scope.remove 函式來直接操作傳過來的物件。
這個小小的修改就完全避免了剛才的BUG。
為了更好地說明問題以及解決方案,請參考 interactive example 。
從中可以學到什麼?
第一個教訓當然是在使用 $index 要小心一點,因為以某些方式使用時很可能會產生BUG。
第二個教訓是,請記住類似這樣的樣式,則可以用更好的做事方式,可以完全避免某些型別的BUG。 我強烈建議大家現在不要使用 $index, 從這種簡單的思維轉變中,就可以減少程式碼中的很多BUG。
第三個教訓是測試並不是什麼時候都有用。 即便有自動化測試,也改寫了足夠多的情形, 但對於依賴特定輸入的情況,也很容易錯過某些BUG。 錯誤本身並不是每次都會出現,即使你也用過濾來測試。
第四個教訓是不要破壞抽象 —— 這一點很容易被忽略。理論上 $index 是由 ng-repeat 建立的一個 “模板變數(template variable)”。 這隻在 repeat 塊裡面有意義(並正確起作用)。 當我們將它的值傳遞到外面時,它就失去了背景關係從而不再有效。 如果確實想讓它在 repeat 之外依然有效,則必須在控制器中也進行過濾,這就需要一些不是很必要的重覆程式碼。 值得慶幸的是本文中介紹的樣式可以用來避免這種情況。
GitHub版:https://github.com/cncounter/translation/blob/master/tiemao_2015/04_ng_repeat_%24index/ng_repeat_%24inde
原文出處:www.sitepoint.com
譯文出處:伯樂線上 – douxingxiang
連結:http://web.jobbole.com/82459/