很多骨干观点 - 性能问题？

Question

TL;博士:我不知道是否有大量(100+就目前而言,可能高达1000/2000或更多)的骨干意见(作为表的单元格),太重或不

我正在研究的项目围绕着一个规划视图.每个用户一行,每天6小时,每小时分为4个15分钟.此计划用于在单击插槽时添加"预留",并应处理正确插槽的悬停,并且还可以在无法进行预订时进行处理 - 即.防止用户点击"不可用"的插槽.

无法单击插槽的原因有很多:此时用户不可用,或者用户正在预订中; 或者应用程序需要"强制"两次预订之间的延迟时间.预留(div)在一个槽(表格的一个单元格)中呈现,并通过使用维度进行处理,悬停正确数量的槽.

所有这些屏幕都是用骨干处理的.因此,对于我正在徘徊的每个插槽,我需要检查是否可以在此处进行预订.到目前为止,我通过使用data插槽上的属性来使用它:当添加预留对象时,覆盖的插槽"用(以及其他)预留对象(骨干视图对象)增强.

但在某些情况下,我现在还没有完全掌握,它会混淆,当删除预订视图时,插槽不会"清理":前一个class没有正确重置.这可能是我做错了或做得不好的事情,但这只会变得更重; 我想我应该在这里使用另一类Backbone视图,但我担心视图对象的插槽数量会很高并导致性能问题.我不知道js perf的情况,所以我想在跳上那列火车之前得到一些反馈.关于如何做到这一点的任何其他建议也会受到欢迎.

谢谢你的时间.如果这还不够清楚,请告诉我,我会尝试重新措辞.

Answer 1

我们有一个非常复杂的backbone.js应用程序,在给定时间可能有数千个视图.我们的瓶颈主要是来自未正确删除的视图的内存泄漏或者事件驱动渲染不必要地重新呈现视图.也就是说,实际的观看次数似乎并没有太大影响.骨干视图非常轻量级,因此只要您没有太多绑定它们的事件,它就不是那么大的问题.

您可能遇到性能问题,但视图可能不是问题.

你可能想要做的事情,如果你确实使用了数千个视图,那就是将初始渲染存储到一个大的'.()'调用中.您可以通过基于视图的cid为每个view-element提供一个id,然后连接视图的html字符串,然后在每个视图上使用setElement再次查找其元素.