这是一个创建于 1710 天前的主题，其中的信息可能已经有所发展或是发生改变。
收藏夹列表:
[
{
"id": 2,
"name": "我的资源收藏夹 1"
},
{
"id": 3,
"name": "我的资源收藏夹 2"
}
]
现在产品设计 加了个不限.....
然后客户端 非得让我修改接口
[
{
"id": 0,
"name": "不限"
},
{
"id": 2,
"name": "我的资源收藏夹 1"
},
{
"id": 3,
"name": "我的资源收藏夹 2"
}
]
就因为下拉 要多一个不限的选择.......
你们现实中是怎么样的那?遇到过这样的问题吗?
第 1 条附言 · 2020-04-22 20:40:55 +08:00
各位大佬.我只是问问大家的意见... 没有别的意思.. 目前已经商量好了,以后这种事情.统一由后端来改. 来返回
[
{
"id": 0,
"name": "不限"
},
{
"id": 2,
"name": "我的资源收藏夹 1"
},
{
"id": 3,
"name": "我的资源收藏夹 2"
}
]
 |
1
SilencerL 2020-04-22 10:28:26 +08:00
遇到过, 一般谁拳头硬就听谁的.
不过我还是感觉这种需求放前端实现比较好. |
 |
2
geshansuiyue 2020-04-22 10:32:29 +08:00
积怨已久？
|
 |
3
shoaly 2020-04-22 10:33:00 +08:00
就现在后面这个 json 挺好, 毕竟 前端不用动, 后端只用多一个 item, 况且产品可能脑抽 还要改字,
不限变成 默认, 默认改成 收藏 收藏改成我的收藏夹 不能每次都升级客户端的 |
 |
4
sodulty 2020-04-22 10:33:06 +08:00
约定好第一个值是特殊的。许多场景不想新开接口，只能靠约定，缺点是维护成本高
|
 |
5
artikle 2020-04-22 10:34:06 +08:00
这种一般是后端改的，因为要是返回的不限这种有变动 比如改名字或者去掉这个选项，后端修改发版成本比较小
|
 |
6
liuxey 2020-04-22 10:35:15 +08:00
像“全部”“不限”这类选项我觉得是 UI 组件的事情，但是具体还是要看谁更硬
 |
 |
7
HongJay 2020-04-22 10:36:30 +08:00  5
为啥要写死在客户端
|
 |
8
kop1989 2020-04-22 10:39:36 +08:00
从整体角度上讲，服务器端加的成本更低，而且更通用。
如果是客户端加的话就要涉及到特殊处理，其实会更麻烦。 |
 |
9
KyonLi 2020-04-22 10:48:34 +08:00
我是能不麻烦后端就不麻烦，在前端分别请求每个分类里的内容然后合并展示，虽然分页加载很诡异但还是能凑合用的
|
|
11
kop1989 2020-04-22 11:16:37 +08:00
@geekzhu 1 、无论在客户端还是服务器端加，在反过来数据提交的时候服务器端都要特殊处理。
2 、其实楼主的这种情况对于服务器端而言不是“特殊处理”，而是多了一条数据。 |
|
12
kop1989 2020-04-22 11:20:06 +08:00
@geekzhu 3 、这个“特殊数据”，其实是服务器端需要的。那么服务器端需要的就应该由服务器端提供。因为这组数据本身是服务器端返回的动态数据。否则如果客户端特殊处理，写死这个“特殊数据”，有差错责任在谁。
|
 |
13
ISSSSSSS 2020-04-22 11:20:42 +08:00
建议后端处理，这样更灵活。比如改个字什么的。
|
 |
14
mmrx 2020-04-22 11:21:10 +08:00
我是客户端
这个事情其实哪端做都可以，这个时候就得看谁在群里说得看上去更有道理 一般我都是“说得看上去更有道理”那个 |
 |
15
wolfie 2020-04-22 11:22:03 +08:00
在哪实现都一样，谁改谁王八。
|
 |
16
geekzhu 2020-04-22 11:22:45 +08:00
|
 |
17
xuarongla0000 2020-04-22 11:24:58 +08:00
发帖的时间都可以改 10 个这种需求了
|
|
18
kop1989 2020-04-22 11:25:38 +08:00
@geekzhu 哦抱歉，我审题的问题，我以为客户端还需要上传。
不过如果不谈回传的问题的话，我个人认为还是服务器处理要合理一些。 主要还是因为这组数据是动态返回，前端写死相当于就对这个动态返回的数据进行了“污染”。这种会在日后维护的时候造成麻烦。 |
|
19
geekzhu 2020-04-22 11:26:04 +08:00
@kop1989 #12 3. 这句话有点不太理解，服务端展示的数据大部分都是客户端需要的，那是不是客户端自己保存就行了，服务端只负责统计就行
|
 |
