前端请教 后端返回数据格式问题

2023-12-11 16:29:01 +08:00
 HeroYang811
本人：前端
对方：后端(外包)
情况：电商项目首页商品列表
问题 1：在多维数组内某些字段含有多个数据的情况下，后端返回的数据格式为字符串，多个则用逗号隔开比如"http://123,http://456,http://789"，然后让我前端去做逻辑处理，也就是说让我将字符串转换为数组再处理。
问题 2：部分类型判断采用中文，比如某个商品类型，name === '类型一号' ，然后根据这个相等的类型去展示对应的内容。
我的前端理解：这也太不规范了吧，很多地方逻辑数据处理全部扔到了前端,而且是在商品首页数据量这么大的地方，难道不会导致页面渲染缓慢吗，并且说：“客户端处理逻辑是用户体验感最好的表现”，偷懒也不能这样吧
结果：浪费时间，我懒得扯了，前端写就写吧

虚心请教，各位后端大牛的看法，
8339 次点击
所在节点    程序员
72 条回复
wu67
2023-12-11 16:39:11 +08:00
第一个问题, 其实谁干都行, 典型的用 mysql 存字符串, 只是他懒得分割而已 (换 pg 存数组就简单粗暴了, pg 大法好). 前端分割其实没太大问题, 累点而已, 你的商城是小程序那就另说, 那玩意的性能和屎一样.

第二个问题, 一言难尽, 很多老旧系统都有, php 的各种商城就是重灾区, 大概是从他的旧代码库里面 c v 了...
xuelu520
2023-12-11 16:41:25 +08:00
部分简单的拆装拼接逻辑给前端，可以降低后端压力。(前端性能都这么强了，这点不算啥)
一般列表都是分页来的，如果数据量大，应该要考虑需求是不是有问题。
总之看你们有没接口规范，没有就怎么合作舒服怎么来
cat
2023-12-11 16:49:00 +08:00
特别讨厌用逗号 , 来隔开的，一旦值本身包含逗号，一分割就乱了
gxy2825
2023-12-11 16:52:26 +08:00
你们公司前端也太好说话了吧，换我们给前端这样的数据早就炸了
op 或许可以问问前端/后端组长的意见？或者其他老员工
awalkingman
2023-12-11 16:52:41 +08:00
@cat 我是特别害怕
gitrebase
2023-12-11 16:53:58 +08:00
问题 1：就像 #1 说的，很有可能是在存“一对多”的数据的时候不想新建一张表，按我的习惯我是会在后端把数据转为数组再传递给前端的

问题 2：用中文 emm 我也不知道行不行，但是用 code 会更好吧
brader
2023-12-11 16:58:30 +08:00
还算正常，我理解是都可以。
还有你说性能的问题，其实影响不大，如果你非要比较个高低，我觉得放服务端转化影响大，因为服务端要面对所有客户端。
Bingchunmoli
2023-12-11 17:03:50 +08:00
@brader 赞同，1. 是需不需要单独处理，前后端都能做的事 看分工，2. 一般用 int ， 不排除一些政企或者老系统喜欢中文需要兼容或者什么的， 数据的一些逻辑处理是可以后端和可以前端的，从性能考虑 优先前端，前端性能“无限”, 还有一种考虑是 后端一个接口支持多端，不同端对应自己业务自己处理， 如果单端，服务器并发不高，前后端都行
lDqe4OE6iOEUQNM7
2023-12-11 17:08:33 +08:00
我也遇到过，筛选 list 列表都让我自己前端写死，还有分页前端来做，还有返回的数据格式，也要我分割，明明穿一个对象就能解决
1016
2023-12-11 17:14:10 +08:00
你这算啥... 我这边后端返回的数据像 tmd 一坨屎... 明明他自己能处理的数据 非要丢给我来处理 自己坐在那里玩手机 刷推特 我真的 C™D

主要他也玩 v2 也不好把数据粘贴出来。
k9982874
2023-12-11 17:15:17 +08:00
这。。外包你不干他，留着他过年？
wdf
2023-12-11 17:26:10 +08:00
那你是没遇到我们的后端，前端用的级联组件，按道理后端返回正常的树结构就没啥问题，结果他返回的数据每层的数据格式不一样，层级也不确定 说最多 5 层，最多返回 5 千多条数据，沟通让改下数据格式，后端回怼句：我返回的数据格式是有意义的，我修改的话不太好。我现在有点质疑自己 不知道问题出在哪了
sanmaozhao
2023-12-11 17:32:36 +08:00
1 、既然是多值，那就以数组返回
这个没什么好商量的，后端你爱咋存咋存，不要暴漏给前端。更别说值里面有逗号咋办的事儿了

2 、逻辑判断用中文不太好，或者说不要用“会显示到界面上的值”
因为会显示出来的，后续很大可能就要修改，文案啥的谁都没法保证不变
如果这个中文永远不显示给用户，那就还行吧，你就当它是个 key 好了
nothingistrue
2023-12-11 17:46:44 +08:00
如果单纯从技术层面讲：
问题 1 ，前后端谁做都可以，后端的视图层，前端的 Model 层都是干这事的，至于具体谁做，首先要看以前谁做，其次要看现在谁愿意做，最后才是看谁有时间做。
问题 2 ，不与代码同步的文档不如没有文档，没有管理的编码不如直接用名称。尤其是经过大数据分析的发展之后，那种没用的编码，还是让他步入坟墓吧。

实际上你不要扣技术，没意义。
davin
2023-12-11 17:49:35 +08:00
感觉第二个问题可以用 enum 枚举映射， 用的时候，name === ItemTypes.Category1 这样判断。之后维护这个 ItemTypes 就好，减少传说中的魔法值。其他比如订单状态，衣服的尺码 (M 、L 、XL 、XXL 、XXXL 等)，订单审核状态也适合用枚举。
MoYi123
2023-12-11 17:49:56 +08:00
喷点只有
1. 不规范
2. 逗号不在 url 转义的表里, 一定要这样搞用个分号, 保证不切错(包括后端的存储)

硬要说性能, 我猜这样 split 性能会比解 json 更好.
43n5Z6GyW39943pj
2023-12-11 17:56:33 +08:00
上嘴脸
FawkesV
2023-12-11 17:58:34 +08:00
问题 1 偷懒了. 也确实很丑.
问题 2 看业务场景,有没有 code 实在没办法只能这样子处理了
coderzhangsan
2023-12-11 18:07:51 +08:00
1 谁做都行，只是看谁懒得强势些，你来提问，就应说明问题了；至于性能，你说得太夸张，你一页要显示多少商品数据？几百条以下，字符串转换为数组能耗损什么性能。
2 用中文可能是前期设计遗留的问题，加状态枚举估计要改造库表，能跑就行，不必过多关注，真有问题，推给后端就好了。

总结：
1 你有代码洁癖
2 贵司后端比较强势
3 后端外包，你们的项目估计也好不到哪去，所以程序和程序员只要有一个能跑就行
fkdog
2023-12-11 18:40:05 +08:00
后端水平太次了，英文半角逗号是 url 无需转义的字符，但凡哪天 url 需要存一个云厂商处理过的带参数图片、视频（往往 url 里带半角逗号的），就会出问题。

这是一个专为移动设备优化的页面（即为了让你能够在 Google 搜索结果里秒开这个页面），如果你希望参与 V2EX 社区的讨论，你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://tanronggui.xyz/t/999425

V2EX 是创意工作者们的社区，是一个分享自己正在做的有趣事物、交流想法，可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX