如何學習一個框架

昨天我在一個羣裏有一個人在問，誰會 rxjs？我當時其實還有點好奇，對於 rxjs 我一直覺得很難，前陣子我也一直在研究。

Rxjs 我也一直覺得挺有用的，但是身邊用 rxjs 的朋友真的很少，我司的項目也是根本沒有。

所以我聽到有人問 rxjs 的問題，我就特別激動，就問了他什麼問題，他說剛接觸 rxjs，然後看源碼遇到一端代碼看不懂。

我當時心想，還有這種操作的麼，還沒學會怎麼使用就開始看源代碼了，然後他就把他不懂的代碼貼了上來，rxjs 源碼是 TS 寫的，我對 TS 不算太熟悉，但是他貼的代碼我還是能看懂，他就問了個 this 的問題，我看着也很簡單，但是我沒有解答他的問題。

原因有兩點：

態度不好，我不喜歡。我跟他說你如何去學習 rxjs 的源碼，然後給他介紹書（程墨的《深入淺出 RXJS》）。他直接回復我，你會不會，我就想知道這個問題，不知道就別 BB（大概就是這意思），所以我直接回了他，不會。
自以爲是。他問的問題其實很簡單，雖然 Rxjs 源碼是 TS 寫的，我對 TS 也不是很熟悉，但是這點代碼我覺得還是比較簡單的，然而這沒看懂，然後還在沒有上手怎麼使用，就開始搞源碼，還不聽人建議，這純屬自以爲是，覺得看源碼纔是王道。對於這種純屬基礎沒打好，就開始搞高端的，走都沒學會就想學跑。

那麼我們如何正確的學習一個框架，什麼時候該看源碼，學到什麼程度再看源碼呢？

我覺得學習一個框架應該分爲三個程度。

我以學習 React 爲例來介紹如何學習一門框架(庫)

這個程度我相信是大部分人所處的階段，熟練使用 React 的 API，熟悉 JSX，各個聲明週期的使用，以及組件之間(父子、子父、兄弟等)如何傳遞消息，高階組件等。

這就相當於入了門，可以完成一般的業務了。

設計思想 衆所周知，React 是一種組件化的解決 UI 構建的一種方案，橫向比較同類型的 Vue ，也是組件化的一種解決方案（這體現了 react 抽象的設計思想），既然是組件化的思想，那麼這種解決方案，理論上都會有組件的生命週期，來處理組件從創建到銷燬的鉤子函數。

React 也是一種聲明式的解決方案，通過數據驅動來改變 UI，從而有 UI = f(state)。

當然 react 還有其他的設計思想，比如組合（各個小組件的組合成大的頁面，這些小組件都是通過組合來達到複用的效果），單向數據流。

關鍵部分的實現思路 React 的重點概念有 JSX，虛擬 DOM，Diff 算法，setState 機制，這些重點概念自己是否能有他們的實現思路，甚至在沒有看源碼的情況下是否能自己根據思路實現出來。

這個可以看看鬍子大叔寫的blog,[從零開始實現一個React](GitHub - hujiulong/blog: 我的blog)。

整體框架的知識體系 已經能熟練使用，也掌握了改框架的重點知識，是否能梳理出整個框架的知識體系，把每個知識點串起來，形成一張 react 知識網，網的每個節點都是一個知識點，連線就是他們之間的關係。

這個階段基本上應付面試沒啥問題了。

這個源碼解讀基本上可以看做終極奧義了，其實大多數情況並沒有必要去解鎖這個終極奧義，因爲源碼解讀確實比較費時間，特別是對於基礎不牢固的同學，看幾行代碼就有看不懂的，又得去查資料搞懂。

對於文章開頭提到的那種行爲真的不提倡，作爲一個前端，要學的知識那麼多，每個都去看源碼實現，哪裏有那麼多時間，不如好好想想怎麼用現有的知識更好的去解決業務問題。

然後明白技術是爲業務服務的，如果沒有業務，技術將是無稽之談。然而在我們大多數場景下，我們的業務是沒有必要去造個輪子來解決，因爲對於 react、vue 這種庫來說，已經是非常的通用了，能解決 95% 以上的業務。

當然也有這些開源框架解決不了的問題，比如我有個業務是需要寫一套代碼，多端可以用的，比如寫 vue 代碼，這套代碼也可以轉換爲小程序代碼，甚至是 Android 原生、IOS 原生代碼等，那麼這個時候我們就必須得去看源碼，才能更清晰的知道源碼是怎麼去處理每一個細節，才能造出更強大的輪子。