这是一个创建于 1800 天前的主题，其中的信息可能已经有所发展或是发生改变。
后端接口中返回了一个 json：
{ "favorite" : [], "most_visited" : [], "recently_visited" : [], "recently_visited_by_day":{} }
注意前三个 key 的值是 array，最后一个是 object
需求是页面需要展示前三个 key 对应的数组的内容，于是前端就对这个字典做了 for 遍历，输出了前三个 key 的内容，而且前端也考虑了，后续如果接口返回了更多的 key，他就直接不用改代码，就兼容了。
我作为后端，我觉得这样不合理，理由是：
前端这种处理，实际上是依赖了 hash 字典 key 的顺序，这不符合常规的习惯。理由是：
- 后端开发在不知道这个依赖的情况下，如果改了 key 的顺序， 前端页面展示顺序就反了。 实际上，确实就遇到 了问题，产品要求改一下三个模块的展示顺序，前端让我接口去改 key 的顺序
- 如果后端在这个接口加了一个字段，本来谁都会认为这个改动不会对前端造成任何影响，实际上就会影响到。
这种非常规的处理，就很容易导致 bug
如果前端确实觉得 for 遍历处理方便，应该和后端沟通，把接口返回格式改为： { "list" :[ [], // 对应 key favorite 的值 [], // 对应 key most_visited 的值 [] // 对应 key recently_visited 的值 ] "recently_visited_by_day":{} }
 |
1
yimity 2019-12-20 08:38:42 +08:00  1
前端定义一个 key 的数组，按照这个数组去拿就好了。后端再怎么改都不怕。
|
 |
2
April5 2019-12-20 08:44:07 +08:00
如果有显示顺序的需求，要不就是你加个 show_list 显示告诉前端咋显示，要不就是前端自己加个 show_list 自己决定显示顺序，无非就是遇到需求更新前端后端的问题而已= =
还有前端的确是不应该去依赖 hash 字典 key |
 |
3
oneisall8955 2019-12-20 08:44:30 +08:00 via Android
1 楼+1
|
 |
4
kely 2019-12-20 08:47:15 +08:00 via Android
前端这样处理的确不合适。主要看你们的需求和场景，如果会频繁变动，就由后端控制，像你后面修改的一样返回一个 list 保证顺序。如果不频繁变动，后端不用改，前端根据 key 取对应值就行。
|
 |
5
ipwx 2019-12-20 09:13:12 +08:00 via Android
后端加一个 key，叫 display_order
|
 |
6
Amit 2019-12-20 09:14:22 +08:00 2
json 是 key-value 形式的数据，本来就不保证顺序的；加字段符合开闭原则，对原有程序应该做到兼容。有些事情不是后端做不到，而是不适合在后端做。不是针对前端，有的人就是蠢的理直气壮。
|
 |
7
huage2580 2019-12-20 09:19:52 +08:00
1L+你的理解，差不多这样。尤其是移动端，发版挺难，有必要自己维护显示的数组，过滤由于后续升级接口，导致旧版本没办法解析的问题。
|
 |
8
shintendo 2019-12-20 09:31:03 +08:00
长见识了，头一次听说这种神仙操作
|
 |
9
avaJ 2019-12-20 09:48:59 +08:00
不懂前端为什么要遍历这个字典
|
 |
10
jin5354 2019-12-20 09:49:04 +08:00
在 js 世界里使用 Object.keys 或者 for in 遍历对象，返回的 key 的顺序也是不做保证的，是不可靠的。所以这不是任务分配的问题，这就是那个前端菜。
|
 |
11
hirasawayui 2019-12-20 09:59:08 +08:00
对，那个前端菜，js 的对象遍历的时候是无序的。哪怕后端用的是有序
|
 |
12
Rekkles 2019-12-20 10:01:54 +08:00
 自从前后端分离 后端不仅要做 curd 还要对付这种前端真是难熬 |
 |
13
xushengbin888 OP 1
感谢大家的回复！
昨天因为这一点，和前端同事从讨论到有点争执，我也在反思自己。我的问题在于，当我觉得这是一个不可接受的处理方式时，沟通的时候我会有种一定要说服对方的潜意识，说服不了就会着急、带情绪。 我后来在反思和这位同事争论的过程： 我的出发点是：前端依赖字典 key 的顺序，是极不合理的。 前端同事的出发点是：遍历渲染页面，开发工作量小。 在友好相处、不因为工作伤情面的角度，我当时可能应该这么做： 我应该从对方的关注点出发，既然你想遍历，而我一时又说服不了你，那么，我可以给你改下接口返回格式，返回一个 list （从业务角度讲，这三个 key，业务还有区别，但也可以勉强理解为是同一类业务）。这样前端去遍历的话，这种行为的后果是可预期的。 有时候我太想证明自己是对的，反而会阻碍了事情的进展，有点舍本求末，浪费了时间，甚至伤了同事的感情。 |
 |
15
Hoshinokozo 2019-12-20 10:34:31 +08:00
for in 是不能保证顺序的，要保证顺序就用数组[{"favorite" : []} , {"most_visited" : []}, {"recently_visited" : []}, {"recently_visited_by_day":{}}]
|
 |
16
ai277014717 2019-12-20 10:53:33 +08:00
产品有提可扩展的要求就没啥问题。就是没有提，给出个排序也不会有这事情了吧。多沟通啊。
|
 |
17
jkmf 2019-12-20 11:54:04 +08:00
前端做法有问题，原因上面的兄弟已经说了。另外觉得你们是不是没搞清楚需求是啥？到底是展示前三个 key 对应的数组的内容还是特定的三个 key 对应的数组内容，我觉得是后一个吧，把需求跟前端大哥说清楚，他就不会再这样处理了吧
|
 |
18
november 2019-12-20 12:27:46 +08:00
前端的做法有没有问题，主要还是看需求。你这里需求也没说清楚。
如果需求是，把 value 为数组的都展示出来，并且不考虑顺序，那么前端的做法，对于这样的数据结构的处理，是没问题的。 当然，你把数据结构改成 Array<Array>，也没问题。 但是如果，显示顺序有要求，前端的做法就有问题了。因为确实不能保证顺序。 如果进一步还考虑到，会有更多的数组添加进来，并且也有顺序的要求，那么最好，还是由后端返回 Array<Array>这样的数据提供给前端遍历。 所以我觉得你们是缺乏沟通，前端对需求了解少或者产品没交代好需求。 |
 |
19
ironMan1995 2019-12-20 12:37:38 +08:00 via Android
@yimity 后续后端添加了，前端又得往这个 key 数组加？
|
|
20
ironMan1995 2019-12-20 12:39:52 +08:00 via Android
不如把数组现在对应的改为对象，数组再放里面再加个排序字段
|
 |
21
hideonwhere 2019-12-20 13:37:10 +08:00
穷举你见过没 还有 0E-10
|
 |
22
fengmumu 2019-12-20 14:10:59 +08:00
我觉得这事出现在我和我的后端老哥身上，我会被打屎，单纯为了自己爽不从项目考虑有点，，
|
 |
23
souths 2019-12-20 19:23:26 +08:00
前端有问题
|
 |
24
Tokin 2019-12-21 01:00:38 +08:00
对顺序有需求，后续还可能会增加字段，那你返回这样的对象前端也不好处理啊。
如果当初需求明确是上面这样的话，我觉得你后端也有问题。如果需求仅仅只是“需求是页面需要展示前三个 key 对应的数组的内容”没有明确要求顺序，那我觉得直接遍历跟菜也没什么关系。 |
|
25
xushengbin888 OP @Tokin 没有明确顺序，返回三个 key，就是三个模块的数据。前端觉得遍历方便，正好也依赖了后端的接口的顺序。
如果要依赖顺序，前端应该提要求，改接口格式，返回 list |
Select Language