JSX渲染到真实DOM

CJCJ
492 阅读8分钟

一 JSX语法

React官网给出的定义：JSX 是 JavaScript 的一种语法扩展，它和模板语言很接近，但是它充分具备 JavaScript 的能力。这就意味着jsx并不是js的某个版本，，他们两个并不是一路人，浏览器是不会主动认识jsx语法的，需要通过其他工具去编译解析jsx语法，一般用到的工具就是babel，它会将JSX 编译成React.createElement()，React.createElement() 将返回一个叫作“React Element”的 JS 对象。

二 Babel

官网定义：Babel 是一个工具链，主要用于将 ECMAScript 2015+ 版本的代码转换为向后兼容的 JavaScript 语法，以便能够运行在当前和旧版本的浏览器或其他环境中。

比如说，ES2015+ 版本推出了一种名为“模板字符串”的新语法，这种语法在一些低版本的浏览器里并不兼容。Babel 就可以帮我们把这段代码转换为大部分低版本浏览器也能够识别的 ES5 代码。类似的，Babel 也具备将 JSX 语法转换为JavaScript 代码的能力。

image.png 可以看到，所有的 JSX 标签都被转化成了 React.createElement 调用，这也就意味着，我们写的 JSX 其实写的就是 React.createElement，虽然它看起来有点像 HTML，但也只是“看起来像”而已。JSX 的本质是React.createElement这个 JavaScript 调用的语法糖，这也就完美地呼应上了 React 官方给出的“JSX 充分具备 JavaScript 的能力”这句话。

三 JSX渲染到真实DOM

认识 React.createElement() 源码

/**
 101. React的创建元素方法
 */
export function createElement(type, config, children) {
    // propName 变量用于储存后面需要用到的元素属性
    let propName;
    
    // props 变量用于储存元素属性的键值对集合
    const props = {};
    
    // key、ref、self、source 均为 React 元素的属性，此处不必深究
    let key = null;
    let ref = null;
    let self = null;
    let source = null;
    
    // config 对象中存储的是元素的属性
    if (config != null) {
        // 进来之后做的第一件事，是依次对 ref、key、self 和 source 属性赋值
        if (hasValidRef(config)) {
            ref = config.ref;
        }

        // 此处将 key 值字符串化
        if (hasValidKey(config)) {
            key = `${config.key}`;
        }

        self = config.__self === undefined ? null : config.__self;
        source = config.__source === undefined ? null : config.__source;

        // 接着就是要把 config 里面的属性都一个一个挪到 props 这个之前声明好的对象里面
        for (propName in config) {
            if (
                // 筛选出可以提进 props 对象里的属性
                hasOwnProperty.call(config, propName) &&
                !RESERVED_PROPS.hasOwnProperty(propName)
            ) {
                props[propName] = config[propName];
            }
        }
    }

    // childrenLength 指的是当前元素的子元素的个数，减去的 2 是 type 和 config 两个参数占用的长度
    const childrenLength = arguments.length - 2;
    
    // 如果抛去type和config，就只剩下一个参数，一般意味着文本节点出现了
    if (childrenLength === 1) {
        // 直接把这个参数的值赋给props.children
        props.children = children;
        // 处理嵌套多个子元素的情况
    } else if (childrenLength > 1) {
        // 声明一个子元素数组
        const childArray = Array(childrenLength);
        // 把子元素推进数组里
        for (let i = 0; i < childrenLength; i++) {
            childArray[i] = arguments[i + 2];
        }
        // 最后把这个数组赋值给props.children
        props.children = childArray;
    }

    // 处理 defaultProps
    if (type && type.defaultProps) {
        const { defaultProps } = type;
        for (propName in defaultProps) {
            if (props[propName] === undefined) {
                props[propName] = defaultProps[propName];
            }
        }
    }

    // 最后返回一个调用ReactElement执行方法，并传入刚才处理过的参数
    return ReactElement(
        type,
        key,
        ref,
        self,
        source,
        ReactCurrentOwner.current,
        props,
    );
}

3.1 函数入参

export function createElement(type, config, children)

