|
@@ -1520,7 +1520,7 @@ typeBinding = `({ type: inputType }).type`
|
|
|
|
|
|
我们知道在 `AST` 中一个标签对应一个元素描述对象,所以从结果上看,`preTransformNode` 函数将一个 `input` 元素描述对象扩展为三个 `input` 标签的元素描述对象。但是由于扩展后的标签由 `v-if`、`v-else-if` 和 `v-else` 三个条件指令组成,我们在前面的分析中得知,对于使用了 `v-else-if` 和 `v-else` 指令的标签,其元素描述对象是会被添加到那个使用 `v-if` 指令的元素描述对象的 `el.ifConditions` 数组中的。所以虽然把一个 `input` 标签扩展成了三个,但实际上并不会影响 `AST` 的结构,并且从渲染结果上看,也是一致的。
|
|
|
|
|
|
-但为什么要将一个 `input` 标签扩展为三个呢?这里有一个重要因素,由于使用了绑定的 `type` 属性,所以该 `input` 标签的类型是不确定的,我们知道同样是 `input` 标签,但类型为 `checkbox` 的 `input` 标签与类型为 `radio` 的 `input` 标签的行为是不一样的。到代码生成的阶段大家会看到正是因为这里将 `input` 标签类型做了区分,才使得代码生成时能根据三种不同情况生成三种对应的代码,从而实现三种不同的功能。有的同学就会问了,这里不做区分可不可以?答案是可以的,但是假如这里不做区分,那么当你在代码生成时是不可能知道目标 `input` 元素的类型是什么的,为了保证实现所有类型 `input` 标签的功能可用,所以你必须保证生成的代码能完成所有类型标签的工作。换句话说你要么选择在编译阶段区分类型,要么就在运行时阶段区分类型。而 `Vue` 选择了在变异阶段就将类型区分开来,这么做的好处是运行时的代码在针对某种特定类型的 `input` 标签时所执行的代码是很单一职责的。当我们后面分析代码生成时你同样能够看到,在编译阶段区分类型使得代码编写更加容易。
|
|
|
+但为什么要将一个 `input` 标签扩展为三个呢?这里有一个重要因素,由于使用了绑定的 `type` 属性,所以该 `input` 标签的类型是不确定的,我们知道同样是 `input` 标签,但类型为 `checkbox` 的 `input` 标签与类型为 `radio` 的 `input` 标签的行为是不一样的。到代码生成的阶段大家会看到正是因为这里将 `input` 标签类型做了区分,才使得代码生成时能根据三种不同情况生成三种对应的代码,从而实现三种不同的功能。有的同学就会问了,这里不做区分可不可以?答案是可以,但是假如这里不做区分,那么当你在代码生成时是不可能知道目标 `input` 元素的类型是什么的,为了保证实现所有类型 `input` 标签的功能可用,所以你必须保证生成的代码能完成所有类型标签的工作。换句话说你要么选择在编译阶段区分类型,要么就在运行时阶段区分类型。而 `Vue` 选择了在编译阶段就将类型区分开来,这么做的好处是运行时的代码在针对某种特定类型的 `input` 标签时所执行的代码是很单一职责的。当我们后面分析代码生成时你同样能够看到,在编译阶段区分类型使得代码编写更加容易。如果从另外一个角度来讲,由于不同类型的 `input` 标签所绑定的事件未必相同,所以这也是在编译阶段区分 `input` 标签类型的一个重要因素。
|
|
|
|
|
|
|
|
|
## 文本节点的元素描述对象
|