这是一个创建于 2160 天前的主题，其中的信息可能已经有所发展或是发生改变。
Ajax 直接根据业务实体生成并返回 html 片段是否一定是糟糕的设计？
 |
1
Vegetable 2019-01-24 00:08:54 +08:00 via iPhone
想洗一下发现功力不够，我觉得肯定有合适的场景，不比其他方案差，但是我想不出来…
|
 |
2
qq292382270 2019-01-24 00:12:10 +08:00
要么服务端返回 html, 要么 js 通过返回的 data 拼接成 html,并未有多大的区别吧 .
|
 |
3
CODEWEA 2019-01-24 00:15:06 +08:00  1
技术方案一定要符合业务实际需求
直接返回 HTML 片段的优势有：减少客户端负载，减少维护成本，客户端体验更流畅。 劣势：逻辑拼接增加服务器负载，技术人员会看起来很 low，不符合潮流，不利于接口重用（要考虑是否真的需要重用，已经重用成本） |
|
4
CODEWEA 2019-01-24 00:15:33 +08:00
以及重用成本
|
 |
5
akatquas 2019-01-24 00:16:36 +08:00 via iPhone 1
ajax 原名就是 XMLHttpRequest 啊...
返回 xml 没毛病，只不过现实场景不多用了，http 请求中大多都用字符串如 json 了而已。 我这个洗的还好吗？ |
 |
6
saulshao 2019-01-24 00:17:46 +08:00
返回 HTML 片段绝大多数是糟糕的设计。
需要用到 Ajax 的时候，都是将结果作为某个整体 HTML 页面的一部分。 大多数的设计都是返回 Json/XML 甚至是自定义的字符串。 对比返回 HTML 片段的设计，如果返回的 HTML 片段不能作为整体页面的一部分来显示，典型的例子是 Ajax 返回一个 HTML 表格，以 Table 开头，有的时候需要把这个表格的某列显示为一个链接，有的时候则不需要。那么就是要么设计 2 个不同的 Ajax API，要么就分析 HTML 片段，显然这都不是什么很好的办法。 |
 |
8
580a388da131 2019-01-24 00:23:42 +08:00 via iPhone
你把数据和样式分开，最后送到客户端 html，这样应该凑合吧。
|
 |
9
akira 2019-01-24 00:23:49 +08:00
如果前端和后台都是你一个人在做，以后也一直是你一个人在维护，那没关系
|
 |
10
szx237560 2019-01-24 00:25:35 +08:00
|
 |
11
KasuganoSoras 2019-01-24 00:26:36 +08:00
并不觉得有什么不好，有时候直接返回 html 还是挺方便的
比如： https://mirror.ssr.wine/ 评论区 AJAX 轮询、选择服务端分类 还有： https://www.zerobbs.net/ 帖子列表翻页，评论区 WebSocket 怎么方便怎么来，看自己喜欢。除非你是在帮别人做项目，那就按照别人的要求来做吧 就我个人而言，因为我并不擅长前端的 Js 那些的，我觉得直接在服务端写 HTML 更方便点，自然我会选择在 AJAX 里返回 HTML。 我这个洗的还好吗？ |
 |
12
FEDT 2019-01-24 00:32:45 +08:00 via iPhone
Pjax，看看 gayhub
|
 |
13
yunye 2019-01-24 00:47:06 +08:00
turbolinks 岂不是 low 翻天了
|
 |
14
azh7138m 2019-01-24 00:53:17 +08:00 via Android
gitlab 也这么操作，问题不大
|
 |
15
byis 2019-01-24 01:01:52 +08:00 via Android
pjax
喵喵喵? |
|
16
byis 2019-01-24 01:02:33 +08:00 via Android
虎嗅网就是这样的
|
 |
17
masker 2019-01-24 01:12:22 +08:00 via Android
不都是字符串咩？
|
 |
18
msg7086 2019-01-24 01:59:20 +08:00
都可以，根据实际需要返回数据就行了。
|
 |
19
Archeb 2019-01-24 02:20:08 +08:00
一般应用在 pjax
|
 |
20
hundan 2019-01-24 07:26:53 +08:00 via Android
我知道新浪微博的评论加载是这样的
|
 |
21
ChefIsAwesome 2019-01-24 08:39:55 +08:00
跟套模板一个道理。前端写好 html 给后端套，之后再要改了就费劲。
|
 |
22
66beta 2019-01-24 08:46:42 +08:00 via Android 1
你这是模块化服务端渲染，简称 mssr，说不定成为今年流行！
可还行？ |
 |
23
yinqi025 2019-01-24 08:59:32 +08:00
这样直接返回 Html 不说性能什么的, 维护工作就很麻烦!!!!谁知道你后台组装了多少 html
|
 |