createElement 有 3 个入参，这 3 个入参囊括了 React 创建一个元素所需要知道的全部信息。

  • type：用于标识节点的类型。它可以是类似“h1”“div”这样的标准 HTML 标签字符串，也可以是 React 组件类型或 React fragment 类型。
  • config：以对象形式传入，组件所有的属性都会以键值对的形式存储在 config 对象中。
  • children：以对象形式传入，它记录的是组件标签之间嵌套的内容，也就是所谓的“子节点”“子元素”。

3.2 createElement函数体拆解

下面的流程图概括了createElement在代码逻辑层面的任务流转。

image.png

createElement的每一步都是在格式化数据，createElement就像是开发者和 ReactElement（返回js对象）调用之间的一个“转换器”、一个数据处理层。它可以从开发者处接受相对简单的参数，然后将这些参数按照 ReactElement 的预期做一层格式化，最终通过调用 ReactElement 来实现js元素的创建。简化流程如下图

image.png

3.3 ReactElement对象(初识虚拟dom)

createElement执行到最后会 return 一个针对 ReactElement 的调用。下面是关于 ReactElement源码的解析

const ReactElement = function (type, key, ref, self, source, owner, props) {
    const element = {
        // REACT_ELEMENT_TYPE是一个常量，用来标识该对象是一个ReactElement
        $$typeof: REACT_ELEMENT_TYPE,
        // 内置属性赋值
        type,
        key,
        ref,
        props,
        // 记录创造该元素的组件
        _owner: owner,
    };

    //
    if (__DEV__) {
        // 这里是一些针对 __DEV__ 环境下的处理，对于大家理解主要逻辑意义不大，此处我直接省略掉，以免混淆视听
    }

    return element;
};

ReactElement 的代码出乎意料的简短，从逻辑上我们可以看出，ReactElement 其实只做了一件事情，那就是“创建”，说得更精确一点，是“组装”：ReactElement 把传入的参数按照一定的规范，“组装”进了 element 对象里，并把它返回给了 React.createElement，最终 React.createElement 又把它交回到了开发者手中。整个过程如下图所示：

image.png

这个 ReactElement 对象实例，本质上是以 JavaScript 对象形式存在的对 DOM 的描述，也就是老生常谈的“虚拟 DOM”（准确地说，是虚拟 DOM 中的一个节点。

3.4 为什么会选择虚拟 dom

DOM 操作是很慢的，而 JS 却可以很快，直接操作 DOM 可能会导致频繁的回流与重绘，JS 不存在这些问题。因此虚拟 DOM 比原生 DOM 更快。

虚拟 DOM（Virtual DOM）本质上是JS 和 DOM 之间的一个映射缓存，它在形态上表现为一个能够描述 DOM 结构及其属性信息的 JS 对象。

虚拟 DOM 在 React 组件的挂载阶段和更新阶段都会作为“关键人物”出镜，其参与的工作流程如下：

  • 挂载阶段，React 将结合 JSX 的描述，构建出虚拟 DOM 树，然后通过 ReactDOM.render 实现虚拟 DOM 到真实 DOM 的映射（触发渲染流水线）；
  • 更新阶段，页面的变化在作用于真实 DOM 之前，会先作用于虚拟 DOM，虚拟 DOM 将在 JS 层借助diff算法先对比出具体有哪些真实 DOM 需要被改变，然后再将这些改变作用于真实 DOM。

image.png

栈调和(包括diff算法)：

  • 栈调和就是将虚拟DOM映射到真实DOM的过程
  • 栈调和 !== diff, diff 只是调和过程的一个步骤
  • diff算法就是找两个树的不同，差量更新，并将时间复杂度从n的3次方降为n，只要实现可以分为以下几点：1.分层处理，同层级才会进行比较，跨层级的直接跳过diff，销毁旧的节点，重建新的节点 2.类型相同的节点才有diff的必要性，类型不同的节点直接销毁并被替换成新的节点 3.key属性：key作为唯一标识，可以减少同一层级的节点的多余比较

除了差量更新patch以外，“批量更新”也是虚拟 DOM 在性能方面所做的一个重要努力： “批量更新”是由 batch 函数来处理的。在差量更新速度非常快的情况下（比如极短的时间里多次操作同一个 DOM），用户实际上只能看到最后一次更新的效果。这种场景下，前面几次的更新动作虽然意义不大，但都会触发重渲染流程，带来大量不必要的高耗能操作。

