这是一个创建于 1969 天前的主题，其中的信息可能已经有所发展或是发生改变。
- 排序问题
假如接口返回的数据是 3 1 2, 但是前端需要展示的是 1 2 3, 并且没有分页, 一共就 3 条数据, 那么这个排序是前端做还是后端做.
- 数据整理问题
假如接口返回的是一个数组, 但是前端需要一个树, 那么这个数据整理是前端做还是后端做.
我的想法是后端和展示层不依赖, 数据整理和排序都应该是展示层的工作.
实际情况是前端做起来很费力, 只能我专门写一个整理好的接口.
再次说明了: 技术问题最终还是人的问题.
第 1 条附言 · 2019-07-02 13:36:28 +08:00
后端这些都可以做, 没问题. 但是因为树型接口我已经改了好几次了
刚开始我给了一个数组, 前端说组件不支持这种数据结构, 要我给一个树
我改接口, 给了一个树
测试提 BUG, 说树节点的顺序不对
前端说是我的接口问题
我又改接口, 增加了排序
上述的问题本来都可以避免的, 前端已经拿到了全量的数据, 怎么整理, 怎么排序都由前端决定.
现在, 测试给前端提 BUG, 前端再把 BUG 转给我, 大费周章值得吗
刚开始我给了一个数组, 前端说组件不支持这种数据结构, 要我给一个树
我改接口, 给了一个树
测试提 BUG, 说树节点的顺序不对
前端说是我的接口问题
我又改接口, 增加了排序
上述的问题本来都可以避免的, 前端已经拿到了全量的数据, 怎么整理, 怎么排序都由前端决定.
现在, 测试给前端提 BUG, 前端再把 BUG 转给我, 大费周章值得吗
 |
1
MotherShip 2019-07-02 11:44:16 +08:00
1 取决于这个接口是否有其他端调用，没有的话可以后端改
2 数据结构还是后端做吧 |
 |
2
akari33 2019-07-02 11:45:01 +08:00
1.前端 2.后端做一个 vo 实体类返回给前端
|
 |
3
dongisking 2019-07-02 11:47:02 +08:00
排序问题
一般是我后端做 数据整理问题 一般是我后端做（例：评论和 reply 评论） |
 |
4
April5 2019-07-02 11:47:05 +08:00
没说清楚前端难在哪
|
 |
5
LongMaoz 2019-07-02 11:53:13 +08:00  1
目前我是用 TypeScript 写前端数据结构，NetCore 写后端接口
后端的数据返回结构可能跟前端所需要的不一样，所以我前端是把后端的 BaseModel 搬过去作为基类， 然后前端的数据结构在 BaseModel 上 Extend，后端只做数据返回，比如你的第二种情况， 我是把后端的数据丢进前端的已经 Extend 的类种的构造函数里面进行实例化，这样就可以后端只返回数据 前端的 BaseModel 用来接收数据，同时创建新 Class 用来 Extend 基类，类中再进行数据转换以及整理，这样应该是可以完美实现你的需求的 |
 |
6
passerbytiny 2019-07-02 11:54:20 +08:00
前端 Model 层或类似层，后端视图层或者端口适配层，都可以做，谁做只取决于谁愿意和有时间干，跟技术无关。技术上可以确认的是，非常不能让后端业务层去做，不建议前端展示层去做。
|
 |
7
stx2012 2019-07-02 11:56:45 +08:00 via Android
当数据量大的时候，前端计算很费资源和时间，还是后端做比较好
|
|
8
LongMaoz 2019-07-02 12:00:34 +08:00
后端返回结构👇
export interface ApiResult<T> { code: number; msg: string; result: T; } T 里面放后端的数据结构基类 然后 T 类的 Extend 的类中定义构造器参数为 T 类 进行实例化就可以了 前端基于后端的 T 类 进行 extends 的结构（ Contact 类就是我 Group 类用到的基类，也就是后台返回的 T 类型）👇 export class Group extends Contact { public upperlimit: number; public creater: string; public announcement: string; constructor(baseGroup: BaseGroup) { super({ key: baseGroup.id.toString(), name: baseGroup.name, imgSrc: baseGroup.logo }); this.creater = baseGroup.createUserID.toString(); this.upperlimit = baseGroup.grade; this.announcement = baseGroup.description; } } |
 |
9
cwjokaka 2019-07-02 12:10:22 +08:00 3
如果我是前端，我会倾向于给后端做。反之亦然
|
 |
