安利一個React同構渲染腳手架 —— razzle

本文發表於我的GitHub轉載請註明出處css


什麼是同構:

  • 客戶端渲染:頁面在 JavaScript,CSS 等資源文件加載完畢後開始渲染,路由爲客戶端路由,也就是咱們常常談到的 SPA(Single Page Application)。
  • 服務端渲染:頁面由服務端直接返回給瀏覽器,路由爲服務端路由,URL 的變動會刷新頁面,原理與 ASP,PHP 等傳統後端框架相似。
  • 同構:英文表述爲 Isomorphic 或 Universal,即編寫的 JavaScript 代碼可同時運行於瀏覽器及 Node.js 兩套環境中,用服務端渲染來提高首屏的加載速度,首屏以後的路由由客戶端控制,即在用戶到達首屏後,整個應用還是一個 SPA。

簡而言之,同構是服務端直出和客戶端渲染的結合html


同構的優勢:

  1. SEO更友好。
  2. 整個頁面級別的應用會使得瀏覽器在解析dom完成以後立刻有東西能夠渲染,減小渲染時間(首屏優化)。
  3. 服務端和客戶端維護一份代碼就好了。
  4. 開源福利:React16的發佈經過重寫了用於服務端渲染的renderToString函數,將渲染速度提高至v15的3倍。
  5. 等等

固然,同構也沒有這麼好,具體的的選擇仍是看業務的,權衡開發(遷移)成本,性能影響等等諸多因素。react


那麼問題來了:)

若是,我嘗試下 React服務端渲染,但又不想本身一開始就糾結於較繁瑣的配置呢?git

不少人的開發都會選用一個現有的腳手架開始,那麼如何選用一個腳手架呢?github


關於一個框架的腳手架,在網上常常看到開發者這樣說:

I'm looking for a very simple starter pack... I don't need all the hoopla.

的確,對一個腳手架項目而言,它須要有全部你想要的,不須要有你不想要的。typescript

react官方的腳手架create-react-app的README中提到 現階段不支持直接提供服務端渲染redux

那麼有哪些支持同構渲染的腳手架呢?

好比這些:後端

這些腳手架各有各的特色,有的依賴多,有的依賴少,有的性能好,有的針對某一個痛點解決...數組

下面隆重介紹今天的主角 ———— razzle:

razzle 是一個把全部於服務端渲染相關的繁瑣配置抽象成了單獨的一個依賴,瀏覽器

給你相似於create-react-app的開發體驗,

可是把剩下的架構決策權,好比 框架選用,路由系統的選擇、數據獲取方式全都交給了開發者本身,充分符合上面說的:

have everything you need and nothing you don't.


razzle 和上述提到的其餘支持同構渲染的框架的 最大不一樣 在於他能過抽象依賴,可以提供相似create-react-app的開發體驗,這就意味了給了開發者很大的自由度去選擇本身順手的,本身看得上眼的react生態裏的庫,razzle提供豐富的examples,幫助開發者可以快速的結合一些流行的成熟的庫,好比用typescript進行開發,經過結合react-redux作狀態管理,好比經過結合react-router作路由系統,經過結合react-loadable作到組件級別的代碼分割和懶加載等等不少。

razzle 的理念決定了它不僅支持React,

還支持Reason,Elm,Vue,Angular,和將來的新框架:)

項目的主要的優勢有:

  1. 開發環境模塊熱替換,無需重啓就能夠看到效果
  2. 你最喜歡的ES6 支持
  3. 與create-react-app 相同的 css 設置
  4. 不少框架的支持
  5. 默認Jest
  6. 零配置服務端渲染


關於同構有一些誤區,列幾個熟悉的:

  1. 同構性能沒有客戶端渲染好?網絡流量高峯的時候,轉到客戶端渲染並不會起很大做用。ssr在服務端的渲染實際上是很是快的,儘管這裏提供不了精確的數據支持,可是看了不少博客上都提到過這種觀點。
  2. 同構容易引發內存泄漏?其實並非,只要注意不要盲目的在定時的函數體中向全局的數組push東西等等,注意組建生命週期componentDidMount中放置服務端執行不了的代碼,而且注意在用一些如window變量前先進行判斷就好,並非很容易致使內存泄漏。


理解還不是很成熟,但願能與你們交流討論。

筆者是razzle的項目使用者,受益者,但願能讓更多的人看到這個項目,將來一塊兒讓他更好。

關於同構的一些其餘文章,也是本文的不少參考:

相關文章
相關標籤/搜索