AG-Grid大数据量场景下的筛选优化实践

背景介绍

在基于AG-Grid开发的企业级应用中，处理超大规模数据集（超过10万行）时通常会采用服务器端行模型（SSRM）。这种架构下，筛选功能也需要从后端获取数据。当用户在前端进行多值筛选时，如果选择数量过大（如超过1000个值），会导致服务器请求压力过大甚至崩溃。

核心问题分析

在AG-Grid的筛选交互中，存在两个关键的技术挑战：

1. 多值选择限制：默认情况下，Excel风格的筛选器没有提供限制选择数量的机制
2. 键盘事件控制：即使用户界面禁用了"应用"按钮，用户仍可通过回车键触发筛选请求

解决方案探索

初始方案：前端交互控制

开发者最初尝试在前端实现选择数量限制：

onFilterModified(params) {
    const totalValues = params.filterInstance.valueModel.availableKeys.size;
    const selectedCount = params.filterInstance.valueModel.selectedKeys.size;

    const isInvalid = selectedCount !== totalValues && selectedCount > MAX_FILTER_SELECTION;

    if (isInvalid || selectedCount === 0) {
        this.disableApplyFilterButton(isInvalid);
    }
}

这种方法虽然可以禁用应用按钮，但无法拦截键盘事件，导致限制措施被绕过。

替代方案：自定义筛选模式

尝试改用非Excel模式的筛选器配置：

filterParams: {
    buttons: ['apply', 'cancel'],
    closeOnApply: true,
    values: this.getFilterData.bind(this),
}

但发现新的问题：在迷你筛选输入框中输入内容后点击"应用"按钮，弹出窗口会关闭但不会触发请求，只有按回车键才有效。

最终解决方案：请求拦截机制

经过多次尝试，最终采用以下策略：

1. 保持Excel模式(Windows风格)的筛选器
2. 在请求发出时进行拦截检查
3. 当筛选值超过限制时：
   • 返回当前数据集
   • 清除违规的筛选条件

// 伪代码示例
interceptRequest(params) {
    if (params.filterValues && params.filterValues.size > MAX_LIMIT) {
        this.gridApi.setFilterModel(null);
        return currentData;
    }
    return fetchFromServer(params);
}

技术要点总结

1. SSRM架构特性：服务器端行模型需要特别注意前端交互与后端请求的协调
2. AG-Grid事件机制：理解筛选器内部的事件触发顺序是关键
3. 防御式编程：在无法完全控制用户操作路径时，需要在多个层面设置防护措施

最佳实践建议

对于类似场景，推荐采用分层防御策略：

1. 前端限制：设置合理的默认选择范围
2. 交互反馈：及时提示用户操作限制
3. 后端防护：即使前端被绕过，服务端也应设置合理的请求限制
4. 性能优化：考虑实现分批加载筛选值，避免一次性获取全部选项

这种综合方案虽然不能完全阻止大请求的产生，但可以在用户体验和系统稳定性之间取得较好的平衡。对于关键业务场景，建议进一步结合虚拟滚动等技术优化整体性能。