10
ben1024 2019-07-02 12:13:48 +08:00
加个 Formatters 层
|
 |
11
lneoi 2019-07-02 12:14:23 +08:00
如果整理数据太耗费时间，比如又排序又对比还得重新组织结构，或者多端都需要重复这一步骤，这块就归后端处理了。
|
 |
12
cyndihuifei 2019-07-02 12:17:48 +08:00 1
这种事情后端处理没什么好说的吧，我自己既是后端也是前端，很反感前端对接个接口还要处理来处理去
|
 |
13
liuhuansir 2019-07-02 12:21:22 +08:00
你举例的两个，真的可以无所谓谁来做，完全看人的，有人觉得举手之劳，顺带就做了，有人嫌麻烦，就让对方做
|
 |
14
PerpetualHeng 2019-07-02 12:22:55 +08:00
两种都有，前后端都可以，但是全部后端处理，会更好一些。
|
 |
15
bin20060407 2019-07-02 12:25:48 +08:00 2
前端能做，不代表前端一定要做，尽量让前端渲染数据更简单是我们这边后端团队的宗旨。
|
 |
16
kanezeng 2019-07-02 12:34:00 +08:00
其实我觉得这两个例子都无所谓吧，大多数时候我都是后端直接做好了出来。不过如果真碰到需要转换的时候有时候我也放用户的前端，让用户的机器帮我们的后端分担点计算资源嘛。
|
 |
17
will0404 2019-07-02 12:42:28 +08:00 via Android 8
这两点前端都能做，而且很简单，但不应该由前端来做。前端的职责是渲染和交互，仅此而已。
通常不太负责的后端会说，这么简单的事你前端做一下就好了，我会怼回去，你不会写的话我来帮你写后端。 |
 |
18
serge001 2019-07-02 13:03:20 +08:00
我觉得前端做,这样才够灵活,不然你今天要这样的排序,明天又想要那样的排序,后端的接口岂不是要反复变;然后对于所说的扁平数据变树跟树状数据变扁平, 除非数据量很大,影响到了性能跟体验,还是在前端做比较好,因为前端可能同时用到扁平数据跟树状数据;
|
 |
19
xuanbg 2019-07-02 13:08:05 +08:00
排序一般都是后端做，因为排序往往还有分页。树形显示不是只要对象包含 id 和父级 id，前端组件数据绑上去就好的吗？
|
 |
20
lihongjie0209 OP @serge001 我主要也是有这方面的顾虑
|
|
21
lihongjie0209 OP @xuanbg 不带分页的,审题
|
|
22
lihongjie0209 OP @will0404 前端改 UI 的话, 需要的数据不变, 是不是后端就因为数据格式的问题还要改接口
|
|
23
lihongjie0209 OP @liuhuansir 不是举手之劳的问题, 后面前端要改 UI, 你还要跟着改接口, 是耦合的问题
|
 |
24
zr8657 2019-07-02 13:26:57 +08:00 via Android
前端的重点是与用户的交互，这种处理数据结构的问题应该后端做。
|
|
25
lihongjie0209 OP |
 |
26
Chingim 2019-07-02 13:30:53 +08:00 via Android 1
后端做。因为一个接口可能对接 web，安卓,ios 等等各种客户端，客户端做就重复劳动了。而且排序规则改变时，若干个端都需要改。
当然排序这么简单的东西，谁做都一样。但是以后如果需要加分页了，那还是后端做，从扩展性上考虑，后端做比较好 |
|
27
lihongjie0209 OP @Chingim 没有多端, 所以暂时不考虑
|
 |
28
a62527776a 2019-07-02 13:43:24 +08:00
这种应该是需求定的把 怎么能因为前端说组件不支持就要求后端改接口呢
|
|
29
will0404 2019-07-02 13:44:00 +08:00 via Android
@lihongjie0209 你的假设就是错的，接口不应该根据 UI 来定。既然你接口要根据 UI 来定，那么 UI 变了接口跟着变不是合理的吗？这个点在于，接口不是跟着前端变，而是接口和前端都跟着 UI 变了。
|
|
30
a62527776a 2019-07-02 13:47:25 +08:00
我感觉的问题是
前端说组件不支持数组 所以要个树 那不是应该前端自己找个支持数组的组件嘛 |
|
31
lihongjie0209 OP @will0404 我的意思是, UI 需要展示的数据我都发给前端, 至于说前端要展示 列表还是树状结构那是前端决定的. 就像前端展示 "2019 年 1 月 1 日" 或者是 "2019-01-01" 和我后端没关系
|
 |
