在服务端渲染部分视图或在客户端发送 json 数据和渲染模板

Posted 2023-05-07

【中文标题】在服务端渲染部分视图或在客户端发送 json 数据和渲染模板

【英文标题】：Render partial view on the server or send json data and render template on the client

【发布时间】：2012-01-22 17:50:08

【问题描述】：

我想知道在 Web 应用程序中呈现部分视图的好方法（或推荐方法）是什么。

我有一个要求，我需要使用 AJAX 将数据加载到已经呈现的页面中，有点像页面末尾的 “加载更多...” 链接，它可以获取更多信息来自服务器并将其呈现到页面底部。

目前我正在使用的 AJAX 响应的两个选项是

返回数据的 JSON 表示，并使用客户端模板库（例如 jQuery 模板）或纯 javascript 将 JSON 转换为 html 并附加到页面底部 在服务器上渲染部分视图（在我的例子中使用 grails 的render template:'tmplt_name'）并通过网络发送它，然后将结果附加到页面底部

还有其他方法可以做到这一点吗？如果不是，考虑到上述选项，在维护、性能和可测试性方面哪个更好？我可以确定的一件事是，JSON 路由（在大多数情况下）将比通过网络发送 html 占用更少的带宽。

【问题讨论】：

我怀疑您已经在用户第一次接触页面时呈现类似的内容，就像您打算使用“加载更多链接”一样。以相同的方式单击“加载更多”后加载正在加载的内容并重用您已经为此编写的代码是否没有意义？你的问题很有趣，我想看看你和其他人对这个话题的想法是什么

是的，在第一次交互时，我重新使用相同的模板（在第 2 点中）来呈现完整的页面（以及页面的其他静态部分）。这两个选项都对我有用，而且我在零散的事情上都使用了它们。我也很想看看其他人对此的看法。

【参考方案1】：

这实际上是一个非常有趣的问题，因为它揭示了一些有趣的设计决策。

我更喜欢渲染部分模板，因为它使我的应用程序能够随时间变化。如果我需要使用图表从<table> 更改为<div>，很容易将其封装在模板中。考虑到这一点，我将几乎每个页面都视为许多小模板的集合，这些模板可能会发生变化。 Grails 2.0 默认的脚手架已经转向这种方法，这是一个好主意。

它们应该是客户端模板还是服务器端的问题是问题的症结所在。

服务器端模板使您的标记在初始页面加载时保持整洁。即使您使用 Mustache 或 ICanHazJS 之类的东西，您也需要在页面中有一个空元素（与您的模板有关），适当地设置它的样式，并在 Javascript 中使用它以更新您的信息.

缺点

“健谈”应用程序 网络上更大的信封（响应包括 HTML，可能被认为是静态的） UI 响应时间变慢

好处

适合有大量服务器端语言经验的人 在服务器端环境中可能更容易操作或修改（例如，返回嵌入了多个模板的页面，这些模板以编程方式加载和包含） 将大部分应用程序内容“保存在一个地方”

但是，客户端模板确实可以减少服务器负载。他们使应用程序“不那么闲聊”，因为您可以通过发回更大的 JSON 集合（以相同数量或更少的字节数，将由 HTML 在服务器端模板方案）。它们还使用户的 UI 体验非常快速，因为单击“更新”链接不必进行 AJAX 往返。有人说：

Anthony Eden @aeden 12 月 10 日回复 转推 收藏 · 打开 Web 应用的未来：请求由函数处理，逻辑始终是异步的，并且永远不会在服务器上生成 HTML。

缺点

不适合 SEO（初始页面加载时的非语义无关 UI 元素） 需要一些 Javascript foo（操作元素）

好处 - 响应式 - 更小的信封

趋势似乎正在转向客户端模板，尤其是 HTML5 附加功能（如<canvas>）所展现的强大功能...但如果利用它们需要您依赖您不太熟悉的技术，那么您对 Grails 部分感到更舒服，可能值得从这些开始，然后根据性能和其他问题研究对客户端模板的重构。

【参考方案2】：

在我看来，第二个选项 rendering partial 更好，因为如果您获得 json 数据，您应该像设置样式、创建元素、设置值和在您在 javascript 中获得 ajax 响应之后，根据需要进行类似的操作，但如果您呈现部分视图，您可以在该部分之前设计您的视图并保持准备状态，只需使用 ajax 调用导入，因此无需处理响应数据。

【参考方案3】：

我会说这取决于您通过网络发送的数据量。如果您正在实现“加载更多”功能，那么您似乎不想花 5 秒钟来加载某些内容。谷歌图片是该功能应该有多快的一个很好的例子。如果您知道您永远不会拥有那么多数据，那么在服务器上渲染部分数据可能会更干净，但如果您的需求发生变化，那么回到第一种方法会很麻烦。所以简而言之，我想说第一种方法允许更多的灾难控制，只要加载更多需要多长时间才能加载大量数据。我想说的是，尽可能减轻服务器的负载也是一种普遍的好习惯，即使它在客户端对开发人员来说有点不方便。

【讨论】：

数据主要是一些水处理样品的简单文本值。加载基本上是抓取一些与首次交互加载不太相关的互补历史数据，除非用户需要它。为了减轻服务器的负载，我认为通过适当缓存部分模板，这应该不是问题吗？