这时就需要请 batch 来帮忙了，batch 的作用是缓冲每次生成的补丁集，它会把收集到的多个补丁集暂存到队列中，再将最终的结果交给渲染函数，最终实现集中化的 DOM 批量更新。

3.4.1 模版引擎(拓展)

下面是一堆数据

const staff = [
  {
    name: 'cj',
    career: '前端'
  },
  {
    name: 'kk',
    career: '编辑'
  },
  {
    name: 'hh',
    career: '运营' 
  }
]

在前端用表格展示这一堆数据，我就可以遵循模板的语法，把它塞进模板（template）里去。下面就是一个典型的模板语法使用示例：

<table>
  {% staff.forEach(function(person){ %}
  <tr>
    <td>{% student.name %}</td>
    <td>{% student.age %}</td>
  </tr>
  {% }); %}
</table>

模版语法其实就是把 JS 和 HTML 结合在一起的一种规则，而模板引擎做的事情也非常容易理解。

把 staff 这个数据源读进去，塞到预置好的 HTML 模板里，然后把两者融合在一起，吐出一段目标字符串给你。这段字符串的内容，其实就是一份标准的、可用于渲染的 HTML 代码，它将对应一个 DOM 元素。最后，将这个 DOM 元素挂载到页面中去，整个模板的渲染流程也就走完了。

使用模板引擎方案来渲染数据是非常爽的：每次数据发生变化时，我们都不用关心到底是哪里的数据变了，也不用手动去点对点完成 DOM 的修改。只需要关注的仅仅是数据和数据变化本身，DOM 层面的改变模板引擎会帮我们做掉。

如此看来，模板引擎像极了一个只需要接收命令，就能够把活干得漂漂亮亮的“扫地机器人”！可惜的是，模板引擎出现的契机虽然是为了使用户界面与业务数据相分离，但实际的应用场景基本局限在“实现高效的字符串拼接”这一个点上，因此不能指望它去做太复杂的事情。尤其令人无法接受的是，它在性能上的表现并不尽如人意：由于不够“智能”，它更新 DOM 的方式是将已经渲染出 DOM 整体注销后再整体重渲染，并且不存在更新缓冲这一说。在 DOM 操作频繁的场景下，模板引擎可能会直接导致页面卡死。

核心思想：只关心数据而不必关心 DOM 细节。

3.4.2 模版引擎和虚拟dom性能比较

image.png

模板渲染是全量更新，而虚拟 DOM 是差量更新。好像差量更新一定比全量更新高效，但需要考虑这样一种情况：数据内容变化非常大（或者说整个发生了改变），促使差量更新计算出来的结果和全量更新极为接近（或者说完全一样）。在这种情况下，DOM 更新的工作量基本一致，而虚拟 DOM 却伴随着开销更大的 JS 计算，此时会出现的一种现象就是模板渲染和虚拟 DOM 在整体性能上难分伯仲：若两者最终计算出的 DOM 更新内容完全一致，那么虚拟 DOM 大概率不敌模板渲染；但只要两者在最终 DOM 操作量上拉开那么一点点的差距，虚拟 DOM 就将具备战胜模板渲染的底气。因为虚拟 DOM 的劣势主要在于 JS 计算的耗时，而 DOM 操作的能耗和 JS 计算的能耗根本不在一个量级，极少量的 DOM 操作耗费的性能足以支撑大量的 JS 计算。

3.5 ReactDOM.render

帮助虚拟dom渲染到真实dom，下面是源码

ReactDOM.render(

    // 需要渲染的元素（ReactElement）

    element, 

    // 元素挂载的目标容器（一个真实DOM）

    container,

    // 回调函数，可选参数，可以用来处理渲染结束后的逻辑

    [callback]

)

ReactDOM.render 方法可以接收 3 个参数，其中第二个参数就是一个真实的 DOM 节点，这个真实的 DOM 节点充当“容器”的角色，React 元素最终会被渲染到这个“容器”里面去。

特此：感谢修言老师！

avatar
文章
阅读
粉丝