32
OSF2E 2019-07-02 13:48:28 +08:00 1
理论上说，交给前端来排序没有问题，但前提条件是 —— 由前端来决定什么时间请求数据以及如何请求数据。
“前端做起来很费力”，只能说明交互场景设计、视图状态分析等等工作拆分的还不够细。 换个角度说，不能用后端“少量字段抽象一个模型”的思路来处理前端问题，应当先分析交互流程，将一个完整的功能拆分为一系列静态场景，然后由前端提出后端数据接口的适配需求，也就是说实现一个功能可能需要提供多个接口，而不是后端把数据“一锅甩给前端，让前端自己在里面选有用的”。 |
|
33
lihongjie0209 OP @a62527776a 嗯, 前端组件需要什么数据结构肯定是前端自己处理, 现在和后端接口耦合了
|
|
34
lihongjie0209 OP @OSF2E 我说的费力是前端的组件需要一个树, 但是我给的是一个数组
|
|
35
liuhuansir 2019-07-02 13:50:32 +08:00
@lihongjie0209 前端 UI 变，接口跟着变也是常事，再说就这两个例子又不复杂，后台跟着变也无关紧要吧，商量着来就行了
|
 |
36
Caballarii 2019-07-02 13:51:45 +08:00
所以现在经常有一层 API 转发，通常是 node，拿着后端大而全的数据，变成更精细的数据接口给前端用，属于前端的活
|
 |
37
version 2019-07-02 13:51:59 +08:00
推荐是前端转吧.我看像是后台管理的应用
能减少后端的业务混乱才是好前端 一对多.多对多.树形结构.后台管理本来数据量不大.没必要后端去拼接.. 前端都 vue react 有状态机了.很方便拼接的了. 我一般是让前端改..不会写的.我会帮前端写.然后再喷他们菜.一个数据处理都不会的前端都是 lj 所以前后端分离.不是一条心的..最终整个团队都是毒瘤了..接口数据拼接多.接口会忙.再加需求.后端抗不了的了 如果是 app 的那些接口.就统一后端处理数据了...最好前端只做展示.包括日期 |
 |
38
zmyongfeng 2019-07-02 13:52:05 +08:00
打得过就让他做。打不过就自己做
|
|
39
lihongjie0209 OP @liuhuansir UI 变的意思是在所需数据不变的情况下调整 UI, 最简单的例子 前端展示 "2019 年 1 月 1 日" 改为 "2019-01-01", 这种情况下接口是不需要改变的
|
 |
40
KingOfUSA 2019-07-02 13:53:30 +08:00
前端做。
|
 |
41
unco020511 2019-07-02 13:54:05 +08:00
一般是后端处理,前端避免数据计算和整理
|
|
42
lihongjie0209 OP @version 这种数据处理工作 map reduce filter 直接解决, 没什么复杂性, 下次我直接帮前端写代码
|
|
43
liuhuansir 2019-07-02 13:54:15 +08:00
@lihongjie0209 我能说前端展示 "2019 年 1 月 1 日" 改为 "2019-01-01"，这种需求，我们的后端都愿意帮忙实现。。。可能是我们工作量都不饱和吧，人家愿意做，我总不能拦着吧
|
|
44
lihongjie0209 OP @liuhuansir ...........无话可说, 佩服佩服
|
 |
45
guorui112 2019-07-02 13:56:19 +08:00 1
看和后端关系好不好，以前和一个关系比较好的后端做项目，都是抢着做，看哪边处理方便
|
|
46
OSF2E 2019-07-02 13:57:10 +08:00
@lihongjie0209 锅背不动了，那就不背了
|
|
47
version 2019-07-02 13:59:24 +08:00
@lihongjie0209 如果是后台管理最好要喷喷前端的了.不行就自己改了..后端再转..以后合并其它数据更加难..例如 table 是 5 个连表出来的数据...一个单独的 tag.都需要我转字段给他们..我就要说了..这无疑会搞垮整个 sql..后端再转多一层分明就是业务乱了.以前试过..后台管理不能让前端做话事权..能前端转数据的是最有利于以后迭代的..
|
 |
