今天开发遇到一个场景,前端页面里涉及金额的字段要增加千分位逗号,数据要做下处理,
我的疑问是,这个处理应该前端来做还是后端来做?
宝子们给点意见
先说下我自己的看法,我是前端的,所以我偏向前端只做交互和渲染,不做数据处理,应该后端处理数据, 你们怎么看?
1
vikaptain 2022-08-04 10:40:37 +08:00 16
前端处理。这不是数据处理问题,是数据显示问题
|
2
abc0123xyz 2022-08-04 10:41:27 +08:00 1
只要不让我处理就好
|
3
stoluoyu 2022-08-04 10:41:54 +08:00 1
撕逼输了的处理
|
4
lingxiaoli 2022-08-04 10:43:06 +08:00
当然是前端来处理了 1 楼说的对 这是显示问题
|
5
ngrok111 2022-08-04 10:43:52 +08:00
前端,就像一楼说的这是显示问题,后端给纯数字你想怎么改都行
|
6
cydysm 2022-08-04 10:43:54 +08:00 via iPhone
就一个字段的话 前端
当然后端可以给个展示用的字段 |
7
MrdotX OP |
8
thinkershare 2022-08-04 10:45:20 +08:00
屁股决定脑袋, 当然是希望将所有工作对推给对方做.
正常情况, 没有 BFF 肯定是所作都可以, 这个一个数据显示为什么样的样式, 更合理的当然是前端来做. |
9
laviris 2022-08-04 10:45:28 +08:00
无论从哪个角度看都是前端处理
|
10
daimubai 2022-08-04 10:45:32 +08:00
数据显示问题当然是前端改。和时间一样的。后端给前端时间戳,前端展示年月日也好,时分秒也好
|
11
des 2022-08-04 10:46:04 +08:00 via iPhone
当然是前端处理,这有什么疑惑的?
|
12
thinkershare 2022-08-04 10:47:02 +08:00 1
@MrdotX 金额进度当然是后端处理, 不过一般不会设计到精度, 因为我们总是使用比分还要小 2 个数量级的单位, 根本就不使用小数存储金额, 而是直接使用 long
|
13
huiyadanli 2022-08-04 10:48:16 +08:00
金额精度后端处理
金额展示前端处理 |
14
aijam 2022-08-04 10:48:33 +08:00
|
15
Cu635 2022-08-04 10:49:33 +08:00
“我偏向前端只做交互和渲染,不做数据处理”
说的对,千分位就是数据显示问题,可以说是“渲染”,而实际的数据完全是不涉及的,所以 lz 问题的回答就是“应该前端处理”。类似的还有小数点是用逗号还是圆点,小数部分是不是要缩小一个字号这种问题。 lz 可以这么想一下:如果数据不再用逗号做千分位了,而是用空格,那么数据是不是就变化了?是不是 1 000!=1,000 ? |
16
lingxiaoli 2022-08-04 10:51:02 +08:00
@MrdotX #7 你说的精度是指分? 后端存的时候就是按分存的 给前端的时候前端按 ui 以及业务要求来做相应处理
|
18
Jooooooooo 2022-08-04 10:52:00 +08:00
后端做的好处是, 能更灵活的去调整这个展示的样式.
前端只单纯展示一个字符串. |
19
damai0419 2022-08-04 10:54:41 +08:00
这种偏向前端处理。
像金额类的,后端基本要保存为币种的最小单位。 这串数字反给前端,前端怎么展示,很可能不同的终端不一样。¥ 1 ,000 ;一千元;壹仟元; 1000 元 等等的。 |
20
ecloud 2022-08-04 10:54:42 +08:00
@MrdotX 精度问题,最好让后端改成用 long 存储,然后再给你返回一个 point (小数位)。比如 (1234567|point=3) => 1234.567 (分隔符取决于 locale )
|
21
wangtian2020 2022-08-04 10:56:42 +08:00
后端提供原始数据,前端负责格式化显示
如果仅做一处数据的显示,也能后端提供 |
22
Routeros 2022-08-04 10:57:01 +08:00
我赞成前端做
|
23
MrdotX OP Fine.. 领导说要前端做。。
|
24
MrdotX OP 沉了沉了
|
25
GeorgeGalway 2022-08-04 11:00:07 +08:00 3
我们前端是个美丽的小姐姐,所以当然是我大后端处理
|
26
fzdwx 2022-08-04 11:02:02 +08:00
|
27
wccc 2022-08-04 11:03:56 +08:00
如果是美丽小姐姐,那就我来
|
28
wccc 2022-08-04 11:05:09 +08:00
前端修改比较合适,毕竟只是格式处理
|
29
Jooooooooo 2022-08-04 11:07:41 +08:00
@fzdwx 如果是客户端, 你还得发版等着用户去用户商店更新才能生效. 咋会更灵活.
|
30
fzdwx 2022-08-04 11:45:43 +08:00
|
31
fkdtz 2022-08-04 12:08:13 +08:00
OP 身为一名前端,此时正在处理
|
32
28Sv0ngQfIE7Yloe 2022-08-04 12:11:49 +08:00
|
33
otakustay 2022-08-04 12:18:26 +08:00
金额加逗号显然是渲染的事,你作为前端就算只做交互和渲染,也应该把这事做了
|
34
Jooooooooo 2022-08-04 12:42:29 +08:00
@Morii 我说的灵活是指更新的灵活, 不是实现上的灵活, 具体的逻辑看下 29l
|
35
28Sv0ngQfIE7Yloe 2022-08-04 12:50:06 +08:00
|
37
hayvane 2022-08-04 13:12:55 +08:00
前端处理,另外 [我偏向前端只做交互和渲染,不做数据处理] ,其实,在实际工作中,有时候前端也是要做数据处理的
我也是前端( app+小程序) |
38
yaphets666 2022-08-04 13:45:37 +08:00
写个处理函数就行,咱是按天算钱的,不计件,多干点活没事,只要不加班就行.
|
39
cnoder 2022-08-04 14:56:51 +08:00
理论上输入和输出格式要一致,你觉得你给后端金额的时候会传 100,454.21 这种数据吗
|
40
fernandoxu 2022-08-04 16:09:57 +08:00
Intl.NumberFormat
|
41
janda 2022-08-04 16:33:52 +08:00
金额计算 - 后端
金额显示 - 前端 |
42
h1104350235 2022-08-04 16:35:50 +08:00
显示问题,一般是前端处理。
像这个数据结构的话,我一般会抽出个方法处理。 |
43
phobal 2022-08-04 18:00:51 +08:00 via iPhone
一行代码的事儿 Number.prototype.toLocaleString()
|
44
adjusted 2022-08-04 18:33:20 +08:00
后端,前端多个平台所有人都得改一遍
|
45
kkfnui 2022-08-04 19:02:09 +08:00
|
46
zjuster 2022-08-04 19:38:45 +08:00
前端处理。
用实际例子说一下,德国等国家的的千分号单位是“.”或者空格,小数是“,”。 德国 123 456 479, 00 或者 123.456.789,00 我国 123,456,789.00 为了适应当地的习惯和策略,前端展示上不同,但对账的时候的数值大小是一致的。 所以前端做展示,后端提供统一的财务数据比较合适。 |
47
zhuweiyou 2022-08-04 20:58:55 +08:00
前端处理,因为金额可能会做计算,比如*数量=总价,你后端返回带逗号的,你怎么做计算?
|
48
godblessumilk 2022-08-05 11:58:57 +08:00
必须是前端处理。因为你的系统以后可能会拓展到全世界,到时候有的用户用美元、有的用户用欧元做单位,你让后端全给你算一次吗?还有,关于时间的显示,一律让后端只返回时间戳,不可以返回处理好了格式的日期,因为你永远不知道你的前端用户在哪个时区
|
49
Cu635 2022-08-08 22:52:42 +08:00
@ecloud #17
说的对对,只不过我个人很不喜欢这种不统一又没有实际意义的人为差别,所以宁可跟着 lz 用“渲染”这个关键字。 @GeorgeGalway #25 既然是美丽的小姐姐是前端,不更应该让前端处理么,遇到问题了可以上去交流啊。 |