key是react唯一乙個用來分辨子元素的標識。如果我們動態建立子react元素，而且這些子元素的順序或者數量不確定的時候，那麼就需要使用key這個屬性。
key的使用允許react來分辨哪些元素改變了，哪些是增加的，那些被刪除了。在元素陣列中，key應該被賦予給每個元素，從而每個元素都有乙個穩定的身份證明。
可能會造成渲染錯誤我之前做了乙個2048的小遊戲，但是在移動的時候，總是會出現跳的現象：
可能會出現資料的錯誤舉個例子，目的是可以在最上方增加輸入行：
export default class list extends react.component ;
} insert = ()=>);
} render()
}export default class item extends react.component ;
} onchange = (e)=>)
} render() : );
}}
key值，會造成乙個bug:
由上面的gif中可以看到，原來在input 2裡面輸入的值變成input 3的值了，這是為什麼？
由於沒有使用key，造成react靠順序來判斷子元素，所以就造成了input 2的元素，修改props成input 3，而原本裡面存著的state並沒有發生變化，所以就顯示的是input 3的輸入域裡面顯示著原本input 2的值。
同理，input 1變成了input 2，然後又重新生成了乙個input 1.
而如果我們使用了key，
render()react就會很容易的辨別子元素，會變成下面這個樣子，就不會造成上面的錯誤了：
就像之前的那個例子裡所展示，不加key可能會造成更多的渲染。
我們在item裡面加乙個shouldcomponentupdate的判斷：
shouldcomponentupdate(nextprops, nextstate)value和state不改變的時候，不會呼叫re-render。
我們可以通過react performance tool的perf來看一下渲染次數的對比。
首先，我們增加幾個功能reverse(調轉),insert(插入到第乙個)和delete(刪除第乙個)
其次，我們規定的步驟是1. insert 2.insert 3.reverse 4.delete，來看一看渲染的次數
下面是列印的結果：
沒有使用key
使用key
對比效果很明顯，沒有使用key的時候，render了14次。而使用key的時候，只render了2次(2次insert)。中間的差別很大，時間也差很多。
看了這篇文章發現了乙個很有趣的用法.
按照作者所說，如果同乙個元件，如果要修改其中的一些props會造成很多資料重新計算，可能會寫很多判斷邏輯，有的時候還是不如直接重新全部刪除重新計算。
有的時候你想要銷毀和重建元件，觸發componentdidmount方法，重置state。那麼就可以使用key這個屬性。當你要銷毀、重建元件的時候，你就可以通過改變key值來達到這個目的。
排版有點亂。。。我會繼續修改
以上
不能再忽略技術了
自己是很喜歡搞技術的，身上的很多特點也決定了我是比較適合搞技術的。一直以來我也比較喜歡鑽研。但最為乙個技術應用者。不懂管理或者不懂業務，也不能更好的應用技術來實現較好的效果。所以便慢慢的開始涉足一些業務領域學習。當然也取得了一些效果。感覺自己的綜合能力有了提高。不過最近閱讀了一些 技術大拿 blog...
不能更改map 中key的屬性
根據前面兩篇的介紹，我們知道了hashmap底層存放和查詢元素的方式，因此得出了不能更改map 中key值的屬性 當然是指重寫了equals和hashcode的情況下 還是使用前面的address類 public static void main string args 更改了屬性值之後當前存放的k...
list為什麼不能作為字典的key
list為什麼不能作為key 至於這個問題，最直接的答案就是 list沒有支援 hash 方法，那麼為什麼呢？對於list的hash函式，我們可能有下面兩種實現的方式 第一種，基於id。這滿足條件，如果hash值不同，那麼他們的id當然不同 但考慮到list一般是作為容器，基於id來hash可能會導...