前端同事总是问我要 form 表单的枚举,多个我能理解,为什么性别和有些 3-5 个字段的类型也要返回呢。这些接口数量多了不是增加服务端压力,并且会阻塞后面的请求吗?
1
null113 2020-11-06 11:19:02 +08:00
让他们写个静态的 json
|
2
geebos 2020-11-06 11:28:08 +08:00
免得后面枚举变了还要改代码吧,谁知道后端会用什么奇葩的枚举值
|
3
lower 2020-11-06 11:29:29 +08:00
搞个字典表,一个接口搞定,上缓存
|
4
Qcui 2020-11-06 11:40:33 +08:00
性别之类不会变的枚举可以前端固定,其它的还是老实给接口吧,谁知道后面会怎么变。
|
5
zarte 2020-11-06 11:53:52 +08:00
考虑太多呗,自己建站的时候就会能省则省了。
|
6
Curtion 2020-11-06 12:00:22 +08:00
这个看业务吧,和数量无关;性别的话讲道理不需要接口
|
7
zoharSoul 2020-11-06 12:06:22 +08:00
放 Apollo 上, 让前端自己拿去
|
8
IvanLi127 2020-11-06 12:27:48 +08:00 via Android
我只知道前端用接口查也挺折腾的
|
9
zealinux 2020-11-06 12:31:43 +08:00
其实性别也真需要接口返回的,
不过可以放在缓存里。 太多的教训了,前端写死是大忌。 |
10
hb0730 2020-11-06 14:07:52 +08:00
数据字典表
|
11
kanezeng 2020-11-06 14:53:10 +08:00
这玩意前端确实不要固定,谁也不知道以后怎么样不是。比如性别吧,最开始大家都是两个选项,后来有的就加了个保密什么的,发展到现在,你看 Facebook 就这个框有 56 个选项。但是你后端可以放缓存减少负担(然后个人觉得有些选项前端也可以一次性先从后端获取,然后缓存在 localstorage 之类的地方)。
|
14
uselessVisitor 2020-11-06 23:59:25 +08:00 via Android
搞一个数据字典表,然后缓存在 redis 里,前端每次只要一次请求获取所有的字典
|
15
nekochyan 2020-11-07 10:34:17 +08:00
我们是单独一个接口请求配置信息存本地,每次登陆 hash 一下不同就重新下发
|
16
TomVista 2020-11-09 09:10:59 +08:00
谷歌注册的性别选项告诉我们,人的性别可能发生变化🐶
|