《深刻淺出React和Redux》讀書筆記一

• 使用React.createClass是一種過期的方法
• React 判斷一個元素是HTML元素仍是React組件的原則就是看第一個字母是否大寫
• 在HTML中直接寫onclick一直就是爲人詬病的寫法，網頁應用開發界一直倡導的是用jQuery的方法添加事件處理函數，直接寫onclick會帶來代碼混亂的問題
• 既然長期以來不倡導在HTML中使用onclick，爲何在React的JSX中咱們卻要使用onClick這樣的方式來添加事件處理函數呢？
• 之前使用HTML來表明內容、用CSS表明樣式、用JavaScript來定義交互行爲，這三種語言分在三種不一樣的文件裏面，其實是把不一樣的技術分開管理了，而不是邏輯上的"分而治之"
• 根據作同一件事的代碼應該有高耦合性的設計原則，既然咱們要實現一個Click-Counter，那爲何不把實現這個功能的全部代碼集中在一個文件裏呢？

• 即便如今，咱們仍是要說在HTML中直接使用onclick很不專業，緣由以下：

  • onclick 添加的事件處理函數是在全局環境下執行的，這污染了全局環境，很容易產生意料不到的後果；
  • 給不少DOM元素添加onclick事件，可能會影響網頁的性能，畢竟，網頁須要的事件處理函數越多，性能就會越低；
  • 對於使用onclick的DOM元素，若是要動態地從DOM樹中刪除的話，須要把對應的事件處理器註銷，若是忘了註銷，就可能形成內存泄漏，像這樣的Bug很難被發現
  • 上述的這些問題，在JSX中都不存在

• 由於

  • JSX中一個組件使用了onClick，並無直接使用onclick的HTML，而是使用了事件委託(event delegation)的方式處理事件，不管有多少個onClick出現，其實最後都只在DOM樹上添加了一個事件處理函數，掛在最頂層的DOM節點上；
  • 全部的點擊事件都被這個事件處理函數捕獲，而後根據具體組件分配給特定函數，使用事件委託的性能固然要比爲每一個onClick都掛載一個事件處理函數要高；
  • 由於React控制了組件的生命週期，在unmount的時候天然可以清楚相關的全部事件處理函數，內存泄漏也再也不是一個問題；
• 選取一些DOM元素，而後對這些元素作一些操做，這是一種最容易理解的開發模式；jQuery的發明人John Resig就是發現了網頁應用開發者的這個編程模式，才創造出了jQuery，其一問世就受到廣泛承認，由於這種模式直觀易懂。可是，對於龐大的項目，這種模式會形成代碼結構複雜，難以維護，每一個jQuery的使用者都會有這種體會
• 用React開發的ClickCounter組件並無像jQuery那樣作"選中一些DOM元素而後作一些事情的動做"

打一個比方，React是一個聰明的建築工人，而jQuery是一個比較傻的建築工人，開發者你就是一個建築的設計師，若是是jQuery這個建築工人爲你工做，你不得不事無鉅細地告訴jQuery「如何去作」，要告訴他這面牆要拆掉重建，那面牆上要新開一個窗戶，反之，若是是React這個建築工人爲你工做，你所要作的就是告訴這個工人「我想要什麼樣子」，只要把圖紙遞給React這個工人，他就會替你搞定一切，固然他不會把整個建築拆掉重建，而是很聰明地把此次的圖紙和上次的圖紙作一個對比，發現不一樣之處，而後只去作適當的修改就完成任務了。
顯而易見，React的工做方式把開發者從繁瑣的操做中解放出來，開發者只須要着重「我想要顯示什麼」，而不用操心「怎樣去作」。
這種新的思惟方式，對於一個簡單的例子也要編寫很多代碼，感受像是用高射炮打蚊子，可是對於一個大型的項目，這種方式編寫的代碼會更容易管理，由於整個React應用要作的就是渲染，開發者關注的是渲染成成什麼樣子，而不用關心如何實現增量渲染。
React的理念，歸結爲一個公式，就像下面這樣：
UI＝render（data）
讓咱們來看看這個公式表達的含義，用戶看到的界面（UI），應該是一個函數（在這裏叫render）的執行結果，只接受數據（data）做爲參數。這個函數是一個純函數，所謂純函數，指的是沒有任何反作用，輸出徹底依賴於輸入的函數，兩次函數調用若是輸入相同，獲得的結果也絕對相同。如此一來，最終的用戶界面，在render函數肯定的狀況下徹底取決於輸入數據。