脚本标记中的客户端模板。优点缺点？

Question

对于将单页Java应用程序的客户端模板放在HTML文件中的脚本标记中的当前趋势感到好奇。似乎是一种有趣的方法，但这被认为是最佳实践（或至少是一种更好的实践）？我试图找出一个优点和缺点列表，但坏的列表似乎超过了好处。 所以我看到它的方式是：

优点：

1. 只有一个请求获取所有模板，而不是每个模板文件的单个异步请求。

缺点：

1. 如果所有模板都在一个位置
，则创建潜在的合并故障点/瓶颈文件
2. 在一个文件中编辑模板有点麻烦
3. 使用键盘快捷键打开文件，找到所需的模板有点麻烦。
4. 在使用模板做任何事情之前，必须等到DOM准备就绪。

看起来，如果将它们放在脚本标记中，您可以预编译和缓存模板，这样您只需查询DOM一次即可获得每个模板。但是，使用AMD / Require和require / text无法达到相同的效果！或道场/文字！？在后一种情况下，您只是懒得加载每个模板一次。然后你可以缓存它并在那时预编译它。

我正在努力看到脚本标签中模板的许多优点。我错过了什么吗？

Answer 1

恕我直言，这真的取决于你有多少个模板。当您的网站刚开始并且您没有很多模板时，将它们全部保存在单个HTML页面上的script标记中会非常有意义。

但是，随着模板数量的增加，很快就会变得难以处理;不久之后，您将使用服务器端逻辑将一堆单独的模板文件连接到主HTML文件中，此时我认为开始考虑其他方法是完全合理的。

就我个人而言，我公司的代码库始于HTML文件中的script标签，但是随着我们的成长（并开始使用require），现在我们已经有数十甚至数百.handlebars {{}我们所有模板的1}}（或更常见的是.hbs）文件。我们使用Alex Sexton的HBS插件（https://github.com/SlexAxton/require-handlebars-plugin）将这些内容添加到我们的Javascript中，因为：

1. 我们将标准require系统用于我们的模板
当我们使用require optimizer 时，
2. 模板被编译为单个压缩的JS文件
3. 我们可以将我们的IDE配置为将.handlebars文件视为HTML，为我们提供适当的语法着色，以及我们编辑它们时

我不确定您使用的是哪个模板系统，但是如果您使用的是Handlebars并且已经使用了需要，那么HBS插件是一个很好的方法。如果您使用不同的模板系统，您可能会找到一个类似的插件用于Require（如果该系统足够流行），或者甚至使用HBS编写自己的插件作为基础。

对于拥有相当数量模板的人来说，我认为这样的系统（对于已经使用Require的人来说，尤其是）比script标签更有意义。

Answer 2

如果我理解正确，您需要使用一些客户端模板，但是您希望将它们分成服务器端的单个文件。当你有很多这样的模板时，这种方法有一些明显的工程优势。

您可以考虑使用JSONP。如果服务器端有一个半合适的处理程序，那么您将获得所需的好处：

1. 每个模板的单独文件
2. 轻松收录到您的HTML网页。
3. 能够将每个模板分配给变量，或者在客户收到变量后立即通过编译功能发送。
4. 在客户端缓存模板，因此不必为每个页面重新加载它们。
5. 与缓存代理的兼容性

JSONP实现中唯一不重要的部分是缓存属性。您需要确保接收请求的服务器端控制器理解条件GET，如何发送304响应，以及正确设置缓存头。

如果您不熟悉该技术，可以查看JSONP wikipedia entry。