Miox答疑解惑之基於頁面的服務體系

Miox發佈以來，不少小夥伴都在問一個問題：Miox與react-router@4.x到底有什麼不一樣？我在掘金和知乎上都回答了一些，可是不夠完整，那麼我就來解釋下它們的不一樣點。

這個問題很簡單，也許是因爲我以前文章標題取的是Miox帶你走進動態路由的世界讓你們以爲Miox僅僅作了動態路由選擇這一層。其實否則，Miox中router僅僅是一部分，咱們還作了不少其餘的事情。簡單而言，咱們能夠歸納爲「基於後端服務理念而架設在前端頁面上的一套WEB SERVICE體系」。

Miox是一個兼容多種渲染引擎的，提供高度自動化 Webview 生命週期管理的一箇中間件/框架，同時提供了開箱即用的若干自動化腳手架，快速生成項目。它能夠自動幫你處理路由切換、webview 生命週期管理等各類單頁應用會面臨的問題，讓你專一於 webview 內的業務開發。
Miox 實現了生命週期和路由管理的最佳實踐，避免了不統一的開發方式可能形成的性能降低和錯誤，而且能夠平滑接入SSR這樣的開發技術，達到開發效率和接近原生體驗二者之間的最佳平衡。
Miox 並不依賴任何框架，這意味着你的業務開發不管是基於 React、Vue 仍是其餘框架，均可以完美的接入到其中來，無需擔憂是否在公司中不能使用某些框架的問題。

頁面管理的區別

React-router的V4版本，已支持動態路由的概念。而這個咱們早在2年前就已經提出，通過2年時間的沉澱纔開源了這個框架。它們二者的區別在因而否單一頁面管理和數據是否隔離上：

• react-router在一個頁面內基於狀態不一樣分層爲不一樣的組件顯示，作到了動態路由區分頁面內容，內部能夠共享頂層（父）組件數據。
• Miox分爲多個頁面由統一的service服務進行管理，數據隔離，不共享頁面數據。

二者因爲設計理念的差別，在不一樣的場景中各有利弊。

Miox另一個優點在於，當咱們使用KOA做爲咱們的服務應用框架，要接入Miox的時候，因爲設計理念的一致性，咱們徹底能夠直接接管掉koa-router來進行自我處理，意思就是對同構很是友好。固然說回來，REACT對後端的支持也很是好，next.js幫咱們完成了這些工做。

Miox比較適合大型項目的開發，靈活的路由分層結構和服務化思想給你們帶來不少相似後端書寫的體驗和維護體驗。咱們能夠直接使用不少不關係nodejs環境變量的中間件包，而不用咱們本身去從新造輪子。一套中間件也許就能直接在前端和後端同時使用，何樂而不爲呢？

補充動態路由的性能說明

基於後端路由理念，體系無非就是頁面 = 模板 + 數據。從這個公式上面，您能夠看到，對於一個頁面的渲染，模板相當重要。在Miox的世界裏，模板就是咱們所謂的Vue或者react。那麼何時建立與何時銷燬的問題，經過後端請求的機制能夠知道，當一個URL進入的時候，咱們會動態根據一些變量生成出數據，同時對應選擇模板來渲染。MIox也是如此。Miox實際上是架設在Web端的一套服務系統，簡稱web service。Miox將使用對應的模板和數據進行頁面的渲染。可是考慮瀏覽器端的特殊性，好比渲染性能等問題，咱們須要對其做出調整。最明顯的作法就是加入緩存機制，咱們是用空間來換效率和性能。咱們會緩存這些生成出來的對象（相似後端最終生成出來的頁面），加入到內存堆棧中，經過一種動態算法來計算進入的這個URL究竟是要從緩存中拿仍是須要從新建立。算法可能比較複雜，您能夠經過這裏看下源碼。咱們會將瀏覽過的頁面緩存起來，表現爲節點的堆疊。固然咱們也不會那麼傻，節點堆疊多了，也是要影響性能的。因此在Miox啓動服務以前，咱們就會讓用戶設置一個max屬性，讓用戶來選擇咱們最大緩存多少個頁面。當每次渲染後，發現頁面緩存堆棧超過了這個最大的指，那麼咱們會經過最遠距離關係將那個須要被刪除的頁面（對象）給刪除，達到一種動態平衡。

再說一點比較深刻的，其實咱們的緩存不只僅存在於頁面堆棧，還在於您渲染的模板上，您能夠經過webview.dic屬性來看下這個模板上被緩存的一些特徵。咱們的原則是，路由不對應具體頁面，而是對應具體頁面的constructor原型對象。這個點，不少小夥伴因爲沒有看過render.js的實現而沒能理解。這個纔是緩存特性的關鍵，理論來說，路由不對應頁面，而是對應生成頁面的原型對象。

最後

你們都會問，我怎麼開始寫一個Miox的項目呢？

咱們提供了腳手架以外，還會提供一系列的教程幫助你們來熟悉Miox的編寫。最近咱們有一個倉庫，就是來介紹Miox的簡單使用，點擊這裏查看。