在视图中大量使用方法会妨碍缓存吗？

我正在尝试在我的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和虚构类BEMBlockBuilder与方法#element（其中的一个实例是如b传递）被定义，并且假设current_user.unregistered?是我们应该得到如下的HTML输出：

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

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

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

这种技术和form_for助手之间的主要差别是，你可能最终使用嵌套块的多个渲染的图，其中的输出可能是未知的。

此技术是否会影响Rails（或HAML）以否定方式执行缓存的能力，还是会损害整体渲染性能？

来源

2014-11-15 Gabriele Cirulli

如果你的助手是纯函数 - 它不应该，因为函数的结果是可预测的。但一切都取决于你使用的助手的内部逻辑。在某些情况下，这可能是一个麻烦。 –

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

虽然案件的页面缓存或动作缓存相当明显，其原因俄罗斯娃娃缓存也通过自定义视图建设者不受影响是因为，如果模型的cache_key不会改变 - 传递给cache助手没有得到该块无论在下面调用的视图构建器如何重新评估。

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

除此之外，唯一的关键问题是streaming of templates将很难处理。如果这与你的用例无关，那么你很好。特别是，如果您使用HAML，那么您无论如何都可以使用can not use。但是，您可以考虑探索一些关于处理流模板的有趣想法。

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

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

这显然是更冗长，而且还容易使在多个块被应用到相同的DOM元素，这是有效的BEM您处理案件。

最后，这里是从extremely well written article一些关键外卖由贾斯汀·魏斯在视图渲染性能评估：对于业绩的边际收益

牺牲可维护性很少一个很好的解决方案
复杂的逻辑，不属于意见
分析工具是你的朋友。

来源

2015-10-17 22:04:03 lorefnon

在视图中大量使用方法会妨碍缓存吗？

回答

相关问题