48
15651980765 2019-07-02 13:59:34 +08:00
我司前端没人权，此类工作都是前端在做，后台大部分时间都是直接给全量数据，前端要啥数据，自己遍历去取然后拼成想要的格式，我已经不止一次吐槽过后台了，然并卵！
|
|
49
will0404 2019-07-02 14:00:30 +08:00 via Android
@lihongjie0209 你举的例子是两类问题。
要列表还是要树，后端做。 时间的格式，前端做（后端提供时间戳满足所有场景）。 对于第一类问题我说了，你接口是根据 UI 定的，从列表换到树，想必 UI 变了吧？而且改动还不小，有什么理由不重写接口呢？ 举个例子，通常接口返回的数据会有一层数据校验，在后端某个中间件上，你不打算改接口，返回的旧数据，而数据转换放在了前端，那一层服务就形同虚设了。 |
 |
50
raynor2011 2019-07-02 14:01:56 +08:00 1
和显示强相关的，必须前端做啊
|
|
51
lihongjie0209 OP @will0404 ui 变了, 但是数据还是那些数据
|
 |
52
527944441 2019-07-02 14:02:56 +08:00
第一个谁做都行 第二个我觉得做之前应该商议一下
|
|
53
Caballarii 2019-07-02 14:04:23 +08:00
市场上彩笔前端太多了，培训班出来一点基本功都没有的，造成了都得后端帮忙的现状
|
 |
54
Sapp 2019-07-02 14:07:30 +08:00
第一个问题无所谓，第二个问题得看具体情况，如果就是这一份数据需要稍微转换一下，实际谁做都可以。但是如果这个结构涉及到很多接口的调用组合然后才能拼出来，那这个接口设计就有问题，也不存在谁做的问题了。
|
 |
55
TimPeake 2019-07-02 14:08:44 +08:00
作为前端做过类似的。
特别树形之类的复杂嵌套之类的数据，真的是后端做方便点。 后端可能几行代码解决了。 前端却需要十几行甚至几十行代码去转换格式化成理想数据，可能还有 BUG 总结：你把东西推给前端，工作流程没有错。但是出于道义，我建议你多为你的前端考虑一下 |
|
56
lihongjie0209 OP @Sapp 全量数据, 不存在调用多个接口的问题
|
 |
57
deleteDB 2019-07-02 14:09:23 +08:00
第一个问题 后端做 如果有一天需要分页全表排序 前端是做不了的 还不如现在后端就做了
第二个问题 谁做都可以 数据量大推荐后端做 感觉没什么代码规范 要不然至少不应该有第一个问题 我是前端 |
 |
58
lizz666 2019-07-02 14:09:30 +08:00
让我想起了上个项目，涉及到腾讯广点通区域定向和今日头条区域定向数据，这两个平台返回的数据结构并不一致，我前端有个树形结构，需要按我树形结构格式给我数据。
头条的数据由于是死的，官方文档上有，我直接在前台写死处理好了。腾讯就比较 fuck 了，必须通过腾讯的接口才能拿到那么多数据，一开始，嫌烦，让后端帮我做，结果，数据太多，接口超时，后来实在没辙，还是交给我前台来处理了。 |
 |
59
keikeizhang 2019-07-02 14:09:53 +08:00
和 demo 操作没有关系的数据处理一律是后端的工作
|
|
60
lihongjie0209 OP |
|
61
lihongjie0209 OP @deleteDB 第一个数据量是死的, 就几条
|
 |
62
tailf 2019-07-02 14:13:35 +08:00
这些前端数据格式化的需求，理论上需要配一个 API 层来处理，这一层只负责给前端需要的数据做聚合和结构处理，这个是有后端工程师做的，但是却属于大前端的范畴。
其实大多数常见的场景都很好办，上 GraphQL 规范，搞定。 |
 |
63
freakxx 2019-07-02 14:18:52 +08:00
这个问题其实主要看谁有空，谁方便，但有个平衡性
如果是数据展示的问题可以考虑类似 ?format=json or ?format=xml 这种方式 如果数据是固定的，资源性的，那么考虑 /api/<api>/xxx/这种给他做个特殊化，比如 /api/students-tree/ or /api/students/tree/ |
|
64
15651980765 2019-07-02 14:21:02 +08:00
@lihongjie0209 话说请教一下数据量大的时候，放在前端处理，对页面性能会不会有什么影响？
|
|
65
serge001 2019-07-02 14:26:21 +08:00
我是前端,反正我觉得这些大部分情况下都应该在前端处理,为了处理数据格式没必要加多个 node 中间层...
|
 |
