V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX 提问指南
erwin985211
V2EX  ›  问与答

后端返回的数据空值时,要不要保持数据类型一致

  •  
  •   erwin985211 · 2021-01-04 10:49:51 +08:00 · 4254 次点击
    这是一个创建于 1420 天前的主题,其中的信息可能已经有所发展或是发生改变。

    最近前后端干的厉害,后端返回数据的时候,有些值是空往往就返回 null,这些往往是引用类型类型。

    前端表示对象就算是空那就返回一个空对象,后端表示前端都不做数值判断的吗,现在是引入 lodash 或者自己写一个公用的判断方法。但依然不爽,后端应该不应该保持数据类型一致呢

    38 条回复    2021-01-05 10:51:54 +08:00
    erwin985211
        1
    erwin985211  
    OP
       2021-01-04 10:50:49 +08:00
    可能解释的不清楚,就是这个值本来是对象、数组。现在全是 null 了。差不多就是这个意思
    misaka19000
        2
    misaka19000  
       2021-01-04 10:54:54 +08:00
    我觉得不应该
    clf
        3
    clf  
       2021-01-04 11:00:34 +08:00
    如果空对象是不允许的,那么后端抛出异常,如果是允许的,前端在 null 的时候显示该显示的东西。
    draguo
        4
    draguo  
       2021-01-04 11:02:07 +08:00
    动态语言返回空对象,需要提前定义变量类型,可是不用定义变量类型是我用动态语言最大的原因啊
    Mithril
        5
    Mithril  
       2021-01-04 11:03:18 +08:00
    nullable 本身是一种状态,它跟空值是不一样的。一个是根本没有这东西,另一个是有这东西,但是空的。
    最简单的,空字符串和 null,空数组和 null,这都是不同的状态。就看你们的约定里,要不要考虑这种状态了。
    我做后端比较多,后端的很多规范里会要求尽量避免使用 null,不然容易炸出来异常。这时候大部分传递的对象或者数组都直接去判断是否为空,而不需要先判断 null 再判断是否为空了。
    cmdOptionKana
        6
    cmdOptionKana  
       2021-01-04 11:07:05 +08:00
    多数情况下尽可能避免使用 null 应该比较好。但这事情没有定论。
    sujin190
        7
    sujin190  
       2021-01-04 11:08:35 +08:00   ❤️ 2
    空{}有歧义的吧,分不清空数据还是空值,返回 null 才是合理的,空数组还问题不大,但是返回空{}不返回 null 真是个坑
    woodensail
        8
    woodensail  
       2021-01-04 11:11:22 +08:00
    不指望后端,反正我是自己在前端定义 schema,然后自动做数据清洗。
    比如某个字段该是数字,管你是传 null 还是字符串,甚至连父级都不存在,我全处理好然后转为 0 。
    imdong
        9
    imdong  
       2021-01-04 11:11:53 +08:00
    关于用户昵称的笑话:

    null 、 "" 、 "null"

    如果不用 null,你怎么知道用户昵称时被设置为了空,还是就是空的?
    baiyi
        10
    baiyi  
       2021-01-04 11:13:23 +08:00
    空值和 nil 本来就代表两种不同的内容,无论是在代码里,还是数据里
    erwin985211
        11
    erwin985211  
    OP
       2021-01-04 11:14:16 +08:00
    @sujin190 我也同意{}布尔值是 true,在判断上是有问题。感觉都挺懒的,不知道大厂这么做的
    erwin985211
        12
    erwin985211  
    OP
       2021-01-04 11:17:57 +08:00
    @imdong 这种基本类型的为 null 没啥问题的,真的有问题的还是对象。不晓得大厂怎么做的
    tjsdtc
        13
    tjsdtc  
       2021-01-04 12:10:55 +08:00
    optional chaining 了解一下,升级下 babel7
    opengps
        14
    opengps  
       2021-01-04 12:17:54 +08:00 via Android
    根据情况,有些场景是个兼容处理,比如,布尔类型用来表示男女,完全可以支持 null 来表示未设置,也可以强制指定默认值为某个结果,这取舍完全看业务需求,
    甚至有的场景下,业务要求在男女不填这三个结果之外填写更多类型,这时候则需要用 int 之类的代替
    xiaochong0302
        15
    xiaochong0302  
       2021-01-04 12:24:07 +08:00
    我一般这样,事先都定义了默认值:
    单条记录空就返回{}
    多条记录空就[]
    Sapp
        16
    Sapp  
       2021-01-04 12:28:28 +08:00
    查询一个列表 返回空数组,查询单个对象返回 null

    用 ts 可以在工程化上动动脑筋,比如读取后端接口自动生成调用接口函数,里面写好返回类型,如果不用可以试试"可选链",后端返回的数据全部用可选链,比如 res?.data?.user?.name 。

    最好的还是用 ts,用 ts 他就算给你返回个布尔值都无所谓,反正你这里类型是可控的,出事甩锅给他
    holystrike
        17
    holystrike  
       2021-01-04 12:29:29 +08:00
    后端接口多花 1 天做数据格式统一

    前端有 4 种客户端,每个客户端花 1 天时间做数据整理,

    你是老板,你选择哪种工期安排?
    Sapp
        18
    Sapp  
       2021-01-04 12:30:25 +08:00
    另外这个事真没啥好打架的,就算后端返回不规范,前端可以在响应拦截器里做手脚,比如把后端返回的 {} 都变成 null,或者把 null 变成 {}
    otakustay
        19
    otakustay  
       2021-01-04 12:31:13 +08:00
    默认值 > null > 空对象
    空对象是最惨的,对象里的属性全是 undefined ?在前端类型上还要处理 undefined,如果是 嵌套的多层对象结果,不死得更惨
    raaaaaar
        20
    raaaaaar  
       2021-01-04 12:39:44 +08:00 via Android
    规范+文档才是真的
    hoyixi
        21
    hoyixi  
       2021-01-04 12:43:03 +08:00
    空对象和 null 完全不同的意思,我倾向于 null
    Mystery0
        22
    Mystery0  
       2021-01-04 12:57:12 +08:00 via Android
    空对象到处是坑,如果返回给前端的接口数据为空返回的空对象,假如后面有一个新服务也调用了这个接口,那么 rest 请求成功了,得到一个空对象,这个方法倒是不报 npe 了,一用这个对象的某个值就报 npe,而且一般都是在 rest 接口调用的 service 做为空判断,谁还管你里面的值是 null,无形之中增加了排错的逻辑
    Mystery0
        23
    Mystery0  
       2021-01-04 12:58:33 +08:00 via Android
    现在负责的系统里面,有些接口返 null,有些接口返空对象,没办法去搞,直接全部不可信,然后就导致代码里面到处是判空的代码
    Maboroshii
        24
    Maboroshii  
       2021-01-04 13:11:34 +08:00
    null 和{}意义不同,约定好就行
    icyalala
        25
    icyalala  
       2021-01-04 13:25:41 +08:00
    @holystrike 客户端开发要是无条件相信后端返回的值,那迟早会出现崩溃,这种客户端要不得。
    erwin985211
        26
    erwin985211  
    OP
       2021-01-04 13:32:30 +08:00
    @Sapp 也不是打架,一般公司后端还是比前端腿出的,就是想问问大家这么做的
    wr516516
        27
    wr516516  
       2021-01-04 13:58:18 +08:00
    我以前公司也是经常因为这个吵,但是基本上还是返回 null.
    我感觉我没理由去给你返回一个空对象,
    你要是要求我给你一个空对象,为什么不要求 mysql 返回给我一个空对象
    要是有排空的逻辑,就另外处理了...
    不过当时是小公司,一共二十几个人,都是看心情....
    huijiewei
        28
    huijiewei  
       2021-01-04 14:05:45 +08:00
    null
    []
    0
    ''
    false
    Leonard
        29
    Leonard  
       2021-01-04 14:13:01 +08:00
    @imdong #9 不允许设置空昵称就行了
    ChoateYao
        30
    ChoateYao  
       2021-01-04 16:20:53 +08:00
    其实我是想支持 null,但是根据我以往对接 iOS 的经验,null 在 iOS 那边处理有点麻烦,后面就统一用""代替了。

    我也不是做 iOS 的,但是经过我搜索 iOS 对 null 的处理,确实有点麻烦。
    hxtheone
        31
    hxtheone  
       2021-01-04 17:49:02 +08:00
    个人倾向于使用 null, 多出一个确定的空值可以表达更多的状态, 而且很多时候'没有值'和'有值但为空', 在逻辑里完全是两种含义
    chairuosen
        32
    chairuosen  
       2021-01-04 17:51:57 +08:00   ❤️ 1
    Object 这个场景下 null 是正确的。
    但 Array 就不一样了,我对接的大部分后端,列表查询为空时也返回 null,其实应该是[]。
    xiangyuecn
        33
    xiangyuecn  
       2021-01-04 17:55:28 +08:00
    赞同#32 楼,对象里面有 null,很合理。 空数组如果用 null 就扯几把蛋
    Elethom
        34
    Elethom  
       2021-01-04 20:21:16 +08:00 via iPhone
    null 和空数据本来就不是一回事。举几个例子:
    未设置项:null
    某项设置为空:""
    按某条件搜索无结果:[]

    如果前端 /客户端说 xx 不好实现让返回 yy,建议一律当场开除。
    Elethom
        35
    Elethom  
       2021-01-04 20:22:17 +08:00 via iPhone
    @xiangyuecn
    早年还见过 true/false 返回 1/null 的。(
    hhyygg
        36
    hhyygg  
       2021-01-05 01:01:32 +08:00 via Android
    所以还是要定好编码规范啊。不然就吵没完了。
    hbhswj
        37
    hbhswj  
       2021-01-05 09:40:20 +08:00
    null 和 0 不一样的含义
    mshadow
        38
    mshadow  
       2021-01-05 10:51:54 +08:00
    数字默认 0,字符串默认"",布尔默认 false,数组默认[],对象默认 null,
    前面几个应该没太多异议,空对象不建议{},不然使用每个属性的时候都得判空
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   902 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 28ms · UTC 22:03 · PVG 06:03 · LAX 14:03 · JFK 17:03
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.