爲什麼要用react，react的原理是什麼：
衆所周知react所強調的組件化開發，什麼是組件化開發，例如我們的這個球星競拍，我們需要從後臺獲取到球星的列表，然後遍歷拼接渲染到真實dom上，父組件負責的任務就是獲取到後臺傳遞過來的json數據，作爲有狀態組件，將json數據設置爲state的屬性，然後通過props傳遞給子組件，而子組件根據父組件傳遞的props值來進行遍歷渲染，在這個過程中父組件只需要負責接收json數據然後將數據發給子組件即可，父組件不需要管是用什麼方法渲染的，而子組件呢，可以看成就是一個函數，而props就是父組件調用子組件傳遞的參數，我不需要管你傳遞過來的參數是什麼，我只需要將你傳遞過來的props參數循環展示就可以，因爲我所接收的參數是父組件給我的，那麼如果渲染不出來原因肯定就是出在了父組件傳遞的props參數有問題了，所以說父組件需要保證的就是數據沒有問題，子組件需要保證的就是渲染的過程沒有問題。
所以父組件只需要負責保證設置的state值，並且將state值通過props傳遞給子組件，而子組件只需要根據props值去渲染，各司其職這也就是面向對象開發了。當數據發生變化時，父組件通過setState修改state的值，然後重新調用render方法（react機制如此），將新的props值重新傳給子組件，子組件根據新的props值進行遍歷拼接之後將數據結構返給父組件，父組件通過react的diff算法將render方法新生成的虛擬dom與已經渲染的真實dom進行對比，將發生改變的dom進行修改，在這個過程中，父組件所承擔的事情就是重新設置state的值，根本不需要管是怎麼渲染的，而子組件從始至終所負責的就是根據父組件傳遞過來的props值進行渲染展示，原始數據和子組件一點關係都沒有，父組件傳給我什麼，那我就渲染什麼，這也就是組件式開發了。
那麼這個過程和狀態管理有什麼關係嗎？其實一點都沒有...如果你僅僅是這麼簡單的一個功能的話，那用到狀態管理真的就是脫褲子放屁多此一舉。但是仔細看我們的截圖，我們在球星卡牌下面還有一個競拍的按鈕，這個按鈕肯定也是通過子組件渲染出來的，所以當你點擊競拍按鈕時，這個事件肯定是觸發在子組件上的，但是子組件只是一個純函數，所有數值發生變化的事情我們都放在父組件中去處理（別問爲什麼...如果你在子組件裏面處理的話，那你還不如用jQuery直接操作dom來的方便，那也就不是組件化開發了），那父組件怎麼知道狀態發生改變了呢？這就需要子組件去通知父組件了，常用的做法是在父組件中編寫一個函數，然後通過props的屬性傳給子組件，當子組件有需要發生變化的參數時，通過自身的函數方法調用父組件中的編寫的函數將發生改變的狀態作爲參數傳遞過去，而父組件根據傳遞過來的參數進行setState操作，步驟也就是上面所說的過程了。這才僅僅是父子組件，你就會發現已經很繞了，然而在實際開發中我們可能會有孫子組件，曾孫子組件，如果事件觸發是在曾孫子組件上，你可以想象一下會有多麼麻煩，曾孫子通知孫子，孫子通知兒子，兒子通知父親，父親收到需要改變的狀態之後進行setState然後通過props在傳遞給兒子 > 孫子 > 曾孫子根據新的props進行重新渲染，這個過程有多麼的麻煩顯而易見，所以在官網上也介紹react只是負責view層展示，這個麻煩的狀態事件你能忍受那你就用這種方式去通知修改，不能忍受那就需要藉助flux、Redux、mobx等框架進行管理。
所謂的狀態管理就是將可能發生變化的數據放到一個公共區域，就像以前的四合院，分別住着曾祖四輩，對應着東西南北四間房子，以前是父親通知隔壁兒子，兒子通知隔壁孫子這樣的順序去告知狀態發生變化，而藉助狀態管理的框架則會將可能發生變更的數據放到院子裏面，當發生變更的時候，只需要出門看一眼院子的數據大家就知道數據已經發生改變了，而不需要一家一家去通知了。
文中並不是在黑jquery，jquery同樣可以做到組件化開發，之所以現在流行vue、react、angular這三種框架，最主要的就是做到UI與數據保持同步，這是最關鍵的，我一直堅信如果jquery能夠支持雙向綁定的話，一定還會重回王座，這是一個使用了四年jquery前端開發堅持的信念。