我有一个DataTable,里面有几千条记录。
我有响应式插件,启用了响应式选项。
我也试过启用deferRender选项,但这似乎对所花费的时间没有影响。
当我调整浏览器大小时,会有1秒到2秒的延迟。这发生在IE11和MS Edge中。镀铬的性能并不是很棒,但在0.5秒时它是可以容忍的。
我正在使用自定义排序功能,但为简洁起见,省略了这些功能。我很确定我知道问题出在哪里,而且不在其中。如果需要,我可以提供。
这是我的初始化代码:
this._dataTable = $("#listtable").DataTable({
paging: true,
responsive: true,
deferRender: true,
columns: [{
title: "Name",
data: "thing.name"
}, {
title: "State 1",
data: "state1",
type: "state1",
render: (data, type, row, meta) => {
return this._renderState1(data, meta);
}
}, {
title: "State 2",
data: "state2",
type: "state2",
render: (data, type, row, meta) => {
return this._renderState2(data, meta);
}
}]
});
我通过为每个项调用dataTable.row.add来加载数据,然后在最后调用dataTable.draw。
在成功加载所有数据后会出现性能问题,因此我不认为这样做。
进一步深入了解剖析器信息,我发现这是行的渲染问题:
通过在initalisation代码中显示的自定义渲染函数中注释掉代码,我发现问题在于找到包含单元格来设置背景颜色:
var cell = this._dataTable
.cell({ row: meta.row, column: meta.col })
.node();
以下是设置背景颜色的其余代码:
var cellClass = this._getStateClass(state);
$(cell).addClass(cellClass);
如果我评论细胞检索线,那么表现并不令人惊讶,但这是可以接受的。
所以我的问题是如何在保持响应性能的同时为单元格提供自定义背景颜色?
dataTable.cell的快速替代方案,以及设置背景颜色的替代方法。
答案 0 :(得分:1)
我设法通过删除找到单元格的需要来解决这个问题。
我在删除了填充的列上放了一个类。
风格:
.cell-state1 {
padding: 0;
}
配置:
this._dataTable = $("#listtable").DataTable({
paging: true,
responsive: true,
deferRender: true,
columns: [{
title: "Name",
data: "thing.name"
}, {
title: "State1",
data: "state1",
type: "state1",
className: "cell-state1",
render: (data, type, row, meta) => {
return this._renderState1(data, meta);
}
}]
});
然后我更改了渲染功能,所以他们将内容返回到填充单元格的div中,具有背景颜色,然后重新添加填充。
风格:
.cell-state1-somestate {
height: 100%;
width: 100%;
padding: 8px;
background-color: #000000;
color: #ffffff;
}
渲染功能:
function _renderState1 (state1) {
var cssClass = _this._getState1CellClass(state1);
var text = _this._getState1CellText(state1);
var content = "<div class='" + cssClass + "'>" + text + "</div>";
return content;
};
这给我留下了最后一期。
我有自定义顺序函数,现在不是传递文本值而是传递包含文本值的div。
我使用了一点jQuery来提取文本:
var floodAlertSeverity = $(content).html();
。
如果订单功能收到原始数据而不是渲染数据,那就太好了,但是哦。好吧。
答案 1 :(得分:0)
我有一个类似的问题,即在以响应模式调整浏览器窗口大小时,IE11变得非常慢,这给用户带来了非常糟糕的体验。
我没有时间也没有专业知识来解决根本的问题(可能只是IE11速度慢),但是我想出了一个优雅的解决方案来解决该问题,基本上是在限制对该函数的调用调整列的大小。
IE11中的性能分析器显示,对_fnAdjustColumnSizing(oSettings);
的调用占用了大部分CPU时间,并且对该方法的调用由'resize.DT-YourTableNameHere'
事件触发,因此可以使用一个简单的计时器来延迟直到用户完成调整窗口大小之前对此函数的调用:
var dtResizeTimer;
var allowPropagation = false;
$(window).on("resize.DT-visitsTable", function (event) {
if (allowPropagation === false) {
event.stopImmediatePropagation();
clearTimeout(dtResizeTimer);
dtResizeTimer = setTimeout(function() {
allowPropagation = true;
$(window).trigger("resize.DT-visitsTable");
}, 100);
} else {
allowPropagation = false;
}
});
显然,您需要将visitsTable
替换为id
元素中的任何table
。
在用户调整大小之后,IE11仍然需要一秒钟来更新表,但是至少调整大小本身现在很平滑。也许有更好的解决方案,但是就目前而言,这使我对IE11的沮丧情绪平静了。