koa返回json数据_Koa-spring：后端太忙，让我自己写服务(下)

关于这篇文章

• 自定义装饰器
• 继承的应用
• 涨过的见识

如果你感兴趣，可以fork项目，自己体验一下
Koa-spring：closertb/koa-spring
related-client: closertb/koa-spring-client
技术栈：koa + Sequelize + routing-controllers + typescript
上一篇：Koa-spring：后端太忙，让我自己写服务(上) · Issue #40 · closertb/closertb.github.io

自定义装饰器

去年我特别看好装饰器在前端的发展前景，直到React开始推崇Hooks，并持续大热，这严重压缩了Javascript中类的应用（没记错的话：上一次是函数式编程）。而现阶段的装饰器是依赖于类的，在未来可能这种局面可能会被改变，一种全新的装饰器语法会诞生。还未了解过装饰器的，可以看一下[阮一峰：ES6入门之装饰器](ECMAScript 6入门)

在上一篇文章写到利用中间件来处理那些重复的逻辑，但遗憾的是，不是所有的重复逻辑都适合用中间件来处理。比如上一章讲过Sequelize的查询结果是一个包装过的结构，在赋值成响应体时，需要调用toJson方法或则使用JSON.stringify格式化。开始在查询时设置了{ query: { raw: true }}, 查询的结果没有被包装,比较干净，所以开始是直接使用中间件来处理分页：

async function PaginationMiddleWare(ctx: any, next: (err?: any) => Promise<any>): Promise<any> {
  const { request: { body = {}, query = {} } } = ctx;
  const params = Object.assign({}, query, body);
  const { pn = 1, ps = 10 } = params;
  const data = ctx.body || [];
  const total = data.length || 0;
  const count = pn * ps;
  const isEnough = total > count || total > (pn - 1) * ps;
  ctx.body = {
    datas: isEnough ? data.slice((pn - 1)*ps, total > count ? ps : undefined) : data.slice(0, ps),
    total,
    pn: isEnough ? +pn : 1,
    ps: +ps
  }
  await next();
}

但由于后面意识到这种暴力查询，面对成千上万条数据时，慢的会让人觉得这是个bug；加上对属性getter方法的需求，不得不放弃{ raw：true }这个设置；另外的考虑就是：搜索请求参数的处理。为了不重复写上面的逻辑，所以考虑用装饰器来处理，即先从查询数据获取请求的目标数据（一般分页就10条或20条数据），再对目标数据进行格式化