66
limuyan44 2019-07-02 14:28:39 +08:00 via Android
解决问题最快的方法是让测试直接把 bug 提给你，这样不就不大费周章了。
|
|
67
KingOfUSA 2019-07-02 14:46:20 +08:00
因为有类似的问题，所以现在团队里面的前后端交互都是让后端的同事来负责(美名其曰 全栈)，前端的同事负责做静态页面以及后端解决不了的问题。
|
 |
68
BreezeInWind 2019-07-02 14:46:38 +08:00 via Android
我前后端都做，做前端的时候我就跟后端说数据随便给，我自己处理成合适的格式，只要别多余浪费就行，比如要五条给十条，要十个字段给二十个字段之类的；做后端提供接口的时候就找前端确认好要的结构，争取他们不怎么用写任何多余的处理逻辑就渲染出界面，。这件事怎么做感觉就是存乎一心，做有做的道理，不做也有不做的道理，如果有合适的机会，前后端都做一下，你会对这件事有不一样的感悟的
|
 |
69
Yuicon 2019-07-02 14:51:16 +08:00
看了半天 就是一个扯皮的问题
|
 |
70
l00t 2019-07-02 14:53:24 +08:00
当然应该前端做。这就是个前端显示的需求，跟后端有什么关系。
|
 |
71
coolooks 2019-07-02 14:59:22 +08:00
有时间来这里扯皮，没时间改接口，闲的蛋疼
|
|
72
lihongjie0209 OP @coolooks 接口早就写好了, 只是讨论一下这个问题而已
|
|
73
lihongjie0209 OP @Yuicon 是一个规范的问题
|
 |
74
rr41ns 2019-07-02 15:05:52 +08:00
都是后端处理。
|
|
75
rr41ns 2019-07-02 15:09:18 +08:00
本人是后端，工作久了就知道沟通的成本很贵，只要是我力所能及能做的我就做。
有时候排序是 sql 里加个 order 的事儿，后端不弄还要让前端去专门排序考虑数据正确性吗？ 有来回沟通的功夫早就弄好了，而且，这些活儿确实是该后端处理。 |
 |
76
drlalll 2019-07-02 15:14:43 +08:00
事实上很多前端只会做界面，逻辑非常差。所以一般逻辑问题都是后端处理好，当然你们这个问题属于沟通不畅。
|
 |
77
coang 2019-07-02 15:15:04 +08:00
如果是树后端做比较好.. 你排序问题 要加数据处理 而不是说前端要这个顺序接口就改成这个顺序.. 排序问题要对应有排序的参数... ps.我是后端
|
 |
78
zydxn 2019-07-02 15:17:05 +08:00
第一种情况，一般接口都有默认排序，如果业务需求上来回变化，走配置。
第二种情况，如果需求变化，要求提供树，就再加个树接口。 |
|
79
passerbytiny 2019-07-02 15:22:03 +08:00
@lihongjie0209 这个其实后端做也是可以的，后端可以在不动领域模型 /服务核心层的情况下，针对不同的前端、版本、特殊定制出不同的接口。传统的 Dao-Service-Controller 分层，如果正确的隔离 Service 层和 Controller 层，是很容易以很少的工作量来实现这种效果的。此时，接口由前端定义——但前端需要深入了解领域模型或业务模型。这样安排，对整体的好处是前后端之间更加松散。对后端的好处是：后端虽然没有了接口的主要控制权，但也没有了定义接口的责任。
不过，以上只是一种可以选择的方式，而不是建议的方式，具体哪种方式，取决于架构师、技术委员会或者技术负责人，如果都没有，那就取决于前后端谁的话语权更大了。 |
 |
80
hyy1995 2019-07-02 15:22:12 +08:00
其实这些个逻辑前后端都能写。但接口可能会多页面重复调用，如果是这样的话数据格式还是后端处理比较好
|
 |
81
tingfang 2019-07-02 15:22:25 +08:00
都可以，我觉得后端做更好一些，前端如果是 APP 或者小程序，逻辑改动还需要审核发布，后端做的话改起来会更方便些？
|
 |
82
santom 2019-07-02 15:24:20 +08:00
数据量不大 随便都可以吧 数据量稍微大点 还是后台做吧
|
 |
83
dicc 2019-07-02 15:26:10 +08:00
用户量大的话,后端做就不好了
|
 |
