React一線問題十問十答
最近在開源中國搞了個問答活動，收到了不少網友關於React的提問，本文挑選出一些比較典型的問題總結一下，對問答感興趣的同學可以移步這裡
問答
問：React如何快速的入手，有什麼學習方法推薦的嗎？
答：快速上手的話，建議閱讀一些入門教程，比如阮一峰老師的部落格，接下來要實踐一下，比如簡單實現一個小程式，接下來就是在學習和實踐中迴圈了
另外React的官網是非常不錯的資料，主要作用可用來查閱資料，如果入門了以後，想要對React有深入的瞭解，可以關注下我的新書《 React狀態管理與同構實戰 》
問：問一下React和Vue的區別？React和Vue等框架未來的發展趨勢？
答：關於React和Vue的區別網上有大把大把的資料，這裡就不展開回答了，簡單來說Vue是MVVM框架，React是一個View層的抽象解決方案
我認為未來React和Vue會長期並存，都會有很多的工作機會，其實在React和Vue之前，框架也是多個並存的情況，另外個人建議不要太侷限於框架，在我看來一個功能用Vue和用React來實現，並沒有太大的開發效率上的區別
從開發效率和學習成本來看，未來可能會出現更高效的情況，但從原理上來說，要顛覆現在框架的原理，可能需要很長時間的發展
框架都是用來解決具體問題的，未來不會再出現一個新的react了，顛覆react的一定不是react的效仿者，目前來看react能夠堅持很久，但是react也有很多不適合的場景，比如動畫就非常不友好，前端框架的發展方向應該是圍繞解決問題，提升效率來的
問：現在框架很多，原始的js這些還沒學完，React跟vue這些已經鋪天蓋地了，而且框架性的東西會要求大家按照他們的語法或者邏輯來做，對於新人重新開始可能沒問題，對於老手來說切換的成本大，容易出錯，是否有好的辦法？
答：我對於框架的態度一直是工作中用到了才回去真正學習，否則不會去深入瞭解，所以面對繁多的新技術不要畏懼，要感到高興，因為這才能證明前端在發展，另外如果原始js還沒學完，怎麼能自稱為老手？
框架只是改變了UI的寫法，元件的寫法，其實涉及到邏輯部分，都還是原生的js，所以原生js和框架兩個都要學好； 現在前端工程師必須有很強的學習能力，不能面向技術程式設計，而是要面向解決問題程式設計，不管什麼技術，只要能解決問題就是好的，否則一個技術展被淘汰了，還是要被迫的去學習
我現在覺得更大的學習壓力是對於新手的，而不是老手的，老手其實只要學一個框架就好了，新手要學的東西遠比老手多，所以現在前端的入門越來越難了
問：剛好最近也在學習React，也接觸了Redux這個狀態管理工具，對於React的設計思想稍微有了些自己的理解——精簡而又複雜，複雜指的是很容易“過度設計”，顯得整個專案有點臃腫龐大，對於這個問題，有沒有什麼元件設計建議呢？
答：React中一切都是基於元件，但是元件的粒度確認一個問題，到底是該每個按鈕設計一個元件，無比細粒度呢？還是很大模組的組粒度呢？
我覺得對於不同場景，應該有不同的設計理念，對於元件庫，那麼應該設計的竟可能細粒度，這樣才能方便組合； 對於業務程式碼，則不應該設計得過細，會浪費精力，也不宜過大，過大了維護起來也是個問題，還是老規矩，每個元件不要超過300行挺好
問：怎麼正確的理解React的生命週期呢?
答：每一個軟體都會誕生和死亡的一天，React元件也有自己的生命週期，每一個React元件都會經歷出生、存在和消亡的過程，在React的世界裡，這三個生命週期被稱為，掛載（Mounting）、更新（Updating）和解除安裝（Unmounting）
React為每個過程提供了一些回撥函式，稱作鉤子函式，讓我們可以自定義一些事情，如果想了解更多的內容，可以關注下我的新書《 React狀態管理與同構實戰 》
問：React在什麼時候比較適合SSR呢？
答：React再有node中間層的時候比較適合做SSR，其實是否SSR應該是業務決定的，比如如果你需要做SEO那你就需要SSR，比如新聞網站，內容類網站；對於不需要SEO的系統，比如後端系統，webapp，都是不需要SSR的
想了解更多SSR的內容，可以關注我的新書
問：1、React在表單處理上有沒有比較好的解決方案？目前在一些複雜的表單處理上，需要些大量的handleXXXChange方法，Vue中的v-model要簡單許多。此外還有表單校驗，包括antd在內的ui框架，在這方面的處理都顯得相當複雜，不易維護。
2、在render中使用箭頭函式和bind都是不推薦的，但是對於列表遍歷中傳遞當前物件：
{items.map((item, index) => (
<li onClick={(e) => this.handleItemClick(e, item, index)}>
{item.title}
</li>
)}
如果不使用箭頭函式，有什麼比較好的解決方案嗎？
答：
- 可以寫一個babel外掛，給react擴充套件v-model的功能哈
- 表單校驗，也可以封裝一些高階函式吧
- 在原生標籤的函式中，使用bind或者剪頭函式沒什麼問題哈，或者可以把值放到dom屬性中，這樣的效能還不如多一個函式快
問：react redux 怎麼處理多執行緒文件,管理多個請求併發問題?
你怎麼看待這種用worker的方式啟動新執行緒的?
var worker = new Worker(js file path);
答：js中是沒有多執行緒的，但是卻可以做到請求併發，如果想要多個請求都返回時才處理，可以使用Promise.all
在有密集計算，又不希望卡頓主執行緒的情況下，原來只能用setTimeout分片，現在可以用worker了，這種方式非常棒，有實際的使用場景
問：做技術選型如何考量react在開發應用的優略？學習成本？也就是說react實際技術落地的技術點？
答：這其實就是技術選型的問題，我將回答react到底適合什麼場景，技術棧是否應該統一
如果你的頁面互動比較簡單，其實使用react，並不能比使用jq提升多少效率，對於這種業務，用不用react是無所謂的； 如果你的頁面是面向c端的頁面，並且需要做seo，那麼就要掂量掂量了，因為你使用react的話就需要使用ssr了
對於一個團隊來說技術棧肯定是統一更好的，但是還是要看業務是否統一，因為面向c端的和麵向內部的系統不統一也可以； 如果你的頁面僅僅是內部系統，那麼選擇react+antdesign是非常好的選擇； 如果你的業務是面向c端的，然後頁面又比較簡單那麼react就不是必須的了，也不是最好的選擇； 如果你的頁面有面向c端的，也有面向內部的，我認為是可以保持兩套技術棧的； 兩套技術棧就意味著浪費效率，基建可能要做兩套，這也是一個問題
所以要綜合考慮，結合業務場景，如果你個團隊同時存在jq和react是可以接收的，但同時存在react和vue就是不能接受的了
總結
本文都是網友反饋的問題，包括React入門進階，React具體細節，技術選型等，如果你也有疑問，歡迎在評論區交流，最後給大家推薦幾本不錯的React書籍
- React狀態管理與同構實戰 我的新書，React入門與進階首選
- React全棧 非常不錯React進階書籍
- 深入React技術棧 深入理解，適合深入閱讀
原文網址：
React一線問題十問十答最後推薦下我的新書《React 狀態管理與同構實戰》，這本書由我和前端高階技術專家@Lucas HC 合力打磨，凝結了我們在學習、實踐 React 框架過程中的積累和心得
為大家準備了 限量簽名版 ，可指定寄語，附贈小驚喜，想要的同學可以私信我@顏海鏡
不想要簽名版的同學可以通過京東購買
《React狀態管理與同構實戰》(侯策，顏海鏡)【摘要 書評 試讀】- 京東圖書最後最後在容我打一個小廣告：號外號外：美團招聘前端，客戶端，後端啦！地點：北京，上海，成都！！！，感興趣的同學可以私信我@顏海鏡