聊聊代碼的拆分和一些前端架構思想

代碼的拆分（colocation）- 把該放一起的東西放一起

首先，傳統來說，開始，我們的應用是一個html文件，裡面是dom，然後，加上樣式和腳本，也即是css和js，這麼一個頁面。

後面，前端開始成為一個應用，也即是，所以需要做模塊化的拆分。而這個拆分的過程，是把改放在一個一起的東西放在了一起。而這個模塊化的拆分，最後，業內都達成了共識，落到了組件這個角色上面。所以，模塊的拆分會把相應的html，js，css文件放在一起或者放在一個文件夾下面。

而組件，在應用複雜起來的時候，會以樹形結構的形式存在，一個入口文件，然後，逐步的在裡面初始化相應的子組件，形成了一個顆樹裝結構。

組件可以大致分為四類：

• 展示組件：輸入state，輸出dom
• 接入組件：有數據源交互的組件
• 交互組件：類似於表達這種交互性的組件
• 功能組件：vue的router，以及transtion這種具備某種功能而沒有實際UI展示的

而就是像react這樣的，返回一個virtual dom或者相應的函數，函數既是組件。也給了架構上面足夠的靈活。

聊聊架構

架構的作用，是讓複雜的事情變得簡單，讓無序的事情變得有序，收貨有序之後的高效和清晰，讓系統變得更加可控。n

因為我以前是做商品詳情的，可以說，市面上最複雜的頁面莫過於此。（當然你們最新的什麼webgl 3d那些不是一個類型的啊）

所以，天貓詳情的架構，其實解決了一些問題，比如說，把狀態放在一起，也即是我們的商品模型product。這樣做的好處，是更加有序，可預測。

那我舉一個無序的例子：數據源拿到數據a，然後組件b，用了數據a，後面組件c，也要用數據a，然後就把a直接傳給c了，後面，數據a要改了，你不知道多少個組件收到了影響，這就是不可預測，無序。在大規模企業應用裡面，這是非常致命的。

所以，這個狀態錶盤裡面，管理了說有的跟頁面相互交流一的數據。

數據之間是可以監聽的，其實跟現在的聲明式渲染其實思想已經非常接近了，你的UI的渲染，一定是跟變數相映射綁定的，雙向綁定。

所以，逐漸的，隨著組件的增加，我們可以發現，數據驅動UI的變化，其實非常清晰和流程。

但是，facebook提出了FLUX的概念，單項數據流，數據本來是不流動的，為什麼需要流動？ 狀態本來是點陣的形式存在的，為什麼facebook需要這東西流動起來。

因為action，這背後設計到複雜場景裡面，如何保持簡單有序。 假設啊，一個比喻，你的系統是一個機器人，你最終拿到手的是一堆的指令集合，然後是你手上的遙控器，或者其他的例如體感遙控之類的。當然，你去改電路板中的某個點的電位，當然可以發生作用，可是這將導致無序。

指令的意思是，命令，為啥？業務，是一個一個的動作，狀態圖才能夠描述系統的運轉，而不是點陣，狀態圖是有方向的。

這是我理解的有序的本質，也即是FLUX設計的核心思想。第一點：把狀態集中起來管理到store 第二點：把系統狀態化，並且每一個動作都是有方向的狀態圖，也即是action，你會發現，你看到action，都是新舊的state方向的變化。FLUX有諸多的實現，幾十個版本的實現，包括redux,mobx,vuex,rxjx。

你會發現，隨著業務越來越複雜，其實就是這些子邏輯的增加和減少，而狀態點陣的變化，其實對更高層級的控制來說，是透明的。

比如說，有限狀態機來描述tcp協議：