21
yaphets666 2020-04-22 11:28:07 +08:00 2
我觉得 "全部" "不限" "所有" 这种字典值很蠢 不填不就是全部? 清空不就是全部? 还用单独搞一个这个出来?
|
 |
23
newtype0092 2020-04-22 11:31:51 +08:00
别气，客户端是要为更新发版妥协的，如果内嵌 H5 页面的可以直接让前端改，但如果是原生 UI 还是后端处理下吧，也算为了用户考虑。
要怪就怪产品为什么早没想到要加个不限，这种又不是什么很特殊的逻辑。。。 |
 |
25
baozijun 2020-04-22 11:36:52 +08:00
做成数据字典模块,维护即可
|
 |
26
DamonLin 2020-04-22 11:37:24 +08:00 via Android
建议后端给接口吧，客户端写死的话不方便后面扩展
|
 |
27
zhangchioulin 2020-04-22 11:38:01 +08:00
这个要看产品规模，DAU 百万的产品我认为这个放在后端比较合适，因为这个量级的产品都有一套全面的后台管理系统，可以控制非常多的东西。比如我司的后台管理能精确到移动端某个活动 Label 的颜色。
如果是产品目前 DAU 不大的话，后台系统不全面的话那就谁改起来简单谁来了。 |
 |
28
huage2580 2020-04-22 11:38:39 +08:00
我觉得没问题 啊，反正进收藏夹列表肯定带 id 给你吧。这样设计不挺好吗
|
 |
29
zpf124 2020-04-22 11:38:56 +08:00
我们一般是前端改， 因为许多类似这样的接口我们设计的时候都是不传筛选参数代表查询所有。
所以这里一般前端做一个额外处理，选择全部时，不给后端发这个参数。 |
 |
30
zdt3476 2020-04-22 11:41:31 +08:00
具体得看更新成本。如果产品后面要修改"不限"这两个字。肯定是放在更新成本低的那方最好
|
 |
31
otakustay 2020-04-22 11:50:15 +08:00
中间加一层 BFF，爱怎么改就怎么改，不修改后面的实际业务服务
|
 |
32
mendax92 2020-04-22 11:52:21 +08:00
其实这种东西，前后端改动都不大，我是做前端的，我也建议这种东西 放在后端。这样更灵活。就像平时开发的时候，接口数据提交只是很简单的一条数据，我建议 把数据封装成数组再提交，因为这种需求 谁也不能保证下一次 需求 不是 批量提交。
|
 |
33
suzic 2020-04-22 12:00:36 +08:00 via Android
遇到过，既然客户端不想改，那就我改呗。反正也改动不大。
|
 |
34
chairuosen 2020-04-22 12:04:55 +08:00
客户端这种不能随时发版的，业务逻辑要后移才能保证灵活性。
|
 |
36
Nostalgiaaaa 2020-04-22 14:29:13 +08:00
产品想改文案 "不限" 改成 "全部" 或者后来想做 abtest 。客户端发版等一周，后端十五分钟。从可拓展性来说后端改好一点。而且要是想记录用户操作啥的，打点也方便。
|
 |
37
speculatorA 2020-04-22 14:43:06 +08:00
不还是多一条数据嘛。。
你后端改到发版，也就 10 分钟的事情？ 客户端从改到发版，那是 1-3 天的事情。 你在发这贴，你同事可能在其他位置吐槽你呢。233 |
 |
38
Alexander321 2020-04-22 16:07:52 +08:00
这个...肯定后端改
因为产品改了一次就能改无数次 增加 item 修改 name.. 直接后端做成可配置的 大家都省事 |
 |
41
dicc 2020-04-22 17:51:27 +08:00
@yaphets666 下拉跟填空不一样,下拉还得恢复成空
|
 |
42
Woood 2020-04-22 18:13:18 +08:00
你是不是没有经历过苹果更新版本
|
 |
43
root777 2020-04-22 18:45:02 +08:00
你有这发帖的时间，还不如去改接口，这是多大脾气的人啊
|
 |
44
des 2020-04-22 18:52:11 +08:00
|
 |
45
nicevar 2020-04-22 20:56:10 +08:00
客户端不是前端，上面一些人要搞清楚，这个问题肯定是后端改最简洁，没什么好气的，几分钟的事非得斗气还怎么合作。
|
 |
46
nl101531 2020-04-22 23:15:35 +08:00 via iPhone
问题不应该出在改需求嗯产品吗。。。。
|
Select Language