QueryBuilder 是一个常用的过滤器的 UI 组件，本文从前后端和数据库查询的角度总结了一些使用经验，包括一些踩坑的心得。

引用 jQuery QueryBuilder 的定义

QueryBuilder 是一个用于创建查询和过滤器的 UI 组件。

QueryBuilder 组件一般多用于数据筛选，它以 AND OR NOT 的嵌套组合，让非专业的人也能构造复杂的数据查询语句。在问卷系统中，就有不少的地方需要使用到这个组件，本文就从最开始的技术选型到上线总结一下其中的一些关键技术点。

一般来说，一个专业的问卷系统都需要满足大量的数据筛选和清洗的工作，而 QueryBuilder 正是交互的第一步。在问卷的回收过程中，我们需要直接根据用户设置的条件进行答案的过滤，如下图：

在答题者提交问卷之后，便会直接在后台根据 QueryBuilder 生成的规则进行 运算，并且标记该份答案是 "有效/无效"，一般多用于根据答题者的答题认真程度进行发奖、招募等场景。因为这种筛选是在 api 侧实时运算的，需要直接根据答案的值解析 QueryBuilder 规则。

而数据清洗的功能则是在管理端异步任务中计算的，一般用于生成报表或者批量导出部分数据使用，它是针对所有回收的问卷进行清洗，所以需要将 QueryBuilder 规则转换成相应的查询语句，比如我们主要的分析工具是 es ，那么就要转换成 es 对应的 DSL 语句。

通过需求场景可以看出，虽然是同样的交互，但是不同的使用场景，底层需要做的事情是完全不一样的，所以我们技术调研时需要考虑的核心点就是扩展性，其一是 UI 组件是否能方便扩展新的规则(例如问卷中需要计算2个数组交集、字符串长度等等)； 其二是 QueryBuilder 规则存储的数据结构能否便捷的转换成对应的语法，如 mongo、es 等；最后还有非常重要的一点就是，是否有后端解析库的支持，比如支持在我们使用的主要语言 go 中直接计算出结果。

综上，最终我们确定使用的是 react-awesome-query-builder，它不仅能通过简单配置扩展 UI 规则，还内置了很多转换器，可以直接将 UI 组件的数据转换成 mysql/mongo/es 的查询语句。而且还可以将 QueryBuilder 规则转换成 jsonLogic，这是一种用 json 构造的语法树，最主要优势是语言无关、前后端通用，jsonLogic 虽然不支持复杂的语法：setters、循环、函数等，但对于 QueryBuilder 这种主要为 AND OR NOT 的语法完全够用了，看看它的语法：