有没有这样一个 lib，可以帮 js 前端“清理”后台 api 返回的数据结构？

[wxsm]

比如说，按照约定后台应该返回这样的一个数据结构：

{
  a: {
    b: [] // 某数组
  },
  c: '某字符串'
}

但是有时候事与愿违，团队开发者一多，后台往往会返回缺斤少两或者奇怪的东西，导致错误，比如

{
  a: null,
  c: null
}

或者：

{
  a: {
    b: null
  }
}

我知道可以通过逐个字段判空来解决，但这太麻烦了，而且一不小心就漏掉了什么地方。有没有一种工具，可以对这样的数据按照约定结构进行补全呢？

比如：

• 数组默认为 []
• 对象默认为 {}
• 字符串默认为空字符串
• 数字默认为 0

[muziyue]

想法不错,不过遇到这种情况找后端打一架比较管用

[orancho]

Protobuf 请。

[264768502]

这个？
https://juejin.im/entry/5a328f1cf265da431f4b19df

[LancerComet]

看了上文，实际上如果接口很多业务很个性，为了确保类型安全还是要写很多业务相关的过滤器，目前看来并没有什么特别好的偷懒方法.

在下所在项目目前的实践是为关键服务的接口写过滤器 + TS Definition，并会在代码审核时检查，说白了就是这个任务一点没省，只不过是平均了罢了.

期待有更好的偷懒实践.

[wxsm]

@muziyue 打得了现任打不了下一任，自己不做处理总会有被坑的一天。

@orancho 这个好像是新的数据交换结构，新项目可以考虑，可是现有的基于 JSON 的项目怎么搞？

@264768502 好像不是我想要的东西。

[crysislinux]

json schema 校验，放在后端的出口就好了，不符合 schema 的就直接报错让后端改，不然你补全了有什么用，你补的了代码补不了逻辑。

[orancho]

@wxsm

现有项目的话只能靠沟通和管理了，当然你也可以试着迁移一下。
P.S. 我司自从尝了 protobuf 的甜头之后大部分项目都迁移了过去。

[zjsxwc]

必须要前后端都有一个约定才能解决楼主问题，不然缺斤少两的情况下，也无法判断出缺的那个字段是补成[]还是{}还是""还是 0

[zjsxwc]

2 个办法：

1. 类似 protobuf 辅助在代码上统一，*约定*通过编写 protobuf 消息文件来指定， 要改原来的代码

2. 用中间转发网关，*约定*通过在这个中间网关里通过图形界面配置，我记得有开源的

[maemual]

我觉得在后端数据无法通过工具约束的情况下，遇到这种错误的数据直接报错更好一点。否则用默认值，当作正常数据再写回到后端的话，以后坑更大。

[Torpedo]

之前的项目就是这样。服务代理了很多接口，接口文档都没有。他们的数据总是不稳定。
其实我理解这个问题有两点：
1.不管什么库，按照你说的那么做都要把数据结构描述一遍。
2.找出不符合的情况不难，那么我一个一个写呢。但是比较大的问题是：这么多字段，每个出问题了都是一个异常处理逻辑。

基于以上两点，1 明显应该是大家约定的，但是却约定不好。2 一个个写太多。
我们用了 react，所以比较好的方法是用 react16 的 componentDidCatch，封了一个高阶组件来统一处理页面模块出错。

本来这问题就是数据问题，哪个数据问题就修复哪个数据就行了。只是前端这里处理，不因为他们的数据问题让整个页面挂掉就可以了

[cenqingbo]

@crysislinux 作者贴出来的错误的 null 返回也属于正确的 json shema 吧

[Terry05]

没啥好偷懒的，一个个节点去判断

[will0404]

这绝对是后端的锅啊，为什么要前端做？在 api 输出的地方做类型检查就好了，前端加个 lib 增加多少流量考虑过吗

[wxsm]

@zjsxwc 你说的这种“网关”其实不切实际。这样一来架构会变得极其脆弱。

@maemual 主要是用来显示的这一块，不往回发。一报错测试马上就找到前端来了，各种背锅。

@Torpedo 你这个办法看起来不错，我这边也是 RN，明天试一下。谢谢。

[wxsm]

@will0404 组织已经决定了，这个锅就 tm 前端来背。

[sensui7]

参考这个视频: <amp-youtube data-videoid="nSKp2StlS6s" layout="responsive" width="480" height="270"></amp-youtube>

[jzhang]

https://github.com/paularmstrong/normalizr

[isbase]

@Torpedo 我觉得如果是后端数据的问题，那就该正常抛出错误让页面挂掉，否则你 catch 了错误继续运行下去可能会导致更严重的问题

@wxsm 平时写代码的时候可以多用 ES6 的函数参数默认值

[wanganjun]

为啥没人说 graphql