前端/客户端有什么办法来处理后端/服务端返回的不规范数据吗

[mouyase]

本人是前端，技术栈 ts/java/oc ，web 和 app 都在做。



现在经常遇到后端返回的值让人难以琢磨。



比如同样都是表示是/否，或者打开/关闭两种状态，有点时候返回值是 0/1 ，有时候是 1/0 ，有的时候是 1/2 ，有的时候是 true/false ，有的时候是"on"/"off"，还有的时候干脆就是为否就没有这个字段了。



或者是同样都是用户 id ，有时候字段叫做 user_id ，有时候叫 UserID ，有时候就只叫 id 。



然后在业务逻辑中经常会出现从不同接口拿到的同一个值，但是是在同一处 UI 显示。就导致 ts 类型定义得定义好几种不同的类型用来兼容。



各位大佬们有什么好的办法来处理这种情况吗？

[label]

本质上还是由于项目的不断更新迭代, 新的开发人员不清楚旧业务的命名, 不同的开发人员, 命名的习惯不一样

[bddxg]

直接工作群骂, 让他贷 2 万找个培训班学一学

[doublestart]

@bddxg 这都被你看出来了, 贷款 2 万还没还清呢 ......

[xiangyuecn]

这个看情况吧，只要不是同一个接口里面会变来变去，都不是问题

true | false 这个：如果有文档，遵照文档，其实没啥可喷的🐶

用户 id 这个，问题不大，屎山堆多了就这样了，数据库里面估计也是这样🐶

最大的问题是你在这屎山上用 ts ，自找麻烦，换做 vanilla js 早下班回家抱老婆了😂

[devilweime]

需求今天出，明天就要发版，还管你那么多，照数据库输出弄，出问题查起来还简单，程序运行 bug 还少点

[liubiantao]

先把锅甩出去，在页面上提示接口返回值错误，让测试、领导、老板等看到，让他们遇到 bug 先去找后端，最不济两人一起找，要加班一起加

[woodfizky]

你需要反思下为什么你会跟这样的后端同事共事🐶

正常点的前后端分离架构一般都会提前商定好前后端交互的数据结构和规范的。

如果没有，你们技术 leader 要么不存在要么不干活。

[kongcc]

我司后端就是这种情况，😭

[FakerLeung]

@Baymaxbowen #19
我还见过 "null" 和 "[]"，排查了大半天，就说为啥保存，打印出来也没问题，踏马的居然是字符串！

[MarioLuo]

根据个人遇到的情况来看，大致是项目没有约定规范、不同开发按照自己的命名和风格随意、新人对项目不熟悉、偷懒对第三方返回数据没有转换，说白了还是技术水平问题，但是归根结底还是管理问题。我的建议了就是提出问题和后端人员，讲道理方式沟通。

[xing7673]

没遇到过这样的后端
楼上 2 位显眼包已经 b 了

[RoshanWu]

自己写一个请求库，一个数据转换库作为其依赖，我是这么实现的。这样不仅可以统一 truth 的判断，也能统一 Response 的结构体。

[linl1n]

如果必须上强度就只有试试 json schema ，其他情况只能跟着 api 文档定义好 responseType ，比如公司后端 go ，经常出现 api 文档返回是个数组为空，但 go 没处理返回了 null ，null.map 直接报错， 只好前端规范了在请求到的数组类型.map .filter 等操作之前必须加 ? , 其他对象类型在解属性时加{}

[linl1n]

不同接口拿到不同字段，态度严肃点直接让后端统一字段，否则只有自己加个处理函数转一下，还是得看沟通

[hefish]

前端自己不会判断哒，实在不行用 ts 重写后端。

[ZeroDu]

@bianhui #65 赞成。我觉得有些人太理想化了。

[alleluya]

@coderzhangsan 除了问清楚 还得做好留痕 省的最后领导问责对方甩锅不承认

[kristofer]

哈哈哈，真就是娱乐圈啊。

[leaflxh]

按照文档来

后端写好 openAPI ，前端生成工具生成请求代码，一把梭

[leaflxh]

哎，戾气太重

以后这种问题建议前后端团队打一架，谁赢了谁说的算（