資訊專欄INFORMATION COLUMN
摘要：多多少少有些不開心的事覺得精力沒有被投入在重點(diǎn)上創(chuàng)業(yè)公司遇到問題變成盲人摸象也許正常吧不過最近這段時間因?yàn)榉?wù)端的策略調(diào)整我開始做一些服務(wù)端渲染主要的站點(diǎn)是簡聊的登錄頁面整體從切換到了以及做了一些整體項(xiàng)目結(jié)構(gòu)統(tǒng)一的工作或者說一些思考我估計(jì)這
多多少少有些不開心的事, 覺得精力沒有被投入在重點(diǎn)上
創(chuàng)業(yè)公司遇到問題變成盲人摸象也許正常吧
不過最近這段時間因?yàn)榉?wù)端的策略調(diào)整, 我開始做一些服務(wù)端渲染
主要的站點(diǎn)是簡聊的登錄頁面, 整體從 Jade 切換到了 React
https://account.jianliao.com/signin
以及做了一些整體項(xiàng)目結(jié)構(gòu)統(tǒng)一的工作, 或者說一些思考
我估計(jì)這些問題已經(jīng)被考慮過很多次, 特別是對于發(fā)展較快的那些公司
因?yàn)楦唤换サ膽?yīng)用和較大的網(wǎng)站的需求, 很容易導(dǎo)向這個結(jié)果
而為了保證交互效果以及產(chǎn)量, 提出相應(yīng)的方案是自然的一個結(jié)果
Teambition 主站的同學(xué)之前有講過 ejs 共用代碼的方案
我大致記得是后端渲染, 前端編譯, 還重新實(shí)現(xiàn)了路由, 大致的
簡聊(https://jianliao.com)這里的嘗試晚了半年一年, 層次也不深, 用 React 難度也低一些
這些天 Coding 在好多地方刷了幾篇服務(wù)端渲染的廣告, 學(xué)習(xí)目的推薦看下
http://segmentfault.com/a/1190000004120539
http://segmentfault.com/a/1190000004094442
簡聊沒有繼續(xù)跟進(jìn) Redux 和 JSX 的方案, 實(shí)際上細(xì)節(jié)處理很不一樣
整體的思路當(dāng)然差不太多, Yahoo 的 fluxible 當(dāng)時演示的方案已經(jīng)成熟
我整理一下大體思路吧, 也許用得到, 特別是中間一些坑
大致有這么幾點(diǎn), 在開發(fā)之前就需要考慮清楚的
前后端共用的渲染模塊
前后端共用的數(shù)據(jù)層實(shí)現(xiàn)
前后端共用的路由方案
前后端共用的類庫
簡聊技術(shù)棧當(dāng)中已有的模塊, 能夠在服務(wù)端共用的:
渲染模塊: React 內(nèi)置功能, 輕松實(shí)現(xiàn)
數(shù)據(jù)層實(shí)現(xiàn): actions-recorder 是很簡單的封裝
路由方案: router-view 功能少, 容易自由組合
共用類庫: 通過 typeof window 強(qiáng)制判斷控制加載
前后端渲染, 實(shí)際上總體的思路還是前端單頁面渲染的套路
單頁面, 會先創(chuàng)建好 Model, 然后根據(jù) Model 和 Router 渲染 View
渲染在 React 當(dāng)中就簡化成為初次渲染, 以及后續(xù)數(shù)據(jù)和操作的更新
而服務(wù)端渲染, 僅僅是把初次渲染放在服務(wù)端進(jìn)行, 后邊照常
因此, 雖說是共用代碼, 但實(shí)際上只是支持單頁面在服務(wù)端做初次渲染
共用渲染代碼本來是最難的, 然而 React 出現(xiàn)以后幾乎不是個事情
只是渲染的性能讓 React 的實(shí)用性打了折扣
不過 0.14 之后有新的模塊在嘗試, 號稱性能提升明顯
整體思路就是把渲染過程轉(zhuǎn)化為 Node 常用的 Stream
https://github.com/aickin/react-dom-stream
我沒有實(shí)際用, 不過這個方案需要手動封裝 HTML 的 部分
方案的代碼是 fork 了 react-dom 官方實(shí)現(xiàn)做的, 看起來挺長
我還是等等事件提供更好的方案吧
數(shù)據(jù)層需要做的主要是定義一個渲染頁面所需的 initialStore
這個 initialStore 可以用于服務(wù)端的初次渲染, 也可以用于客戶端
簡聊網(wǎng)頁版用的 actions-recorder 在服務(wù)端渲染時幾乎每做什么
整個 initialStore 直接被輸出為 JSON 寫在 HTML head 當(dāng)中
前端代碼初始化時讀取其中的數(shù)據(jù), 重新用 actions-recorder 初始化一遍
一般服務(wù)端寫 initialStore 之前會做一些操作
比如說服務(wù)端能拿到的 cookie 或者其他的一些配置
或者是后面要說的路由信息, 因?yàn)楹喠牡穆酚墒堑刃?JSON 表示的
服務(wù)端是代替客戶端做了一些初始化工作, 否則前端初始化也是類似的代碼
router-view 包含兩部分代碼, 一部分是解析路由, 另一部分是渲染和監(jiān)聽
當(dāng)然, 初次之外, 還有接口可以定義路由規(guī)則, 我挺懶
如果有興趣看看內(nèi)部實(shí)現(xiàn)和實(shí)例也就算了, 很短的代碼
https://github.com/teambition/router-view
頁面初次渲染的過程, 大致就是解析出路由, 渲染對應(yīng)頁面就完了
路由解析在后端做, 在前端做, 只是獲取 path 的 API 不同而已
這里倒是有一點(diǎn)要注意, 服務(wù)端渲染有特別的地方, 就是初次操作
比如說, 打開一個頁面, 會自動觸發(fā)一個操作, 比如驗(yàn)證某些數(shù)據(jù)
單純按照單頁面的思路, 渲染時不應(yīng)有操作, 那么, 操作應(yīng)該是更早發(fā)出
也就是在之前用戶發(fā)有操作, 到服務(wù)器渲染頁面, 這中間
這種問題在前端做, 總架構(gòu)考慮, 就該是認(rèn)為是用戶打開瀏覽器的行為上發(fā)出
總之盡量避免認(rèn)為是 didMount 的時候發(fā)出這樣一個行為了
路由另外一點(diǎn)是隔離 JavaScript/CSS 代碼的作用
當(dāng)然, 其實(shí)還是通過單頁面應(yīng)用的套路來實(shí)現(xiàn)的, 甚至 Webpack 打包也是
就是說通過 Component 的分割, 將 JavaScript/CSS 限制在每個頁面里
我們早期一些代碼用的是原始的 DOM 操作, 就不容易管理
比如說打包到一起, 萬一 CSS 或者 JavaScript 不應(yīng)該卻觸發(fā)了怎么辦?
我們沒有積累強(qiáng)大的后端渲染靜態(tài)資源管理方案, 因而這點(diǎn)需要避免...
最主要的問題就是第三方類庫可能影響在 Node 中加載代碼
其實(shí)初次渲染很可能用不到很多代碼, 只要加載不報(bào)錯就好了
用的辦法簡單粗暴, 就是強(qiáng)制判斷, 然后控制 require 的執(zhí)行
typeof window isnt undefined
我記得這個還是以前 AirBnB 放出的幻燈片里看到用的
實(shí)際遇到會是很瑣碎的情況, 甚至導(dǎo)致代碼都有些難看
但是誰讓 JavaScript 設(shè)計(jì)時看不到這么遠(yuǎn)的適應(yīng)場景呢
另外有個辦法, 是用 Webpack 的打包方式, 自動把 Node 模塊過濾掉
這個辦法我是剛學(xué)會, 具體看網(wǎng)上的例子:
https://webpack.github.io/docs/configuration.html#node
http://stackoverflow.com/a/34033159/883571
大致說來就是定義一些模塊, 告訴 Webpack 用什么方案處理
可以 mock, 可以引用... 細(xì)節(jié)我還不清楚, 但值得挖掘
我實(shí)踐中遇到最坑的一件事, 莫過于代碼當(dāng)中存在 event loop
簡聊有段代碼打包后幾萬行, 中間有時間循環(huán), 根本不知道在哪
后來猜想是 setInterval 有問題, 就重置了變量通過報(bào)錯定位出來
這種 IO 代碼畢竟不如 pure function 好控制, 能隔離盡量隔離
前后端渲染主要的好處, 就是做了單頁面, 又保證首屏渲染體驗(yàn)
如果僅僅是服務(wù)端渲染加 jQuery, 組件化會很頭疼
特別是實(shí)現(xiàn)比較復(fù)雜的功能, 還要遷就初次渲染額外處理, 真的不輕松
然而用了 React 很多工作就這么省掉了
簡聊目前的場景, 就是第一次加載是服務(wù)端渲染, 然后前端加載
之后點(diǎn)擊切換路由, 就完全是 HTML5 路由切換, 完全是單頁面套路
說簡單除了頁面少, 另一點(diǎn)是因?yàn)閿?shù)據(jù)層幾乎沒有內(nèi)容
就是說, 從服務(wù)端在 HTML head 寫 JSON 傳導(dǎo)前端初始化, 幾乎沒有數(shù)據(jù)
僅僅是讀取的一些配置信息而已, 所以不涉及數(shù)據(jù)庫操作
復(fù)雜的情況, 從目前對簡聊主站應(yīng)用的情況做的設(shè)想
應(yīng)用在初始化時, 會先裝備好查詢到首屏需要的所有數(shù)據(jù)
數(shù)據(jù)拼裝完成, 然后才能開始渲染, 當(dāng)然到這一步就很簡單了
難度在于怎么查詢好需要的數(shù)據(jù)? 而且, 是一套代碼, 不是前后端各一套
那么要求有更好的抽象機(jī)制能做數(shù)據(jù)查詢的事情, 有點(diǎn)難度
一方面是 polyfill 兩邊的 ajax API, 另一方面是數(shù)據(jù)邏輯抽象
我感覺跟著 React 和 GraphQL 的思路, 已經(jīng)觸及一些重要問題了
數(shù)據(jù)和界面之間, 怎么做好隔離, 然而又怎樣設(shè)計(jì)界面對數(shù)據(jù)的依賴?
界面自身的組合如何抽象, 數(shù)據(jù)自身的組合又如何抽象?
將來要梳理的問題還是會有很多
文章版權(quán)歸作者所有，未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址：http://systransis.cn/yun/78303.html
摘要：參與情況第一天趕上了時間晚上聚餐沒去第二天趕飛機(jī)提前退場關(guān)于的幾個分項(xiàng)沒有在場微信群幾乎全程參與并且大部分時間在維護(hù)氣氛陰差陽錯兩天都沒上錯過了推廣機(jī)會公司展位準(zhǔn)備不充分連續(xù)兩年的問題需要注意印象深的演講百度上的很贊而且在上對付鼠標(biāo)事件我很 參與情況 第一天趕上了時間, 晚上聚餐沒去 Nodebot 第二天趕飛機(jī)提前退場, 關(guān)于 React 的幾個分項(xiàng)沒有在場 微信群幾乎全程參與, ...
摘要：在上看到發(fā)的視頻被狂轉(zhuǎn)開始注意之前幾乎對這個詞語沒有印象看到是在的演講還以為是新技術(shù)在上找一下這次好多個視頻是關(guān)于的視頻的內(nèi)容主要是講網(wǎng)站優(yōu)化分別用做例子可惜沒有大概要等小右補(bǔ)方案應(yīng)該沒有問題從視頻看優(yōu)化的效果非常顯著本來好幾秒的 在 Twitter 上看到 Addy Osmani 發(fā)的視頻被狂轉(zhuǎn), 開始注意https://twitter.com/addyosmani/status/7...
摘要：前面不短時間持續(xù)投入了時間在做應(yīng)用架構(gòu)方面的考量一個是冒險進(jìn)行了一次應(yīng)用架構(gòu)的調(diào)整另一個是跟進(jìn)了的進(jìn)展當(dāng)然實(shí)際上是同一個事情也許錯過的比收獲的還多一些不過能走到現(xiàn)在也算幸運(yùn)了畢竟單頁面應(yīng)用還面臨很多不成熟之處國慶長假過去不少現(xiàn)在的想法估計(jì)會 前面不短時間持續(xù)投入了時間在做 React 應(yīng)用架構(gòu)方面的考量一個是冒險進(jìn)行了一次應(yīng)用架構(gòu)的調(diào)整, 另一個是跟進(jìn)了 Redux 的進(jìn)展當(dāng)然, 實(shí)際...
摘要：自己英語一般，水平有限，獻(xiàn)上原文地址，還有我翻譯的中文地址，歡迎大家勘誤下面是自己的一點(diǎn)感想先說一下，我們知道，前端優(yōu)化有這么幾步，第一步首先呢我們知道，一個應(yīng)用要依賴好多條文件，而瀏覽器加載完一條，要執(zhí)行完這條才加載下一條，所以呢，就很慢 自己英語一般，水平有限，獻(xiàn)上原文地址，還有我翻譯的中文地址，歡迎大家勘誤 下面是自己的一點(diǎn)感想 先說一下webpack，我們知道，前端優(yōu)化有這么幾...
閱讀 2226·2021-11-15 11:38
閱讀 1179·2021-09-06 15:02
閱讀 3432·2021-08-27 13:12
閱讀 1406·2019-08-30 14:20
閱讀 2426·2019-08-29 15:08
閱讀 668·2019-08-29 14:08
閱讀 1754·2019-08-29 13:43
閱讀 1488·2019-08-26 12:11
