如何评价51信用卡开源的Miox框架？

目前在51信用卡工作，来51一年多，正好见证了公司高速发展的阶段，前端人员也从刚开始10多人到现在60人，我尝试站在这个角度回答下miox为什么会诞生。

在发展初期，51和很多中小型公司一样，技术栈选择前卫和大胆，基本所有的h5页面都是采用spa完成，包括主app管家内的页面以及整个套壳的金融web app。

随着业务的高速增长，spa的开发效率和体验给业务带来了很大的贡献，但是随着规模增大，也遇到不少问题，尤其是移动端:
1. spa首屏加载慢
2. spa页面间切换动画流畅性以及和app原生页面动画的一致性。
3. spa页面间通信。
4. 大型spa项目路由治理。
5. spa页面间互相影响带来的可维护性和稳定性的下降。
6. spa和app原生导航条冲突问题。
7. spa子路由独立打开问题。
8. ios手势返回问题。
…

和创业初期不同，规模性和稳定性带来的问题越来越多，我们就越能理解大厂选择重MPA轻SPA的原因，但我们争论了很长一段时间，还是决定尝试解决这些问题。

miox就是在这种背景下产生的。我们希望能够尽可能降低单页开发在大规模应用时带来的副作用，让业务开发同学们可以更关注在业务的同时，也可以通过spa高效的开发。所以miox诞生时的目标就不是一个简单的router，而希望是一套完整的解决方案。

当然，miox目前开源的部分并不能解决上述所有问题，我们还有大量内部的最佳实践沉淀。之后，miox将会做为核心框架，围绕它会陆续给大家带来一整套移动端spa解决方案。

这就是miox的初心和定位。

沈赟杰白米Ⅲ级

我们团队开源的Miox其实专注在路由容器上，可以通过Miox带你走进动态路由的世界 - 掘金这篇文章来简单了解下。
我们也在不断进行更新，包括各种实战Demo的编写，让用户能够快速上手。
# Miox答疑解惑基于页面的服务体系

**[Miox](51nb/miox)**发布以来，很多小伙伴都在问一个问题：Miox与[react-router@4.x](ReactTraining/react-router)到底有什么不同？我在[掘金](Miox带你走进动态路由的世界 - 掘金)和[知乎](如何评价51信用卡开源的Miox框架？)上都回答了一些，但是不够完整，那么我就来解释下它们的不同点。

这个问题很简单，也许是由于我之前文章标题取的是`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到底是要从缓存中拿还是需要重新创建。算法可能比较复杂，您可以通过[这里](https://github.com/51nb/miox/blob/master/src/miox/src/lib/render.js)看下源码。我们会将浏览过的页面缓存起来，表现为节点的堆叠。当然我们也不会那么傻，节点堆叠多了，也是要影响性能的。所以在Miox启动服务之前，我们就会让用户设置一个`max`属性，让用户来选择我们最大缓存多少个页面。当每次渲染后，发现页面缓存堆栈超过了这个最大的指，那么我们会通过`最远距离`关系将那个需要被删除的页面（对象）给删除，达到一种动态平衡。

再说一点比较深入的，其实我们的缓存不仅仅存在于页面堆栈，还在于您渲染的模板上，您可以通过`webview.dic`属性来看下这个模板上被缓存的一些特征。我们的原则是，路由不对应具体页面，而是对应具体页面的`constructor`原型对象。这个点，很多小伙伴由于没有看过`render.js`的实现而没能理解。这个才是缓存特性的关键，理论来讲，路由不对应页面，而是对应生成页面的原型对象。

# 最后

大家都会问，我怎么开始写一个Miox的项目呢？

我们提供了脚手架之外，还会提供一系列的教程帮助大家来熟悉Miox的编写。最近我们有一个仓库，就是来介绍Miox的简单使用，[点击这里查看](51nb/miox-demo-basic-use)。

旧城白米Ⅲ级

利益相关。
个人认为 miox 在技术思想上有很大的创新。
刚接触 miox 时，我也将 miox 与 *-router 进行对比地理解，这是很容易的下意识行为。然而，这是一种误区，router 仅仅是 miox 中天然而有的特性，但 miox 比 router 的立意更加高远。miox 是一个完整的 SPA 运行环境，它如浏览器管理传统的 web page 一般管理 SPA 中的逻辑页面，miox 对逻辑页面的重视提升到了显式的层面，同时它将运行环境的职责和 router 做了非常明确的区分，有助于开发大型复杂 SPA 时降低协作成本。
长期以来，w3c 组织对于发展单页应用都不太感兴趣，很多的底层模型也高度倾向于多页面应用场景。我认为 miox 在一定程度上很好地填补了这部分空白，让开发者不再与浏览器API直接交互，而转向与 miox 的API 交互，屏蔽了多页网站和单页应用间的许多细微差异，而且也简化了概念，间接减低学习成本。

notomorow 白米Ⅲ级

看了一下掘金的文章，感觉miox把路由单独功能抽出来作为一个中间件的思想还是可以的，这样其实挺符合前端项目是由一个个小而精的组件搭配组合而成的理念。而且路由这一块其实真的算前端开发中比独立而整的一块功能，所以这种组件的拆分细度还是可行的。但还没具体使用，不知渲染性能是否真的能够和自带的路由相比。

夏吕俊白米Ⅲ级

简单的看了下 miox-css 的实现，猜想 miox 应该就是把页面当作 modal 来玩的。。。我之前也有这种想法：Page Router · 云中红瞳的博客。。。。不过还不清楚的是它的 engine 是怎么做的？在切换页面被隐藏的页面的 react 组件有没有被销毁，如果是销毁了那怎么保证 dom 不销毁，如果没销毁，那它就应该还是活的，是不是它就仍然会因为 store 变化而变化。。。modal 层级一多，性能就会下降。我的博客里 modal 是使用递归路由来做的，所以如果想删除太底层的页面，只保留上层的页面，就需要做到销毁父组建但不销毁子组件，这在 react 里是做不到的。。。那这里miox 又是怎么做的？是不是 ReactDOM.render(<Page1 store={store}/>, page1); ReactDOM.render(<Page2 store={store}/>, page2); 这样，让 Page 级别的组件就是最高层组件，这样来做到选择销毁太低层的 Page。。。如果是这样的话，那它就是与 react-router 彻底的不兼容（当然，这不是问题），它就是一个框架，而不是一个可以轻松使用的工具组件（当然，它本身定位也是框架）。。。

整体说来，挺看好这东西。。。只是如果它的逻辑真的与我的猜想一致的话，会有点遗憾不能继续使用 react-router 的面向组件的路由而不是面向页面的路由的这种哲学。。。。。。。
如果 react 本身能做到销毁父组建，但不销毁子组件这种的话，那就好了。。。