24
ebingtel 2019-01-24 09:03:59 +08:00
脱离应用场景和需求讨论这个有啥意义……
|
 |
25
hasbug 2019-01-24 09:08:06 +08:00
比较难配合工作，后期维护成本也高，反正···
|
|
26
hasbug 2019-01-24 09:09:05 +08:00
6 年前都这么干，然后天天页面布局错乱，找了半天，后端自己拼的 html 少各种结束标签···
|
 |
27
zwb9412 2019-01-24 09:11:51 +08:00 via Android 1
遇到过返回 html 的 里面还带 js 脚本，js 脚本有 bug 极难调试。。
|
 |
28
brofen 2019-01-24 09:15:24 +08:00
微博好像是这么干的
|
 |
29
keelii 2019-01-24 09:21:32 +08:00
恰恰相反，很多时候返回 html 其实更方便，也更具有跨应用的复用性。唯一问题就是 HTML 代码比较冗余，需要考虑 HTTP 请求传输数据量的问题。
|
 |
30
fkdog 2019-01-24 09:29:41 +08:00
微博、apple 官网各种这么干。
根据自己实际来。 |
 |
31
vinsony 2019-01-24 09:32:28 +08:00
没毛病，10 年前我就是这么干的
|
 |
32
qinxi 2019-01-24 09:33:23 +08:00
微博翻页就是这样啊
|
 |
33
carlclone 2019-01-24 09:34:35 +08:00
pjax , 没毛病
|
 |
34
guanhui07 2019-01-24 09:38:12 +08:00
区别不大 看那一层套上模板。
|
 |
35
sambawy 2019-01-24 09:39:13 +08:00
脱离现实场景聊这个就是耍流氓
|
 |
36
lymi2771 2019-01-24 09:45:30 +08:00 via iPhone
我觉得没有任何问题
有人说不利于接口复用 我觉得这个 route 就是需要返回一个 view 也没什么问题吧？ 不然普通的页面怎么访问的呢 服务端渲染这样的场景我觉得还是很多的 |
 |
37
zst 2019-01-24 09:46:40 +08:00 via Android
twitter 也这么干的 23333
|
 |
38
BOYPT 2019-01-24 09:48:39 +08:00
没问题呀，而且这个技术还有专门的名词：服务器端渲染
|
 |
39
ioven 2019-01-24 09:50:28 +08:00
很 low，可自己用的很爽
|
 |
40
Yiki 2019-01-24 09:59:45 +08:00
传 svg 算不算 html 片段
前端也省事儿，不能太片面吧 |
 |
41
mostkia 2019-01-24 10:08:24 +08:00
只要前后台不打起来，用什么交换数据都是 ok 吧。。我是前后台都做，感觉无所谓，但一般使用 json 吧，数据和表现分离，后期好维护一些，有时候想改改版面也更方便，但又需要的情况下，直接返回 html 我感觉并无什么不妥。
|
 |
42
FakeLeung 2019-01-24 10:10:48 +08:00
low 咋滴啦？用的爽就好了。
|
 |
43
doodlewind 2019-01-24 10:24:45 +08:00
我是搞前端编辑器的，简单来说，假如我的业务场景（编辑器）动态性非常强，那么一些插件就需要依赖后端的能力来生成 html 返回给前端，这时候接口里包含 html 片段也是可能的呀，至少据我所知 confluence 的富文本编辑器就是这么干的。
当然了 confluence 这个编辑器的架构设计是前后端不分离的，编辑器插件都是 jar 包，现在的前端架构设计应该可以杜绝这样的实践了吧。 |
 |
44
SakuraKuma 2019-01-24 10:27:44 +08:00
很多都这么干好嘛..
|
 |
45
tao1991123 2019-01-24 10:31:49 +08:00
pjax 没毛病
|
 |
46
miniwade514 2019-01-24 10:40:27 +08:00
简单地理解，这个方案只是把 HTML 放到服务端渲染了。
应该也不存在接口不好复用的问题，你在服务端把渲染 HTML 的服务和数据服务拆分成两层，数据服务也是可复用的。 适合前端交互不复杂的场景。 |
 |
47
litbear 2019-01-24 13:55:11 +08:00
pjax 啊
|
 |
48
meepo3927 2019-01-24 14:54:58 +08:00
后端写 HTML 体验很差吧 ， 字符串拼接？
|
 |
49
Dogergo 2019-01-24 14:59:53 +08:00
有一个场景，新旧产品都需要我点击名称的时候弹出一个弹窗，但是根据新旧产品的不同，弹窗样式包括数据个数发生了很大变化，我弹窗层用的是 layer，我放在前端 js 里去判断是不是不太好，而我如果放在服务端，我之需要一个接口，拼接好 html，分配变量进去，返回，很完美，代码复用性更好。
|
Select Language