module.exports = function inline(state) {
var tokens = state.tokens, tok, i, l;
// Parse inlines
for (i = 0, l = tokens.length; i < l; i++) {
tok = tokens[i];
if (tok.type === 'inline') {
state.md.inline.parse(tok.content, state.md, state.env, tok.children);
}
}
};
这一步是在 ParserBlock 之后的,因为 ParserBlock 处理之后会生成 type 为 inline 的token。这种 token 属于未完全解析的 token,需要 ParserInline 进一步处理,生成新的token。这些新生成的 token 会存放在 children 属性上。举个栗子来说:
// Double + single quotes replacement pairs, when typographer enabled,
// and smartquotes on. Could be either a String or an Array.
//
// For example, you can use '«»„“' for Russian, '„“‚‘' for German,
// and ['«\xA0', '\xA0»', '‹\xA0', '\xA0›'] for French (including nbsp).
Core.prototype.process = function (state) {
var i, l, rules;
rules = this.ruler.getRules('');
for (i = 0, l = rules.length; i < l; i++) {
rules[i](state);
}
};
在调用 process 的函数体内部,每次调用一个 rule,会将 state 传入。state 的 tokens 属性存储了所有的 token。因此我们发现,所有 rule 函数内部必须维持对 state.tokens 和 state 的引用不变,因此不能做类似于以下的赋值操作。
function rule (state) {
state = xxx // wrong
state.tokens = [token1, token2] // wrong
state.tokens.push(token1) // true
}
// 第一个语句错误的原因,是因为你改了 state 的指向,切断了与老 state 的联系。
// 第二个语句错误的原因,是改了 tokens 的指向。这样接下的 rule 函数拿到的 state.tokens 就丢失了之前 rule 生成的 tokens。
这种函数在函数式编程里面叫做拥有副作用的函数,因为输入的 state 在函数内部发生了变化,导致外层 state 也被改变。这也是 javascript 里面基础类型与引用类型的区别。但是 MarkdownIt 的整体架构设计就是基于这种引用类型的机制,否则必须在 rule 里面返回每次新生成的 tokens,并且统一管理。
ParserCore
编译的核心管理者,掌握着不同类型的 token 生成的流程。它内部管理了 ParserBlock、ParserInline、linkify、replacements 等 rule 函数。也就是说,用户传入一个字符串,经历了这些 rule 函数处理之后,得到了一个由许多 token 组成的 tokens 数组,最后再交由 renderer 处理之后,吐出 HTML 字符串。
先看下 MarkdownIt 的执行逻辑。
我们重点关注一下 ParserCore 这个类。它位于
lib/parser_core.js
。parserCore 实例上仅有一个 ruler 属性,这个是用来管理内部所有的 rule 函数,并且原型上。只有一个 process 方法。
当调用 process 的时候,首先会拿到职责链名为空字符串(
''
)的 rule 组成的数组,将 state 作为入参传入至每一个 rule 函数,得到 tokens 之后挂载到 state 上去。类似的伪代码如下:因此我们的关注点就在于这些属于 parserCore 的 rule 到底是做了什么工作?state 又是什么呢?先来看下属于 parserCore 的 state。它位于
lib/rules_core/state_core.js
src
用来放用户输入的字符串,tokens 存放编译出来的 token。inlineMode
表示 parse 的时候是否编译成 type 为 inline 的 token。md
就是当前 MarkdownIt 的实例。而属于 ParserCore 的 rules 的职能是什么?我们先粗略了解一下。它们都在
lib/rules_core
文件夹。作用很简单,就是兼容一下 linux 和 windows 换行符的问题。
内部逻辑很清晰,先判断是否开启 inline 模式的 parse。否则通过 md 调用 ParserBlock 的 parse 方法。这一步是将换行分隔符(
\n
) 作为 src 的划分界限,生成很多 block 为 true 的 token。我们在接下来的一篇关于 ParserBlock 分析的文章里面详细阐述。这一步是在 ParserBlock 之后的,因为 ParserBlock 处理之后会生成 type 为 inline 的token。这种 token 属于未完全解析的 token,需要 ParserInline 进一步处理,生成新的token。这些新生成的 token 会存放在 children 属性上。举个栗子来说:
ParserInline 的揭秘,会在另外一片文章详细分析。
这个 rule 的作用就是将 URL-like 的字符串转化成超链接。rule 是否执行,是取决于你实例化 md 传入的
options.linkify
。内部检测 URL-like 的字符串用的库是linkify-it
。里面对很多种 url 格式做了检验,有兴趣的可以详细研究一下。初始化 md 的时候传入的
options.typographer
为 true 的时候,开启该 rule。这个 rule 的作用,就是替换一些印刷字体,比如类似于下面的:初始化 md 的时候传入的
options.typographer
为 true 的时候,开启该 rule。rule 的作用就是为了处理一些不同国家语言的引号问题。官网给出的解释如下小结
如此一来,我们从宏观的角度全面分析了 MarkdownIt 的 parse、tokenize、render 的全流程。代码的整体设计思路非常的清晰,内部的源码注释也是非常的丰富到位,用一张图来简单阐述下流程。
但是如果有细心的同学,会发现如下的一段代码,很有意思。
在调用 process 的函数体内部,每次调用一个 rule,会将 state 传入。state 的 tokens 属性存储了所有的 token。因此我们发现,所有 rule 函数内部必须维持对 state.tokens 和 state 的引用不变,因此不能做类似于以下的赋值操作。
这种函数在函数式编程里面叫做拥有副作用的函数,因为输入的 state 在函数内部发生了变化,导致外层 state 也被改变。这也是 javascript 里面基础类型与引用类型的区别。但是 MarkdownIt 的整体架构设计就是基于这种引用类型的机制,否则必须在 rule 里面返回每次新生成的 tokens,并且统一管理。
总结
分析完了 ParserCore,让我们从整体上对 MarkdownIt 的原理有了一定的了解。下两篇文章,我们分别详细分析 ParserBlock 和 ParserInline,这两部分篇幅会比较长,因为这属于核心的 parse 逻辑。