让我们把工作原理讲的更简单一些,先不讲从右向左也不讲接口,先来分析下如果要执行一段选择器表达式,或者说设计一个简版选择器引擎,直觉上需要做些什么工作:
以div > p为例来模拟这个过程,找div元素下的p元素:

1. 首先要能正确的将独立的块表达式从选择器表达式中分割出来,这是必须的,否则没法找div元素或p元素

2. 然后要能正确的执行块表达式,无论是left>right或right>left,首先要能找到div元素或p元素
块表达式可能不仅仅是简单的id/name/tag/class,也可能是它们之间的组合,甚至是与伪类的组合
比如div.red,查找具有指定.red的div,怎么实现这个过程呢?
可以先找div数组,再在div数组上过滤.red;或者也可以先找*.red数组,再在*.red数组上找div
不管哪种方式,上边的过程都可以分解为:一个简单查找器和一个对查找结果过滤的过滤器

3. 单个块表达式搞定了,最后来处理块表达式之间的关系,DOM元素之间关系不外乎四种:父子,祖先,兄长,兄弟
就是找父亲或找儿子,找祖宗或找后代,找哥哥姐姐或找弟弟妹妹,关系不复杂,都有原生API支持

只要把2~3重复执行就可以完成(我感觉我的神经好粗大),选择器引擎的大致思路就是如此。
把上述过程与Sizzle对应着理解:
1. 分割器 chunker正则
2. 块查找 Sizzle.find( expr, context, isXML )
块内过滤 Sizzle.filter( expr, set, inplace, not )
3. 块间关系过滤 Expr.relative
这三个接口正是Sizzle实现的核心API。

当然上边的分析有事后诸葛亮的嫌疑,毕竟我已经看过Sizzle源码了, 但是当我试着用上边的过程来理解Sizzle的工作原理时,顿时豁然开朗,希望有所启发。

发表评论

电子邮件地址不会被公开。 必填项已用*标注