作为前端，你肯定经常有这样的烦恼：我明明只需要这几个字段，结果你全部给我返回了，何必呢？今天我发了一个包 scopedquery 以解决这个问题。这里 scoped 的意思是“限定的”，也就是你进行的查询是在限定的内容里面。它基于一个新的语言，样子大概如下：

query "https://xxx.com/api/articles/:id" -> {
  article_title
  create_time: date('YYYY-MM-DD')
  article_content
  view_count: number
  comments: [
    {
      comment_author
      comment_content
      comment_time: data('YYYY-MM-DD')
    }
  ]
}

上面这段代码所表达的意思是，往 "http...." 发送了一个请求，这个请求要求返回的结果的形状，以及节点上对节点值的格式，需要按照 -> 后面的内容进行返回。

它看上去和 graphql 有点像，但又很不同。它是一个描述性语言，类似 JSON，而非一个编程性语言，即 graphql。graphql 虽然很好，但是，它依赖底层的建设和比较难理解的语法组织。而 ScopedQuery 则纯粹是为了解决数据裁剪而生，不负责底层库的查询，因此，它更轻量，且开箱即用。

npm i scopedquery

安装好后，在业务代码中这样写作：

import { Query } from 'scopedquery'

const data = await Query.run(`
  query "http..." -> {
    // 支持注释
    // 裁剪后的内容
  }
`)

默认情况下，内部会使用全局的 fetch 进行 ajax 请求，但是你可以自己定义：

const query = new Query({
  fetch(url, params) {
    // ...
  }
})
const data = await query.run(`...`)

在 node 端，可以使用 Query.parse 方法直接裁剪数据：

const data = Query.parse(dataFromBackend, `{
  name: string
  age: number
}`)

冒号后面的 string, number 看上去是类型，实际上是格式化工具，它们可以被自定义，让开发者自己觉得不同情况下怎么返回值。

基于 webpack 的能力，我们可以把这些 query 文本单独保存，这样我们可以极为清晰的了解每一个接口对于前端而言，需要的是哪些内容，且有值描述，对于前后端而言，都可以作为参考，辅助前后端在开发过程中进行沟通。