Miox哲学思想引出的一些思考

前言：

当我第一次接触AngularJs 1.x的时候，被其声明式渲染，路由系统，单页面，丰富的指令深深吸引。当我发现nodejs正在服务端发挥着耀眼的光芒的时候，又在感叹js的强大。这些年，伴随着Vue，React，Angular的崛起，原先刀耕火种的前端已经逐步退出舞台。更多的带给我们的是一系列工具、脚手架。但是这些东西本不应该是天生就有的，而是标着着前端浪潮的一些进步：

SPA应用的一些感触

现在作为开发者的我们，可能已经习惯每天产出的一些新的框架，每天迭代的一个新的工具，慢慢的就会变得麻木和懒惰。其实有的时候我们更需要的是对问题的一种思考和解决。下面简单记录一些我目前遇到的一些问题的解决方案，在此做一些分享吧：

1. 前端SPA路由思想和 Miox 路由的思想

为什么要使用路由？
传统web开发是每一个请求地址都会请求服务器来进行处理，但是用户有些操作则无需请求服务器，直接页面端修改下逻辑就能达到目的，这种最好使用路由，也许会有疑问：直接使用js处理下不就行了。使用js直接处理这些是可以的，事实上以前我们也这么做，但是这样做不便于用户收藏当前页，因为使用js时并不更新url，但是使用路由时，url也是随着改变的，用户浏览到一个网页时可以直接复制或收藏当前页的url给别人，这种方式对于搜索引擎和用户来说都是友好的。

1. 服务端路由：对于服务器来说，当接收到客户端发来的HTTP请求，会根据请求的URL，来找到相应的映射函数，然后执行该函数，并将函数的返回值发送给客户端。对于最简单的静态资源服务器，可以认为，所有URL的映射函数就是一个文件读取操作。对于动态资源，映射函数可能是一个数据库读取操作，也可能是进行一些数据的处理，等等。以Express为例:

app.get('/users', (req, res) => {
  db.queryAllUsers()
    .then(data => res.send(data))
})

2. 客户端路由对于客户端（通常为浏览器）来说，路由的映射函数通常是进行一些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手段来达到选择组件，比如说组件等。但是在官方的文档上我们可以看到动态路由匹配，其实这是动态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

综合问题的一些思考

前端业务开发完之后，并不是什么事情都没有了，恰巧，开发完业务需求，只是最初的一步。因为我们的页面需要更快更优雅的展示在用户面前，我们还需要更多的东西。

1. 为了让页面能够展示的安全可靠，我们需要不断地测试、预发... 我们需要不断地区分这些环境，生成不同接口环境的代码包...
2. 为了团队协作的规范流程，以及最终发布的代码质量，我们需要不断地gitflow 和 codeReview gitflow
3. 为了让页面更加流畅和迅速的展示，我们需要不断地优化加载资源和页面交互饿了么的 PWA 升级实践
   
4. 为了让用户无感知发布，我们又需要一系列发布规范，有兴趣的可以参考这里：大公司里怎样开发和部署前端代码

这里我基于上述做了一个简单的demo：
Miox + easyMock + 前端部署简化

关于

作者：monkeywang
Miox官方地址：Miox
Miox 文档地址： Miox文档
欢迎关注微信公众号：前端知识铺