專治前端焦慮的學習方案

最近我也讀了Jose Aguinaga的博文2016年裏作前端是怎樣一種體驗。這篇博客引起了普遍的關注與討論，不管是在Hacker News仍是Reddit仍是Medium上，都有不少人蔘與到了它的討論中。我也是很早以前就感受到了目前JavaScript生態圈中的羣雄逐鹿，而且我還特意對目前JavaScript庫流行現狀進行了調查，但願可以在奇光異彩的各式各樣的庫中尋找到真正的爲大衆所接受的。不過今天我但願可以更進一步，不只僅再抱怨現狀，而是從我我的的角度來給出一個逐步深刻學習JavaScript生態圈的方案。（若是你尚對HTML/CSS/JavaScript並不瞭解，那麼能夠閱讀前端攻略：從路人甲到英雄無敵）。而在文本中咱們會涉及如下幾個方面:

• 一個現代的JavaScript Web應用會包含哪些部分

• 爲何不推薦使用jQuery？

• 爲何React是個不錯的選擇

• 爲何並不須要你首先學透JavaScript？

• 如何學習ES6語法

• 緣何與如何學習Redux?

• GraphQL到底解決了什麼問題？

• 下一步又會走向何方

Background

JavaScript vs JavaScript

在正式開始以前，咱們先要搞清楚我所要說的和你目前理解的是否是同一個東西。若是你在Google中搜索‘Learn JavaScript’或者‘JavaScript study plan’，你能獲得一坨一坨的資料與教程指導你如何學習。不過實際上在咱們的真實項目中，咱們只會用到一些相對簡單的語法。換言之，可能你在學習Web應用編寫中所須要的80%的知識點都包含在了任何一本JavaScript書籍的前幾章。另外一個角度來講，真正麻煩的點在於如何掌握整個JavaScript生態圈，這裏包含了數不盡的框架與庫。不過我相信本文能夠給你一點啓示。

Building Blocks Of JavaScript Apps

爲了便於理解現代JavaScript爲啥看起來如何複雜，咱們首先要明白其工做原理。咱們首先來看下2008年左右流行的所謂傳統Web應用的架構:

1.服務端從數據庫中獲取數據。
2.服務端讀取這些數據而後渲染到HTML中。
3.HTML文件被髮送到瀏覽器，瀏覽器將HTML轉化爲DOM樹而且展現出來。

如今不少的應用會在客戶端使用JavaScript來保證應用的可交互性，不過本質上瀏覽器仍是從收到HTML文件開始。下面咱們再比較下2016年流行的所謂現代Web應用，典型的就是所謂的單頁應用:

注意到區別了嗎？與傳統的Web應用相比，如今的服務端更多的承擔起是提供數據的功能，而渲染HTML文件這一步交由客戶端進行處理。這一個根本性的變化也會致使不少或好或壞的結果，好的一方面呢:

• 對於某一塊內容，僅僅發送數據會比發送整個HTML文件快不少

• 以單頁應用爲例，客戶端能夠刷新局部數據而不須要刷新整個瀏覽器窗口

壞的方面:

• 因爲如今數據的加載與渲染放在了客戶端，初始加載與渲染會耗費更長的時間

• 如今須要在客戶端提供一個存儲與管理數據的地方，也就是咱們目前所熟悉的狀態管理工具

噁心的地方:

• 隨着客戶端應用邏輯與交互的日漸複雜，你須要掌握像服務端技術棧同樣複雜的前端技術棧

The Client-Server Spectrum

實際上不少才接觸現代前端開發技術棧的同窗，特別是才從後端轉前端的同窗都會有個疑問，既然這麼麻煩爲什麼還要進行轉變？舉個例子，若是用戶但願獲得2+2的結果，確定不須要咱們將這個計算髮送到服務端而後等待結果，瀏覽器徹底可以支持這種簡單的計算。換言之，若是你是打算構建一個純粹的靜態內容站，譬如博客這樣的，那麼在服務端直接生成最終的HTML文件是個不錯的選擇。不過實際上不少Web應用中咱們並不能很好地界定這個分割點，而且整個光譜並非連續的，你並不能先構建一個純粹的服務端應用而後慢慢地向客戶端遷移。當到達某個分割點時，你不得不中止這種遷移過程而去重構大量的代碼，或者你就會面對一個龐雜無序難以維護的垃圾代碼庫。

這一點與不建議使用jQuery不謀而合，你能夠將jQuery看作膠帶一類的存在。對於房子的修修補補非常不錯，可是若是你想不斷地增長內容與功能，你就會發現你的房子歪歪扭扭，處處都是狗皮膏藥，越看越醜。而大部分的現代JavaScript框架則是更像3D打印技術，可能在開始以前須要大量的準備時間，可是它能還你一個更整潔穩定的房屋。

Week 0:JavaScript Basics

除非你是一個純粹的服務端應用程序開發者，你確定知道些JavaScript基礎的內容。若是你還不是很瞭解的話那麼也不須要擔憂，這裏推薦個不錯的教程Codecademy’s JavaScript lessons。

Week 1:Start With React

在你瞭解了JavaScript基礎語法知識以後，我推薦你下一步開始學習React。

React是由Facebook開發而且開源的UI庫，換言之，其專一於完成將數據渲染到HTML這一步驟，也就是所謂的View層。不過須要注意的是，我在這裏並非安利React爲最優秀的庫，這個是因項目而定的，不過我以爲React是個挺不錯的合適初學者的庫：

• React不必定就是最受歡迎的庫，不過其受歡迎程度至關高

