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