知乎live筆記05 不吹不黑聊聊前端框架
尤雨溪大神的live
確實是大神，講的方向很多，隨意哪個方向都是值得深入研究的領域。邏輯清晰有條理，聽完之後只會覺得有時候人和人的差距實在是大到無法想象。佩服。
live中給出了很多推薦的連結，要花一些時間去學習、理解相關的知識和內容。
劃重點：
- 理論上講，服務端資料對於前端來說是不可變的，前端不能隨意更改服務端資料，如果要更改，必須與服務端確認。所以將服務端資料放到store中是有些多此一舉的。
- 技術方案都是先有問題，再有思路，同時伴隨著取捨。在選擇衡量技術的時候，儘量去思考這個技術背後是在解決什麼問題，它做了怎樣的取捨。這樣一方面可以幫助我們更好的理解和使用這些技術，也為以後哪天你遇到業務中的特殊情況，需要自己做方案的時候打好基礎。
- 對於前端框架的學習，理解思想最重要，熟悉原始碼是為了提升與業務無關的工程化的理解等，對自己寫框架、做方案有幫助。
Vue原始碼學習
元件化
元件分為：
- 純展示型元件
- 接入型元件container，包含與資料來源打交道的邏輯，將資料傳給純展示型元件
- 互動型元件，比如表單元件，強調複用性
- 功能型元件，例如<router-view><transition>，作為一種擴充套件、抽象機制存在
JSX與模板
JSX在實現功能型元件時是遠超與模板的
模板更善於實現純展示型元件，更容易書寫樣式
變化偵測和渲染機制
命令式：jQuery，直接通過命令完成功能，會遇到維護性的問題
宣告式：宣告文件與變數之間的對映關係
Vue採用的是一種混合式的策略，以元件為單位進行響應式的更新，進行virtualDOM的比對。pull是一種暴力的便利比對，進行全域性的更新，是粗粒度的，而push是響應式的通知系統哪些資料發生了變化，需要進行更新，是更細粒度的。雖然push更新範圍小，會帶來效能的提升，但是由於對每一個需要偵測的變數都需要增加觀察者，同時響應更新的機制也會帶來記憶體方面的壓力。
狀態管理
常見的狀態管理框架Redux、Mobx， vuex
狀態管理的本質：從原事件（source events）對映到狀態的遷移，在對映到UI的改變。
（滑鼠點選事件→應用狀態改變→UI（dom）的改變）
宣告式的渲染解決了狀態到UI的管理，狀態管理解決的是管理事件源對映到狀態變化的過程，將對映過程從試圖元件中剝離出來，提高可維護性
Redux VS Mobx VS Vuex
正規化（paradigm）不同，Redux強調資料不可變，函式式的，reducer是純函式
Mobx和Vuex是響應式的，資料是可變的，資料可變的副作用是宣告式的
本質相同的。
都沒有回答如何處理非同步。
狀態管理如何處理非同步
建議使用RXJS來做一層封裝處理非同步。利用RXJS跳過狀態的改變（Redux中的reducer，Vuex中的mutation），利用“流”來管理（需要對RXJS的理解非常高--我就不理解）
狀態管理的尷尬
- 元件內部狀態的管理，內部狀態和全域性狀態界限不明顯。
- 全域性狀態和服務端資料關係
路由
單頁應用的路由，本質上是將url對映到元件樹結構的過程
React-Router V4
去中心化的路由，利用元件本身去做路由，將路由與元件結合，用元件生命週期做跳轉
Web路由與原生路由
瀏覽模式的區別：Web路由的跳轉需要拋棄跳轉之前的狀態，而原生路由是由新的頁面疊加在舊的頁面上，後退時將當前頁面拿掉
鼓勵Vue社群向原生路由的方向發展
主流的 CSS方案
- 跟 JS 完全解耦，靠前處理器和比如 BEM 這樣的規範來保持可維護性，偏傳統
- CSS Modules，依然是 CSS，但是通過編譯來避免 CSS 類名的全域性衝突
- 各類 CSS-in-JS 方案，React 社群為代表，比較激進
- Vue 的單檔案元件 CSS，或是 Angular 的元件 CSS（寫在裝飾器裡面），一種比較折中的方案
傳統 css 的一些問題
- 作用域 2. Critical CSS（載入首屏需要的CSS檔案） 3. Atomic CSS（將類按最小功能拆分） 4. 分發複用 5. 跨平臺複用
CSS-IN-JS未必是未來的方向，很多功能都可以通過對CSS的靜態編譯實現。
構建工具
磨刀不誤砍柴工，構建工具就是在磨刀。
瀏覽器的限制（程式碼環境）導致了構建工具的必要性。
- 任務的自動化
- 開發體驗和效率（新的語言功能，語法糖，hot reload 等等）
- 部署相關的需求
- 編譯時優化
gulp/grunt：用的較少了，主要價值在於task runner，用於任務自動化，但是現在npm srcipts可以代替其大部分功能，或者用nodeJS手寫指令碼完成這部分功能，而且這兩者在模組化構建方面基本沒有特長
關於部署
由於部署要考慮的問題很複雜（程式碼的打包合併、本地資源的對映、小尺寸圖片的處理等等），導致了webpack配置的複雜，本質上是因為webpack要實現的功能的複雜性
服務端資料通訊
GraphQL對複雜關聯的資料獲取比傳統的REST抽象要強，對資料量的優化更精確。使用門款較高， 需要後端的支援
是否要將服務端資料放到store中管理
理論上講，服務端資料對於前端來說是不可變的，前端不能隨意更改服務端資料，如果要更改，必須與服務端確認。
所以將服務端資料放到store中是有些多此一舉的。
（但是對於大量的資料是不是存在store中，進行增量的修改對效能更有利？）
服務端渲染
跨平臺渲染
將渲染過程與DOM節點解耦。
Web Component
Web Component 和類 React、Angular、Vue 元件化技術誰會成為未來？
Web Assembly
類似於JS的組合語言，適合做一些JS中不適於做的大量的計算、3D動畫、挖礦等，但是目前無法與DOM接觸，對框架影響有限。
react和Vue的場景
場景區別很小，基本可以互換。決定於團隊的習慣、技術水平等
前端框架的學習需要到什麼程度
理解思想最重要，熟悉原始碼是為了提升與業務無關的工程化的理解等，對自己寫框架、做方案有幫助。
為什麼要用服務端渲染
除了SEO的考慮之外，前端渲染的前提是JS全部載入完成，而服務端直出渲染可以減少使用者看到內容的時間，對於某些產品，減少使用者1s的等待可能會帶來更高的轉換率，所以是有必要的。
（對於CRM這種內部工具就無所謂了，讓他們等著唄。）