前言：
當我第一次接觸AngularJs 1.x的時候，被其聲明式渲染，路由系統，單頁面，豐富的指令深深吸引。當我發現nodejs正在服務端發揮著耀眼的光芒的時候，又在感嘆js的強大。這些年，伴隨著Vue，React，Angular的崛起，原先刀耕火種的前端已經逐步退出舞臺。更多的帶給我們的是一系列工具、腳手架。但是這些東西本不應該是天生就有的，而是標著著前端浪潮的一些進步：
SPA應用的一些感觸
現在作為開發者的我們，可能已經習慣每天產出的一些新的框架，每天迭代的一個新的工具，慢慢的就會變得麻木和懶惰。其實有的時候我們更需要的是對問題的一種思考和解決。下面簡單記錄一些我目前遇到的一些問題的解決方案，在此做一些分享吧：
1. 前端SPA路由思想和 Miox 路由的思想
為什么要使用路由？
傳統web開發是每一個請求地址都會請求服務器來進行處理，但是用戶有些操作則無需請求服務器，直接頁面端修改下邏輯就能達到目的，這種最好使用路由，也許會有疑問：直接使用js處理下不就行了。使用js直接處理這些是可以的，事實上以前我們也這么做，但是這樣做不便于用戶收藏當前頁，因為使用js時并不更新url，但是使用路由時，url也是隨著改變的，用戶瀏覽到一個網頁時可以直接復制或收藏當前頁的url給別人，這種方式對于搜索引擎和用戶來說都是友好的。
- 服務端路由：對于服務器來說，當接收到客戶端發來的HTTP請求，會根據請求的URL，來找到相應的映射函數，然后執行該函數，并將函數的返回值發送給客戶端。對于最簡單的靜態資源服務器，可以認為，所有URL的映射函數就是一個文件讀取操作。對于動態資源，映射函數可能是一個數據庫讀取操作，也可能是進行一些數據的處理，等等。以Express為例:
app.get('/users', (req, res) => {
db.queryAllUsers()
.then(data => res.send(data))
})
- 客戶端路由對于客戶端（通常為瀏覽器）來說，路由的映射函數通常是進行一些DOM的顯示和隱藏操作。這樣，當訪問不同的路徑的時候，會顯示不同的頁面組件。客戶端路由最常見的有以下兩種實現方案：基于Hash或者基于History API
Miox這個東西是一種思想的產物，是一種服務端路由客戶端化。我們現在其實已經習慣了vue-router或者react-router早期這樣的靜態路由（react-router后續已經支持了動態路由）
現在主流的框架，除去Angular，就只有Vue與React了。它們各自有各自的路由模塊。總的來說，他們的路由模式，都是遵循自己的設計原則來設計的，都是采用組件化路由的思想，達到分發路由的目的，Vue與React路由都是組件，數據上可以通過頂層（父）組件傳遞數據下來，頁面之間數據可以互通。而Miox 是基于服務端MPA的思想：頁面之間數據不互通，需要通過Store等中間產物來達到互通，理論上是完全隔離的。
有的時候我們在做nodejs中間層的時候，我們更希望我們的思想是統一的，也就是PAGE = TEMPLATE + DATA。
其實在用vue-router的時候，我們還會碰到另一些問題：
它是一套靜態路由，不具備動態選擇組件的能力，需要通過各種HOOK手段來達到選擇組件，比如說<component />組件等。但是在官方的文檔上我們可以看到動態路由匹配，其實這是動態URI的概念，而非真正的動態路由概念。
const router = new VueRouter({
routes: [
// 動態路徑參數 以冒號開頭
{ path: '/user/:id', component: User }
]
})
在實際的場景中，/user/:id變化的任意路徑都只會對應到User組件，而非不同的組件來渲染。所以這個概念不是很正確。如果基于后端對路由概念到理解，那么我們應該是通過這樣到模式來反映出動態路由的概念。
router.get('/user/:id', ctx => {
if (global.opened) {
return ctx.render(webviewA);
}
ctx.render(webviewB);
})
Miox是一種基于服務端路由思想的框架，做的東西比較哲學化，但是使用起來確實可以提高開發者的效率，我覺得也是思想上的一種轉變，而這種轉變能帶來什么，還是需要開發者自己去衡量，正所謂不談應用場景選框架是耍流氓。這里只是拋磚引玉，更多介紹可以參考Miox文檔。
2. 提高Mock開發效率
傳統開發中，后端定義好接口規范，前端根據規范進行mock數據，所以我們可能會去一遍遍重復著接口文檔的編寫，類似于這樣的動作：
httpRequest.get('/user/login', options)
隨著時間的推移，接口越來越多，或者接口地址的變動，我們需要有一個地方可以專門去維護這樣的地址，我們不希望這些東西需要我們手動一個個敲下來，最好能根據服務端的接口規范自動生成！
其次可能還會存在另一些問題，如果所有mock的數據存在本地的話，很難協同開發和維護。如果所有mock數據放在git服務，經常會碰到彼此需要交叉修改的mock數據的情況，容易早場代碼沖突和不規范，況且mock數據并不屬于業務性代碼，提交到遠程mock似乎并不是那么友好，隨著項目體量的增加或者迭代，這種mock方式越發難以維護。所以我們需要一個mock服務器，可能代替存儲我們的mock數據最好了！
當然mock服務能做的不僅僅只有這些，有興趣的可以參考：easy-mock
綜合問題的一些思考
前端業務開發完之后，并不是什么事情都沒有了，恰巧，開發完業務需求，只是最初的一步。因為我們的頁面需要更快更優雅的展示在用戶面前，我們還需要更多的東西。
- 為了讓頁面能夠展示的安全可靠，我們需要不斷地測試、預發... 我們需要不斷地區分這些環境，生成不同接口環境的代碼包...
- 為了團隊協作的規范流程，以及最終發布的代碼質量，我們需要不斷地gitflow 和 codeReview gitflow
- 為了讓頁面更加流暢和迅速的展示，我們需要不斷地優化加載資源和頁面交互餓了么的 PWA 升級實踐
- 為了讓用戶無感知發布，我們又需要一系列發布規范，有興趣的可以參考這里：大公司里怎樣開發和部署前端代碼
這里我基于上述做了一個簡單的demo：
Miox + easyMock + 前端部署簡化
關于
作者：monkeywang
Miox官方地址：Miox
Miox 文檔地址： Miox文檔
歡迎關注微信公眾號：前端知識鋪
