簡聊初步嘗試服務端渲染的一些感想

Clect 發(fā)布于2019-08-19 17:13 / 1268人閱讀

摘要：多多少少有些不開心的事覺得精力沒有被投入在重點上創(chuàng)業(yè)公司遇到問題變成盲人摸象也許正常吧不過最近這段時間因為服務端的策略調整我開始做一些服務端渲染主要的站點是簡聊的登錄頁面整體從切換到了以及做了一些整體項目結構統(tǒng)一的工作或者說一些思考我估計這

多多少少有些不開心的事, 覺得精力沒有被投入在重點上
創(chuàng)業(yè)公司遇到問題變成盲人摸象也許正常吧
不過最近這段時間因為服務端的策略調整, 我開始做一些服務端渲染
主要的站點是簡聊的登錄頁面, 整體從 Jade 切換到了 React
https://account.jianliao.com/signin
以及做了一些整體項目結構統(tǒng)一的工作, 或者說一些思考

我估計這些問題已經(jīng)被考慮過很多次, 特別是對于發(fā)展較快的那些公司
因為富交互的應用和較大的網(wǎng)站的需求, 很容易導向這個結果
而為了保證交互效果以及產量, 提出相應的方案是自然的一個結果
Teambition 主站的同學之前有講過 ejs 共用代碼的方案
我大致記得是后端渲染, 前端編譯, 還重新實現(xiàn)了路由, 大致的
簡聊(https://jianliao.com)這里的嘗試晚了半年一年, 層次也不深, 用 React 難度也低一些

前后端渲染大略

這些天 Coding 在好多地方刷了幾篇服務端渲染的廣告, 學習目的推薦看下
http://segmentfault.com/a/1190000004120539
http://segmentfault.com/a/1190000004094442

簡聊沒有繼續(xù)跟進 Redux 和 JSX 的方案, 實際上細節(jié)處理很不一樣
整體的思路當然差不太多, Yahoo 的 fluxible 當時演示的方案已經(jīng)成熟
我整理一下大體思路吧, 也許用得到, 特別是中間一些坑
大致有這么幾點, 在開發(fā)之前就需要考慮清楚的

前后端共用的渲染模塊

前后端共用的數(shù)據(jù)層實現(xiàn)

前后端共用的路由方案

前后端共用的類庫

簡聊技術棧當中已有的模塊, 能夠在服務端共用的:

渲染模塊: React 內置功能, 輕松實現(xiàn)

數(shù)據(jù)層實現(xiàn): actions-recorder 是很簡單的封裝

路由方案: router-view 功能少, 容易自由組合

共用類庫: 通過 typeof window 強制判斷控制加載

前后端渲染, 實際上總體的思路還是前端單頁面渲染的套路
單頁面, 會先創(chuàng)建好 Model, 然后根據(jù) Model 和 Router 渲染 View
渲染在 React 當中就簡化成為初次渲染, 以及后續(xù)數(shù)據(jù)和操作的更新
而服務端渲染, 僅僅是把初次渲染放在服務端進行, 后邊照常
因此, 雖說是共用代碼, 但實際上只是支持單頁面在服務端做初次渲染

渲染模塊

共用渲染代碼本來是最難的, 然而 React 出現(xiàn)以后幾乎不是個事情
只是渲染的性能讓 React 的實用性打了折扣
不過 0.14 之后有新的模塊在嘗試, 號稱性能提升明顯
整體思路就是把渲染過程轉化為 Node 常用的 Stream
https://github.com/aickin/react-dom-stream
我沒有實際用, 不過這個方案需要手動封裝 HTML 的部分
方案的代碼是 fork 了 react-dom 官方實現(xiàn)做的, 看起來挺長
我還是等等事件提供更好的方案吧

數(shù)據(jù)層實現(xiàn)

數(shù)據(jù)層需要做的主要是定義一個渲染頁面所需的 initialStore
這個 initialStore 可以用于服務端的初次渲染, 也可以用于客戶端
簡聊網(wǎng)頁版用的 actions-recorder 在服務端渲染時幾乎每做什么
整個 initialStore 直接被輸出為 JSON 寫在 HTML head 當中

前端代碼初始化時讀取其中的數(shù)據(jù), 重新用 actions-recorder 初始化一遍

一般服務端寫 initialStore 之前會做一些操作
比如說服務端能拿到的 cookie 或者其他的一些配置
或者是后面要說的路由信息, 因為簡聊的路由是等效 JSON 表示的
服務端是代替客戶端做了一些初始化工作, 否則前端初始化也是類似的代碼

路由方案

router-view 包含兩部分代碼, 一部分是解析路由, 另一部分是渲染和監(jiān)聽
當然, 初次之外, 還有接口可以定義路由規(guī)則, 我挺懶
如果有興趣看看內部實現(xiàn)和實例也就算了, 很短的代碼
https://github.com/teambition/router-view
頁面初次渲染的過程, 大致就是解析出路由, 渲染對應頁面就完了
路由解析在后端做, 在前端做, 只是獲取 path 的 API 不同而已

這里倒是有一點要注意, 服務端渲染有特別的地方, 就是初次操作
比如說, 打開一個頁面, 會自動觸發(fā)一個操作, 比如驗證某些數(shù)據(jù)
單純按照單頁面的思路, 渲染時不應有操作, 那么, 操作應該是更早發(fā)出
也就是在之前用戶發(fā)有操作, 到服務器渲染頁面, 這中間
這種問題在前端做, 總架構考慮, 就該是認為是用戶打開瀏覽器的行為上發(fā)出
總之盡量避免認為是 didMount 的時候發(fā)出這樣一個行為了

路由另外一點是隔離 JavaScript/CSS 代碼的作用
當然, 其實還是通過單頁面應用的套路來實現(xiàn)的, 甚至 Webpack 打包也是
就是說通過 Component 的分割, 將 JavaScript/CSS 限制在每個頁面里
我們早期一些代碼用的是原始的 DOM 操作, 就不容易管理
比如說打包到一起, 萬一 CSS 或者 JavaScript 不應該卻觸發(fā)了怎么辦?
我們沒有積累強大的后端渲染靜態(tài)資源管理方案, 因而這點需要避免...

共用類庫

最主要的問題就是第三方類庫可能影響在 Node 中加載代碼
其實初次渲染很可能用不到很多代碼, 只要加載不報錯就好了
用的辦法簡單粗暴, 就是強制判斷, 然后控制 require 的執(zhí)行

typeof window isnt undefined

我記得這個還是以前 AirBnB 放出的幻燈片里看到用的
實際遇到會是很瑣碎的情況, 甚至導致代碼都有些難看
但是誰讓 JavaScript 設計時看不到這么遠的適應場景呢

另外有個辦法, 是用 Webpack 的打包方式, 自動把 Node 模塊過濾掉
這個辦法我是剛學會, 具體看網(wǎng)上的例子:
https://webpack.github.io/docs/configuration.html#node
http://stackoverflow.com/a/34033159/883571
大致說來就是定義一些模塊, 告訴 Webpack 用什么方案處理
可以 mock, 可以引用... 細節(jié)我還不清楚, 但值得挖掘

我實踐中遇到最坑的一件事, 莫過于代碼當中存在 event loop
簡聊有段代碼打包后幾萬行, 中間有時間循環(huán), 根本不知道在哪
后來猜想是 setInterval 有問題, 就重置了變量通過報錯定位出來
這種 IO 代碼畢竟不如 pure function 好控制, 能隔離盡量隔離

預想復雜場景

前后端渲染主要的好處, 就是做了單頁面, 又保證首屏渲染體驗
如果僅僅是服務端渲染加 jQuery, 組件化會很頭疼
特別是實現(xiàn)比較復雜的功能, 還要遷就初次渲染額外處理, 真的不輕松
然而用了 React 很多工作就這么省掉了

簡聊目前的場景, 就是第一次加載是服務端渲染, 然后前端加載
之后點擊切換路由, 就完全是 HTML5 路由切換, 完全是單頁面套路
說簡單除了頁面少, 另一點是因為數(shù)據(jù)層幾乎沒有內容
就是說, 從服務端在 HTML head 寫 JSON 傳導前端初始化, 幾乎沒有數(shù)據(jù)
僅僅是讀取的一些配置信息而已, 所以不涉及數(shù)據(jù)庫操作

復雜的情況, 從目前對簡聊主站應用的情況做的設想
應用在初始化時, 會先裝備好查詢到首屏需要的所有數(shù)據(jù)
數(shù)據(jù)拼裝完成, 然后才能開始渲染, 當然到這一步就很簡單了
難度在于怎么查詢好需要的數(shù)據(jù)? 而且, 是一套代碼, 不是前后端各一套
那么要求有更好的抽象機制能做數(shù)據(jù)查詢的事情, 有點難度
一方面是 polyfill 兩邊的 ajax API, 另一方面是數(shù)據(jù)邏輯抽象

我感覺跟著 React 和 GraphQL 的思路, 已經(jīng)觸及一些重要問題了
數(shù)據(jù)和界面之間, 怎么做好隔離, 然而又怎樣設計界面對數(shù)據(jù)的依賴?
界面自身的組合如何抽象, 數(shù)據(jù)自身的組合又如何抽象?
將來要梳理的問題還是會有很多

云服務器 GPU云服務器服務端渲染計算機的初步學習網(wǎng)頁端webrtc視頻渲染網(wǎng)頁端3d云渲染

文章版權歸作者所有，未經(jīng)允許請勿轉載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。

轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/78303.html

深js, jsconf China 回顧

摘要：參與情況第一天趕上了時間晚上聚餐沒去第二天趕飛機提前退場關于的幾個分項沒有在場微信群幾乎全程參與并且大部分時間在維護氣氛陰差陽錯兩天都沒上錯過了推廣機會公司展位準備不充分連續(xù)兩年的問題需要注意印象深的演講百度上的很贊而且在上對付鼠標事件我很參與情況第一天趕上了時間, 晚上聚餐沒去 Nodebot 第二天趕飛機提前退場, 關于 React 的幾個分項沒有在場微信群幾乎全程參與, ...

csRyan 2019-08-21 10:35 評論0 收藏0
初步整理的關于 Progressive Web Apps 的資料

摘要：在上看到發(fā)的視頻被狂轉開始注意之前幾乎對這個詞語沒有印象看到是在的演講還以為是新技術在上找一下這次好多個視頻是關于的視頻的內容主要是講網(wǎng)站優(yōu)化分別用做例子可惜沒有大概要等小右補方案應該沒有問題從視頻看優(yōu)化的效果非常顯著本來好幾秒的在 Twitter 上看到 Addy Osmani 發(fā)的視頻被狂轉, 開始注意https://twitter.com/addyosmani/status/7...

luffyZh 2019-08-19 18:24 評論0 收藏0
個人感想

摘要：對于膽子小的人來說，什么未知情況都會害怕，這感覺真讓人討厭。遠程服務器找到資源并使用響應返回該資源，值為的響應狀態(tài)表示一個正確的響應。最近事好多，心好累。對于膽子小的人來說，什么未知情況都會害怕，這感覺真讓人討厭。知識點一個頁面從輸入 URL 到頁面加載顯示完成，這個過程中都發(fā)生了什么？分為4個步驟：（1），當發(fā)送一個URL請求時，不管這個URL是Web頁面的URL還是We...

Seay 2019-08-19 18:22 評論0 收藏0
關于單頁面應用一些隨想

摘要：前面不短時間持續(xù)投入了時間在做應用架構方面的考量一個是冒險進行了一次應用架構的調整另一個是跟進了的進展當然實際上是同一個事情也許錯過的比收獲的還多一些不過能走到現(xiàn)在也算幸運了畢竟單頁面應用還面臨很多不成熟之處國慶長假過去不少現(xiàn)在的想法估計會前面不短時間持續(xù)投入了時間在做 React 應用架構方面的考量一個是冒險進行了一次應用架構的調整, 另一個是跟進了 Redux 的進展當然, 實際...

AaronYuan 2019-08-21 10:41 評論0 收藏0
前端優(yōu)化感想以及[譯]redux 教程第一部分（共四部分

摘要：自己英語一般，水平有限，獻上原文地址，還有我翻譯的中文地址，歡迎大家勘誤下面是自己的一點感想先說一下，我們知道，前端優(yōu)化有這么幾步，第一步首先呢我們知道，一個應用要依賴好多條文件，而瀏覽器加載完一條，要執(zhí)行完這條才加載下一條，所以呢，就很慢自己英語一般，水平有限，獻上原文地址，還有我翻譯的中文地址，歡迎大家勘誤下面是自己的一點感想先說一下webpack，我們知道，前端優(yōu)化有這么幾...

snowell 2019-08-19 17:14 評論0 收藏0