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

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

虚心请教，各位后端大牛的看法，
8387 次点击
所在节点    程序员
72 条回复
nice2cu
2023-12-11 19:19:25 +08:00
估计数据库里就是这么存的，不存成 json 格式迟早要炸
kristofer
2023-12-11 19:24:05 +08:00
第一个问题，后端菜，不过你都说他是外包了，菜很正常。谁来解析都跟性能没关，一个分页列表，有啥性能问题。
第二个问题，历史遗留的不算，新代码且不是非这样不可的情况下，采用中文判断我不认可。
zjyl1994
2023-12-11 21:47:53 +08:00
1 的话，确实应该后端处理，存储层的细节不应该暴露出来给到前端。
2 的话和业务有关，有些上古系统就是这么设计的，你不兼容搞两套维护成本更高。而且很有可能接口已经被其他部门拿去用了，只能将错就错继续用下来，等接口重构才有机会改。
ntedshen
2023-12-11 22:22:32 +08:00
逗号拆数组的逻辑中间件写就完了吧，哪端都一样。。。

“很多地方逻辑数据处理全部扔到了前端,而且是在商品首页数据量这么大的地方，难道不会导致页面渲染缓慢吗”
讲道理前端苛求性能然后让后端做处理才更不符合现实逻辑。。。
尤其国服硬件性能本来就卷的很，一个电商客户端/网页还能有两位马老板的全家桶费性能？
Shosuke
2023-12-12 07:53:05 +08:00
我也碰到過這樣的後端，開發體驗糟糕的不行。

很多的事情邏輯上都扔到了客戶端，還有前端總要因爲後端的數據無規範，寫出一大堆自己看了都想吐的代碼。

不管怎麽溝通都會出現同樣的問題，最後自己選擇辭職。
Shosuke
2023-12-12 08:00:03 +08:00
問題 1 ）數據不是很多的話，可以接受，但是這種傳 string + ',' 方式真的不太好。
問題 2 ）專案是因爲太老了要維持字典還是什麽原因，好想吐槽...
bthulu
2023-12-12 08:48:59 +08:00
部分类型判断采用中文有什么问题? 我这边工业领域, 大部分专业名词都没有英文, 难道你还去生造一个英文单词出来?
snarkprayer
2023-12-12 08:53:53 +08:00
歪个楼，针对页面渲染缓慢这个，前端大部分项目其实摸不到性能瓶颈，看着不流畅一是动画不够，二是 HTML 历史包袱太重，抛弃掉各种兼容的话性能翻个一两倍轻轻松松
looo
2023-12-12 09:03:02 +08:00
我看前排好多人觉得这种逻辑后端没必要去写，都前后端分离了，那是不是先出文档，根据文档要求只做展示，前端不做任何业务处理。

一句话：前端只做展示，不做任何业务处理。
IvanLi127
2023-12-12 09:09:49 +08:00
问题一，绝对是后端偷懒，这都不转换回多维数组，要前端再处理，那要这后端有啥用？要我就直接拉他项目改代码了。
问题二，不好说合理不合理，如果是类似字典表做动态类型的话，中文就中文吧。
bianhui
2023-12-12 09:16:59 +08:00
针对问题 1：可能数据库存的就是字符串。后端拿到之后直接吐了，就没有处理。站在后端角度看，split 是要损失性能的，而这些性能是公司的服务器提供，都是要公司花钱的，如果 split 在客户端，用的是用户资源。其次众所周知处理成 json 会包含大量的无效字符，比如说引号逗号，在高并发常见会造成带宽的更多占用。
在前端角度看，确实破坏了整个项目统一性和规范性。让项目维护起来困难。同时如果后端数据格式发生变动，前端必须要跟随修改。
总结：如果公司不是你的，你自己分一下得了。
针对问题 2：这个不用说后端问题，可以让对方规定一套枚举或编号用于判断，中文在不同环境下编码有问题是毋庸置疑的。
总结：你可以让后端试试表单提交的 field name 全是中文的感觉
wangtian2020
2023-12-12 09:21:14 +08:00
其实逗号分隔的结果和 ['http://123','http://456','http://789'].join() 的执行结果一致
不能说完全没有关系，但是还是在返回体里面用 json 比较好

更坑的后端是直接返回个破字符串要求你 JSON.parse 几下
duanxianze
2023-12-12 09:34:31 +08:00
刚开始工作的时候我还会争辩两句，现在没必要，小公司，一来领导是看你工作时间给钱，二来你费劲心思写的代码说不定坚持不到 1 年就没用了，尤其是前端代码，说什么可维护都是扯淡
wolfie
2023-12-12 09:38:40 +08:00
经历不同，我们公司前端要求逗号更多，后端给数组时 老让后端改。
i8086
2023-12-12 09:42:10 +08:00
不排除就是直接从数据库读取出来，也不转换，直接返回给前端了。
luliumytime
2023-12-12 10:05:15 +08:00
能用就行
SleepyRaven
2023-12-12 10:10:19 +08:00
前后端都写一点的说下个人看法：
1 、这个存储的时候，避开值本身包含逗号或者转义的情况下，用逗号隔开存整个字符串也是可以的，问题在于返回给前端的时候肯定要 split 成数组的。
2 、这肯定不行啊，枚举值要么接口返回要么前后端统一写到常量 map 里。
abcdexx
2023-12-12 10:14:48 +08:00
@1016 在网上挂我？好，我记住你了。
darkengine
2023-12-12 10:18:50 +08:00
@Shosuke 是的，为了展示数据要做转换，特别是 web 转一遍，Android/iOS 又要转一遍。
dj721xHiAvbL11n0
2023-12-12 10:38:51 +08:00
既然是外包的，那肯定是你说了算

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

https://tanronggui.xyz/t/999425

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

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

© 2021 V2EX