我最近一直想知道是否有可能使用与Twig相同的语法模板系统进行客户端模板化,以及与Twig的集成。找到了Swig,这似乎是“用于javascript的Twig”。
使用相同的语法可能有几个好处:
然而,会出现一些挑战:
{% raw %}
标签可以完成工作,但是...... <head>
中收集我希望可用于前端模板引擎的所有块,每个块都包含在<script>
标记内。所以我需要“原始 - 包含”这些块。有没有人将Twig与Swig或任何其他javascript模板系统结合使用,其语法与Twig的语法有些冲突? 您将如何管理/组织模板,以便您也可以轻松地在前端使用模板?
答案 0 :(得分:0)
免责声明:这是一个开放式问题的公开答案,牢记这一点 请。我分享了我的经验,因为没有简单,单一的方式来回答这个问题。
我是一名前端网络开发者,与symfony人密切合作。回到过去,我们一起使用了树枝和胡子模板。小胡子模板duplictad枝条,无论哪里需要ajax调用。很明显,这是一个巨大的维护费用。
我将答案分为两部分,分别处理两个问题;构建模板以使它们易于前端化,并添加twig的javascript实现。
模板结构
我们采用逻辑组织模板的第一步是将它们分为页面级,功能性和演示文稿模板。
页面级模板是定义应用内容的常规容器的模板。 想一想:
功能性模板只需更深入一步。它们是用于构建整个页面的预制件。通常它们是来自后端的数据的点。例如,可以考虑容器中的用户列表。功能模板是容器,包括表示模板,将数据传递给它。
演示模板只是没有逻辑(没有数据转换)的组件,意味着要提供数据。这些组件可以嵌套。 (例如,按钮和标题都包含在 CTA 组件中)。演示组件是我们构建模块中最精细的元素。
以这种方式组织代码花费了很多时间,但允许我们对必须能够进行前端渲染的组件和可能具有逻辑重量的组件进行明确的区分。
<强> Twig.js 强>
下一步是整合(正如其中一条评论中所建议的)twig.js。
我想在我的主要HTML文件中收集我希望可用于前端模板引擎的所有块,每个块都包含在标记内。所以我需要&#34; raw-include&#34;这些街区。
使用twig.js,您不必担心为前端制作模板。您可以只提供网址,如果模板扩展或包含其他一些模板,则可以异步加载&#39; ll。因此,用json数据提供的twig模板由javascript呈现,并且不需要额外的模板引擎。
我从未进行任何性能测试。虽然我可以想象twig.js比胡子慢得多,但在twig.js中只渲染无逻辑的组件可以大大提高性能。
如果我没有解决任何问题,请告诉我。我渴望进一步讨论这个问题。