1

我正在尝试在我的 Rails 4 应用程序中实现BEM助手，以帮助我更愉快地编写视图。

假设我们有以下Haml视图：

= block :user_bar, unregistered: current_user.unregistered? do |b|
  - if current_user.unregistered?
    = b.element :inner do
      You are not registered.

假设定义了和具有方法block的虚构类（其中的实例作为 传递），并假设是，我们应该得到以下 HTML 输出：BEMBlockBuilder#elementbcurrent_user.unregistered?true

<div class="user-bar user-bar--unregistered">
  <div class="user-bar__inner">
    You are not registered.
  </div>
</div>

这种技术应该可以设置块、元素并对其应用修改器，而不必每次都重复块的名称，并且它可以简单地基于绑定到它们的值是真实的来应用修改器。

该技术本身与使用帮助程序时发生的情况有些相似form_for，因为它将一个实例传递FormBuilder给块。

这种技术和form_for助手之间的主要区别在于，您最终可能会使用大量嵌套块来渲染视图，而这些视图的输出可能是未知的。

这种技术会影响 Rails（或 HAML）以负面方式执行缓存的能力，还是会损害总体渲染性能？

4

1 回答 1

0

不，您建议的实现不会对缓存产生负面影响 - 这包括页面缓存、动作缓存以及俄罗斯娃娃缓存。

虽然页面缓存或动作缓存的情况相当明显，但俄罗斯玩偶缓存也不受自定义视图构建器影响的原因是，如果cache_key模型不改变 - 传递给cache助手的块不会被重新评估，而不管在下面调用的视图构建器。

以上假设您避免构建器中的隐式状态。亚历克斯已经在评论中强调了可预测性的重要性。

除此之外，唯一的关键问题是模板流处理起来很棘手。如果这与您的用例无关，那么您就可以开始了。特别是，如果您使用的是 HAML，那么无论如何您都不能使用流式传输。但是，您可以考虑探索线程以获取有关处理流模板的一些有趣想法。

如果你想避免这个问题，你可以考虑使用小的帮助函数来根据 BEM 生成类名。然后你可以使用类似的东西：

<div class="<%= bem_class(block: 'user-bar', el: 'inner', mods: ['unregistered']) %>">
</div>

这显然更冗长，但也很容易让您处理多个块应用于同一个 DOM 元素的情况，这在 BEM 中是有效的。

最后，以下是Justin Weiss 撰写的关于视图渲染性能评估的一篇非常出色的文章中的一些关键要点：

  • 为了性能的边际收益而牺牲可维护性很少是一个好的解决方案
  • 复杂的逻辑不属于视图
  • 分析工具是您的朋友。
于 2015-10-17T22:04:03.280 回答