聊聊前端框架——尤雨溪
阿新 • • 發佈:2019-02-15
框架選擇
- 結合場景需求
- 與開發者個人背景有關
- 不如讓不同場景,不同開發者都變得更有效,因此多種方案並存是有益的
元件
早期開發是以頁面為單位,而現在更趨向於應用,應用則意味著元件化;而React揭示了一個事實,元件樹是一個函式
分類
- 接入型 container
- 展示型
- 互動型 比如各類加強版的表單元件,通常強調複用
- 功能型 比如
<router-view>
,<transition>
,作為一種擴充套件、抽象機制存在。
模版與jsx的對比
- jsx:擁有js完全的靈活度,對於功能性元件的書寫遠超模版
- 模版:強制性的要求在減少檢視中的邏輯,以更加檢視化的方式思考
collocation
相關的資源(js,css之類)以元件作切分,管理;而傳統的做法是按檔案型別維護
變化偵測
-
pull(粗粒度)
react與angular,需要手動告知有變化發生,之後它們會進行“暴力的”比對(react的diff,angular的髒檢查),來找到哪裡有變化;因此react中有
pure component
一類的東西來由使用者幫助系統跳過一些比對 -
push(細粒度)
由’watcher’主動告知哪裡發生變動,相應的會帶來額外的記憶體開銷。因此vue2.0採用元件push,內部pull(virtual dom比對)的策略
偵測成本與自動優化的平衡取捨
狀態管理
從源事件——>狀態的遷移——>狀態的改變——>ui的更新
e.g. 滑鼠點選——>應用狀態改變——>ui改變
redux與mobx與vue?
問題
- 非同步的管理
- 區域性狀態與全域性狀態的管理
路由
以元件作為路由對映的基本元素
url可理解為序列化的狀態
React-router4將路由去中心化,用元件本身作為路由,而非是以往的集中式管理。但這對於理解路由的結構;管理路由跳轉有一些問題
web路由與應用路由區別
web路由方案,相對於應用路由,在跳轉中狀態被丟棄,而非是一層層的疊加狀態
css方案
主流的 CSS 方案
- 跟 JS 完全解耦,靠前處理器和比如 BEM 這樣的規範來保持可維護性,偏傳統
- CSS Modules,依然是 CSS,但是通過編譯來避免 CSS 類名的全域性衝突
- 各類 CSS-in-JS 方案,React 社群為代表,比較激進
- Vue 的單檔案元件 CSS,或是 Angular 的元件 CSS(寫在裝飾器裡面),一種比較折中的方案
傳統 css 的一些問題
- 作用域 —— 幾種解決方案已經基本ok
- Critical CSS —— 對於服務端渲染尤為重要,因此需要在服務端偵測到頁面用到了哪些css,vue可以在編譯時將css插入與元件的生命週期掛鉤,而css in js
- Atomic CSS(原子類)—— 優點,css體積小,不過由靜態編譯去進行這種處理也完全可行
- 分發複用
- 跨平臺複用