前端这样依赖后端接口合适不？

[xushengbin888]

后端接口中返回了一个 json：

{ "favorite" : [], "most_visited" : [], "recently_visited" : [], "recently_visited_by_day":{} }

注意前三个 key 的值是 array，最后一个是 object

需求是页面需要展示前三个 key 对应的数组的内容，于是前端就对这个字典做了 for 遍历，输出了前三个 key 的内容，而且前端也考虑了，后续如果接口返回了更多的 key，他就直接不用改代码，就兼容了。

我作为后端，我觉得这样不合理，理由是：

前端这种处理，实际上是依赖了 hash 字典 key 的顺序，这不符合常规的习惯。理由是：

1. 后端开发在不知道这个依赖的情况下，如果改了 key 的顺序， 前端页面展示顺序就反了。 实际上，确实就遇到 了问题，产品要求改一下三个模块的展示顺序，前端让我接口去改 key 的顺序
2. 如果后端在这个接口加了一个字段，本来谁都会认为这个改动不会对前端造成任何影响，实际上就会影响到。

这种非常规的处理，就很容易导致 bug

如果前端确实觉得 for 遍历处理方便，应该和后端沟通，把接口返回格式改为： { "list" :[ [], // 对应 key favorite 的值 [], // 对应 key most_visited 的值 [] // 对应 key recently_visited 的值 ] "recently_visited_by_day":{} }

[yimity]

前端定义一个 key 的数组，按照这个数组去拿就好了。后端再怎么改都不怕。

[April5]

如果有显示顺序的需求，要不就是你加个 show_list 显示告诉前端咋显示，要不就是前端自己加个 show_list 自己决定显示顺序，无非就是遇到需求更新前端后端的问题而已= =
还有前端的确是不应该去依赖 hash 字典 key

[oneisall8955]

1 楼+1

[kely]

前端这样处理的确不合适。主要看你们的需求和场景，如果会频繁变动，就由后端控制，像你后面修改的一样返回一个 list 保证顺序。如果不频繁变动，后端不用改，前端根据 key 取对应值就行。

[ipwx]

后端加一个 key，叫 display_order

[Amit]

json 是 key-value 形式的数据，本来就不保证顺序的；加字段符合开闭原则，对原有程序应该做到兼容。有些事情不是后端做不到，而是不适合在后端做。不是针对前端，有的人就是蠢的理直气壮。

[huage2580]

1L+你的理解，差不多这样。尤其是移动端，发版挺难，有必要自己维护显示的数组，过滤由于后续升级接口，导致旧版本没办法解析的问题。

[shintendo]

长见识了，头一次听说这种神仙操作

[avaJ]

不懂前端为什么要遍历这个字典

[jin5354]

在 js 世界里使用 Object.keys 或者 for in 遍历对象，返回的 key 的顺序也是不做保证的，是不可靠的。所以这不是任务分配的问题，这就是那个前端菜。

[hirasawayui]

对，那个前端菜，js 的对象遍历的时候是无序的。哪怕后端用的是有序

[Rekkles]

自从前后端分离 后端不仅要做 curd 还要对付这种前端真是难熬

[xushengbin888]

感谢大家的回复！
昨天因为这一点，和前端同事从讨论到有点争执，我也在反思自己。我的问题在于，当我觉得这是一个不可接受的处理方式时，沟通的时候我会有种一定要说服对方的潜意识，说服不了就会着急、带情绪。
我后来在反思和这位同事争论的过程：
我的出发点是：前端依赖字典 key 的顺序，是极不合理的。
前端同事的出发点是：遍历渲染页面，开发工作量小。

在友好相处、不因为工作伤情面的角度，我当时可能应该这么做：
我应该从对方的关注点出发，既然你想遍历，而我一时又说服不了你，那么，我可以给你改下接口返回格式，返回一个 list （从业务角度讲，这三个 key，业务还有区别，但也可以勉强理解为是同一类业务）。这样前端去遍历的话，这种行为的后果是可预期的。

有时候我太想证明自己是对的，反而会阻碍了事情的进展，有点舍本求末，浪费了时间，甚至伤了同事的感情。

[neverfall]

@Rekkles 如果后端连这种水平的前端都应付不了，大概也是半斤八两吧。

[Hoshinokozo]

for in 是不能保证顺序的，要保证顺序就用数组[{"favorite" : []} , {"most_visited" : []}, {"recently_visited" : []}, {"recently_visited_by_day":{}}]

[ai277014717]

产品有提可扩展的要求就没啥问题。就是没有提，给出个排序也不会有这事情了吧。多沟通啊。

[jkmf]

前端做法有问题，原因上面的兄弟已经说了。另外觉得你们是不是没搞清楚需求是啥？到底是展示前三个 key 对应的数组的内容还是特定的三个 key 对应的数组内容，我觉得是后一个吧，把需求跟前端大哥说清楚，他就不会再这样处理了吧

[november]

前端的做法有没有问题，主要还是看需求。你这里需求也没说清楚。

如果需求是，把 value 为数组的都展示出来，并且不考虑顺序，那么前端的做法，对于这样的数据结构的处理，是没问题的。
当然，你把数据结构改成 Array<Array>，也没问题。

但是如果，显示顺序有要求，前端的做法就有问题了。因为确实不能保证顺序。

如果进一步还考虑到，会有更多的数组添加进来，并且也有顺序的要求，那么最好，还是由后端返回 Array<Array>这样的数据提供给前端遍历。

所以我觉得你们是缺乏沟通，前端对需求了解少或者产品没交代好需求。

[ironMan1995]

@yimity 后续后端添加了，前端又得往这个 key 数组加？

[ironMan1995]

不如把数组现在对应的改为对象，数组再放里面再加个排序字段