84
Hakka 2019-07-02 15:27:08 +08:00
排序问题
一般是我后端做 数据整理问题 一般是我后端做（同三楼） |
 |
85
dongxiao 2019-07-02 15:30:32 +08:00
看是否改动频繁吧，如果改动频繁前端做比较好点，不然每次调整页面都需要改动接口，如果基本定下来不会动了，后端改起来还是要快点，话说公司最近的一个项目包括页面显示的文字都是我这接口返回的，就是 No.1 xxxx No.2 xxxx 这种，前后端还是要多多配合，都是为了进度不是嘛
|
 |
86
zsy979 2019-07-02 15:51:31 +08:00
到底由谁做？没人能给最终结论
我是后端前些时刚经历了因为数据结构问题跟前端扯皮。。 树形结构转换在扯皮过程中都是小事，也算是头一次遇到糟心的前端可能他也是这么想的。 现在好了没必要因为这种问题去扯皮，就算说服他让他转换又能怎样，他可能还会想这个煞笔这都不会或者这都懒得做 |
 |
87
x7395759 2019-07-02 16:56:11 +08:00
此时就需要多一个层了
|
 |
88
mmuggle 2019-07-02 17:07:09 +08:00
GraphQL
|
 |
89
NotNil1 2019-07-02 17:07:17 +08:00
树的话我一般每个节点会额外给一个排序字段，层级字段。
|
 |
90
xianxiaobo 2019-07-02 17:14:20 +08:00
建议分成三个职位，一个后端，只做数据库的增删查改，一个前端，只做页面渲染，交互和样式书写，还有一个中端，专门做数据转换，将前端传入的数据转换为后端想要的数据，将后端返回的数据转换为前端想要的数据，以此解决此类扯皮问题。
|
 |
91
MoRun 2019-07-02 17:37:30 +08:00
这个得看情况
如果你的后端很重，有很多任务要做，比方说后端是一个负载均衡的网关，或者需要对个多展示层，那展示层的数据需要给前端做，或者再加一层数据处理层来专门做这个事情，比如说 GraphQL 如果你的后端仅仅只是简单的增删查改，我觉得还是尽量配合前端比较好 |
 |
92
CoCoMcRee 2019-07-02 17:49:24 +08:00
我这里 后端大多接口都会提供排序字段, 支持正反排序.
最外层肯定是树形结构. { "success": true, "errorCode": "", "message": "", "data": } |
|
93
CoCoMcRee 2019-07-02 17:51:13 +08:00
data 里头才是前端要的数据
而且 ,谁说只有后端才做数据校验 我这里前端对后端返的数据也要做数据校验的哦, 不同接口,校验的字段和结构都不一样哦. |
 |
94
bdnet 2019-07-02 18:03:18 +08:00
1. 问题不应该是 没有事先约定好接口数据结构？
2. 业务逻辑尽量收拢在一个地方，也就是后端，后端可以加一成，处理数据转换 |
 |
95
yufeng0681 2019-07-02 21:24:42 +08:00
1、还缺个组长，定义接口数据按什么排序返回；
2、后端做得越厚，前端就越简单，多个终端做起来一致性也容易保证。 3、你想做得灵活一点，就让前端传排序参数，支持多种排序方法返回数据。 |
 |
96
petelin 2019-07-02 21:35:35 +08:00 via iPhone
屁大点事 这都无所谓 当时文档怎么写的就怎么改
后期需求就看谁的老板硬 这都无所谓有什么好讨论的 |
 |
97
nidaye999 2019-07-02 21:44:54 +08:00
后端做，这么弱智的问题
|
 |
98
a852695 2019-07-03 01:58:15 +08:00
尽量后端做，前端核心是交互和数据可视化，你非觉得 chrome 性能好到比你服务器还快，那你就前端做吧
|
 |
99
a86356 2019-07-03 06:22:21 +08:00 via iPhone
后端做，数据结构后端做，给前端需要的数据结构即可。前端也一样的，提交数据的时候给你需要的数据结构。没什么好说。前端主要是交互。而且排序什么的，后端处理一 order 的问题，前端做还要遍历再排序，浪费时间。前端要做的是一些小的数据转换显示，比如时间搓，一些状态，1.2.3 转成对应文字。
|
|
100
a86356 2019-07-03 07:53:19 +08:00 via iPhone
@hedamao9999 说的很对，都做过考虑会比较周全。要不然一叶障目
|
Select Language