最近前后端干的厉害,后端返回数据的时候,有些值是空往往就返回 null,这些往往是引用类型类型。
前端表示对象就算是空那就返回一个空对象,后端表示前端都不做数值判断的吗,现在是引入 lodash 或者自己写一个公用的判断方法。但依然不爽,后端应该不应该保持数据类型一致呢
1
erwin985211 OP 可能解释的不清楚,就是这个值本来是对象、数组。现在全是 null 了。差不多就是这个意思
|
2
misaka19000 2021-01-04 10:54:54 +08:00
我觉得不应该
|
3
clf 2021-01-04 11:00:34 +08:00
如果空对象是不允许的,那么后端抛出异常,如果是允许的,前端在 null 的时候显示该显示的东西。
|
4
draguo 2021-01-04 11:02:07 +08:00
动态语言返回空对象,需要提前定义变量类型,可是不用定义变量类型是我用动态语言最大的原因啊
|
5
Mithril 2021-01-04 11:03:18 +08:00
nullable 本身是一种状态,它跟空值是不一样的。一个是根本没有这东西,另一个是有这东西,但是空的。
最简单的,空字符串和 null,空数组和 null,这都是不同的状态。就看你们的约定里,要不要考虑这种状态了。 我做后端比较多,后端的很多规范里会要求尽量避免使用 null,不然容易炸出来异常。这时候大部分传递的对象或者数组都直接去判断是否为空,而不需要先判断 null 再判断是否为空了。 |
6
cmdOptionKana 2021-01-04 11:07:05 +08:00
多数情况下尽可能避免使用 null 应该比较好。但这事情没有定论。
|
7
sujin190 2021-01-04 11:08:35 +08:00 2
空{}有歧义的吧,分不清空数据还是空值,返回 null 才是合理的,空数组还问题不大,但是返回空{}不返回 null 真是个坑
|
8
woodensail 2021-01-04 11:11:22 +08:00
不指望后端,反正我是自己在前端定义 schema,然后自动做数据清洗。
比如某个字段该是数字,管你是传 null 还是字符串,甚至连父级都不存在,我全处理好然后转为 0 。 |
9
imdong 2021-01-04 11:11:53 +08:00
关于用户昵称的笑话:
null 、 "" 、 "null" 如果不用 null,你怎么知道用户昵称时被设置为了空,还是就是空的? |
10
baiyi 2021-01-04 11:13:23 +08:00
空值和 nil 本来就代表两种不同的内容,无论是在代码里,还是数据里
|
11
erwin985211 OP @sujin190 我也同意{}布尔值是 true,在判断上是有问题。感觉都挺懒的,不知道大厂这么做的
|
12
erwin985211 OP @imdong 这种基本类型的为 null 没啥问题的,真的有问题的还是对象。不晓得大厂怎么做的
|
13
tjsdtc 2021-01-04 12:10:55 +08:00
optional chaining 了解一下,升级下 babel7
|
14
opengps 2021-01-04 12:17:54 +08:00 via Android
根据情况,有些场景是个兼容处理,比如,布尔类型用来表示男女,完全可以支持 null 来表示未设置,也可以强制指定默认值为某个结果,这取舍完全看业务需求,
甚至有的场景下,业务要求在男女不填这三个结果之外填写更多类型,这时候则需要用 int 之类的代替 |
15
xiaochong0302 2021-01-04 12:24:07 +08:00
我一般这样,事先都定义了默认值:
单条记录空就返回{} 多条记录空就[] |
16
Sapp 2021-01-04 12:28:28 +08:00
查询一个列表 返回空数组,查询单个对象返回 null
用 ts 可以在工程化上动动脑筋,比如读取后端接口自动生成调用接口函数,里面写好返回类型,如果不用可以试试"可选链",后端返回的数据全部用可选链,比如 res?.data?.user?.name 。 最好的还是用 ts,用 ts 他就算给你返回个布尔值都无所谓,反正你这里类型是可控的,出事甩锅给他 |
17
holystrike 2021-01-04 12:29:29 +08:00
后端接口多花 1 天做数据格式统一
前端有 4 种客户端,每个客户端花 1 天时间做数据整理, 你是老板,你选择哪种工期安排? |
18
Sapp 2021-01-04 12:30:25 +08:00
另外这个事真没啥好打架的,就算后端返回不规范,前端可以在响应拦截器里做手脚,比如把后端返回的 {} 都变成 null,或者把 null 变成 {}
|
19
otakustay 2021-01-04 12:31:13 +08:00
默认值 > null > 空对象
空对象是最惨的,对象里的属性全是 undefined ?在前端类型上还要处理 undefined,如果是 嵌套的多层对象结果,不死得更惨 |
20
raaaaaar 2021-01-04 12:39:44 +08:00 via Android
规范+文档才是真的
|
21
hoyixi 2021-01-04 12:43:03 +08:00
空对象和 null 完全不同的意思,我倾向于 null
|
22
Mystery0 2021-01-04 12:57:12 +08:00 via Android
空对象到处是坑,如果返回给前端的接口数据为空返回的空对象,假如后面有一个新服务也调用了这个接口,那么 rest 请求成功了,得到一个空对象,这个方法倒是不报 npe 了,一用这个对象的某个值就报 npe,而且一般都是在 rest 接口调用的 service 做为空判断,谁还管你里面的值是 null,无形之中增加了排错的逻辑
|
23
Mystery0 2021-01-04 12:58:33 +08:00 via Android
现在负责的系统里面,有些接口返 null,有些接口返空对象,没办法去搞,直接全部不可信,然后就导致代码里面到处是判空的代码
|
24
Maboroshii 2021-01-04 13:11:34 +08:00
null 和{}意义不同,约定好就行
|
25
icyalala 2021-01-04 13:25:41 +08:00
@holystrike 客户端开发要是无条件相信后端返回的值,那迟早会出现崩溃,这种客户端要不得。
|
26
erwin985211 OP @Sapp 也不是打架,一般公司后端还是比前端腿出的,就是想问问大家这么做的
|
27
wr516516 2021-01-04 13:58:18 +08:00
我以前公司也是经常因为这个吵,但是基本上还是返回 null.
我感觉我没理由去给你返回一个空对象, 你要是要求我给你一个空对象,为什么不要求 mysql 返回给我一个空对象 要是有排空的逻辑,就另外处理了... 不过当时是小公司,一共二十几个人,都是看心情.... |
28
huijiewei 2021-01-04 14:05:45 +08:00
null
[] 0 '' false |
30
ChoateYao 2021-01-04 16:20:53 +08:00
其实我是想支持 null,但是根据我以往对接 iOS 的经验,null 在 iOS 那边处理有点麻烦,后面就统一用""代替了。
我也不是做 iOS 的,但是经过我搜索 iOS 对 null 的处理,确实有点麻烦。 |
31
hxtheone 2021-01-04 17:49:02 +08:00
个人倾向于使用 null, 多出一个确定的空值可以表达更多的状态, 而且很多时候'没有值'和'有值但为空', 在逻辑里完全是两种含义
|
32
chairuosen 2021-01-04 17:51:57 +08:00 1
Object 这个场景下 null 是正确的。
但 Array 就不一样了,我对接的大部分后端,列表查询为空时也返回 null,其实应该是[]。 |
33
xiangyuecn 2021-01-04 17:55:28 +08:00
赞同#32 楼,对象里面有 null,很合理。 空数组如果用 null 就扯几把蛋
|
34
Elethom 2021-01-04 20:21:16 +08:00 via iPhone
null 和空数据本来就不是一回事。举几个例子:
未设置项:null 某项设置为空:"" 按某条件搜索无结果:[] 如果前端 /客户端说 xx 不好实现让返回 yy,建议一律当场开除。 |
35
Elethom 2021-01-04 20:22:17 +08:00 via iPhone
@xiangyuecn
早年还见过 true/false 返回 1/null 的。( |
36
hhyygg 2021-01-05 01:01:32 +08:00 via Android
所以还是要定好编码规范啊。不然就吵没完了。
|
37
hbhswj 2021-01-05 09:40:20 +08:00
null 和 0 不一样的含义
|
38
mshadow 2021-01-05 10:51:54 +08:00
数字默认 0,字符串默认"",布尔默认 false,数组默认[],对象默认 null,
前面几个应该没太多异议,空对象不建议{},不然使用每个属性的时候都得判空 |