• React不必定是最輕量級的庫，不過其談不上是一個重量級的庫

• React不必定是最簡單易學的庫，不過其並不難學

• React不必定是最優雅的庫，不過其看上去仍是很舒心的

總而言之，React並不必定適用於全部的場景，可是我以爲它是所謂最安全的，學了不吃虧。React還會引導你去了解一些像組件、應用狀態與無狀態函數等等現代Web應用框架的概念。最後，React的整個生態圈很是繁榮，你能夠從Github上有關React的項目中找到不少可用的組件，或者在Stack Overflow上找到不少關於React的答疑解惑。我我的是比較推薦Wes Bos的React for Beginners這一課程。這課程包含了React從入門到最佳實踐的所有知識。

Week 2:Your First React Project

• 使用Facebook的create-react-app快速構建React開發環境

• 在重構腳手架中掌握React/Redux/Webpack2基本套路

到了這裏我假設你已經完成了React的基礎課程，若是你跟我差很少的話，那麼我估計你如今的狀態多是:

• 估摸着你已經忘了一大半學過的知識點

• 你很想可以儘快付諸實踐

衆所周知，實踐是學習某個框架的不二法訣，而且開始一個簡單的我的項目也是學習新技術的不錯的試驗點。一個我的項目能夠是簡單的單頁應用，也多是像Github客戶端這樣複雜的Web應用。這裏我推薦你能夠嘗試着去作一個簡單的我的主頁。不過仍是要補充一句，若是你打算用React作一個簡單的靜態內容頁就有點大材小用了，這裏推薦一個不錯的工具Gatsby，這是一個React靜態網站生成器。

這裏我把Gatsby推薦爲你能夠在初步實踐React階段一個不錯的參考項目，主要是由於:

• 其提供了配置好的Webpack，能夠省去你不少學習配置的煩惱

• 可以基於你目錄結構動態設置路由

• 全部的HTML內容一樣能夠服務端渲染

• 生成的靜態內容頁意味着你能夠簡單地就能夠部署在Github主頁上

Week 3:Mastering ES6

隨着我學習React的深刻，我很快就感受到了如今可以看得懂簡單的代碼示例，不過還有不少語法尚不能徹底理解。舉例來講，我還不熟悉ES6中的一些常見特性:

• Arrow functions

• Object destructing

• Classes

• Spread Operator

若是你跟我同樣也不是很熟悉，那麼建議能夠花個幾天時間來認真學習下ES6的特性。若是你喜歡上面推薦的React基礎課程，那麼你也能夠看下ES6 for Everybody系列教程。不過若是你想找點免費的資源，那麼這裏推薦Nicolas Bevacqua’s book, Practical ES6.。最後，我仍是想提到下對於ES6的好的學習方法就是回顧參照各類各樣的代碼庫，學習人家的用法與實踐。

Week 4:Taking On State Management

• 思考:我須要怎樣的前端狀態管理工具?

• 你不必定須要Redux

• 深刻理解Redux:10個來自專家的Redux實踐建議

到這裏咱們已經可以構建基於靜態內容的簡單的React的前端項目，不過真實的Web應用項目不可能全是靜態內容，他們須要從服務端獲取數據而後交與React進行動態渲染。最直觀的作法就是將數據一層一層地傳遞給組件，不過這很容易引起整個系統的混亂。譬如當兩個組件須要去展現一樣的數據時候，它們應該如何交互呢？
這也就是所謂狀態管理工具的用武之處，不一樣於將你的數據存放到組件內，你能夠建立一個獨立的全局單例Store來爲組件樹存放狀態:

在React的生態圈中，最著名的狀態管理工具當屬Redux。Redux不只可以幫助你集中管理數據，還能強制使用者對於數據的修改操做進行統一規範。

你能夠將Redux想象爲銀行，你並不能直接進入本身的帳戶而後修改帳戶中的餘額，你須要經過前臺來發出一系列的指令控制操做。Redux也是這樣，並不容許你直接修改全局狀態，你必須將Actions傳入Reducers，而後由這些純函數來返回新的狀態值。這樣整個系統的流程就清晰可見而且可回溯:

 

一樣的，咱們這裏也推薦一些Redux 教程，以及免費的Redux做者的系列分享。

Week 5: Building APIs With GraphQL

• GraphQL初探:從REST到GraphQL，更完善的數據查詢定義

如今咱們已經討論了不少客戶端開發中所須要的知識棧，不過對於有追求的前端開發者而言這遠遠不夠。不談整個Node生態社區，咱們還須要注意這個服務端的數據是如何傳遞到客戶端的。這裏要着重介紹下GraphQL，一個由Facebook出品的能夠替代傳統的REST API的標準。

傳統的REST API會經過暴露多個REST路由來容許用戶訪問些數據集，譬如/api/posts,/api/comments。而GraphQL將多個後端的REST接口整合爲單個端點，容許用戶從單個端點獲取所須要的數據。

Beyond & Next Steps

章節所限，在個人調查裏也提到Vue與Elm都是很優秀的框架，推薦有興趣的朋友能夠了解下。另外，在學完了這些基礎知識，你還能夠了解如下幾個方面:

• JavaScript on the server (Node, Express…)

• JavaScript testing (Jest, Enzyme…)

• Build tools (Webpack…)

• Type systems (TypeScript, Flow…)

• Dealing with CSS in your JavaScript apps (CSS Modules, Styled Components…)

• JavaScript for mobile apps (React Native…)

• JavaScript for desktop apps (Electron…)