Процесс рендеринга Vue

Добрый день! Меня зовут Александр, я работаю frontend-разработчиком в компании Nord Clan. В прошлой статье мы рассмотрели процесс компиляции Vue, а теперь надо как-то «пристроить» результат этой самой компиляции в процесс рендеринга. Давайте для начала вспомним основные пакеты:

В процессе рендеринга будут использоваться пакеты runtime-dom и runtime-core. При этом, runtime-dom будет обращаться к своему старшему брату runtime-core, который более мудрый и знает как, когда, и где использовать api из runtime-dom.

Начнем как обычно издалека, а именно сначала будем создавать наброски схем процесса рендеринга, а далее разбираться в них.

Стрелки в этих схемах будут указывать на вызовы других функций, а пунктирные линии на код, выполняемый внутри функций. Скажем так, это будет джуманджи в мира фронтенда, и джунгли кода будут все гуще и гуще…

Создание контекста рендеринга

Возьмем мощный микроскоп и рассмотрим то, как эти пакеты (runtime-dom и runtime-core) взаимодействуют между собой с последующим пошаговым и детальным описанием данной схемы:

Пользователь из app (берем любое Vue-приложение) вызывает функцию createApp(), и первым делом данная функция вызывает ensureRenderer:

export const createApp = (...args) => {   const app = ensureRenderer(); }

ensureRenderer либо создаст новый контекст рендеринга, либо использует уже созданный:

function ensureRenderer() {   return (     renderer ||     (renderer = createRenderer(rendererOptions))   ) }

Функция createrRenderer используется из пакета runtime-core и принимает в качестве аргумента объект с набором методов для работы с DOM (rendererOptions), которые будут использоваться в процессе монтирования виртуальных нод внутри runtime-core.

Заметим, что renderer изначально не установлен, так как тип renderer может отличаться в зависимости от сред выполнения кода:

let renderer: Renderer<Element | ShadowRoot> | HydrationRenderer

В нашем случае вызовется функция createRenderer, так как пока что никакого renderer создано не было:

(renderer = createRenderer(rendererOptions))

Эта функция в свою очередь вызовет baseCreateRenderer из пакета runtime-core, который отвечает за создание нового контекста рендеринга.

Функции patch, render, mount и т.д. будут использовать переданные из runtime-dom методы (hostInsert, hostRemove и т.д):

function baseCreateRenderer(   options: RendererOptions, ) {   const {     insert: hostInsert,     remove: hostRemove,     createElement: hostCreateElement,     createText: hostCreateText,     // ...   } = options    const patch = () => {     // ...   }    const render = () => {     // ...   }    const mount = () => {     // ...   }    // ... }

Конечно «портянка» кода в этой функции намного больше, но мне не охота пугать вас так же, как испугался я при ее виде. Однако же, именно эта функция позволяет обучится шаблонам рефакторинга произвести рендеринг.

Функция baseCreateRenderer возвратит ключевую функцию render, а также функцию createAppAPI:

function baseCreateRenderer(   options: RendererOptions, ) {   // ...     return {     render,     createApp: createAppAPI(render)   } }

createAppAPI возвращает функцию, которая создаст контекст приложения и предоставит методы, которые можно будет использовать в app, например, createApp().mount() или createApp().unmount():

export function createAppAPI<HostElement>(   render: RootRenderFunction, ): CreateAppFunction<HostElement> {   return function createApp(rootComponent) {     const app = {       mount() {         // ...       },       unmount() {         // ...       },     }      return app   } }

То есть разработчик как раз вызовет createApp, а далее с радостью использует метод mount, даже не подозревая о тех страшных вещах, которые произойдут в «черном-черном ящике»…

Возьмем старый пример из прошлой статьи. В качестве rootComponent передадим литерал объекта, содержащий свойства и методы следующего компонента:

Vue   .createApp({     data: () => ({       dynamic: 1     }),     template: `       <div>         <div>foo</div>         <div>bar</div>         <div>{{ dynamic }}</div>       </div>     `,   })   .mount('#app')

Вернемся к функции createApp. Как раз она и вызовется через Vue.createApp, а ранее baseCreaterenderer (помним, создается в ensureRenderer) уже любезно предоставил возможность создать контекст через вызов createApp:

export const createApp = (...args) => {   const app = ensureRenderer().createApp(); }

Итак, первый этап пройден, контекст создан, перейдем к следующему этапу — монтированию, созданию видеокурса по написанию своей реактивной библиотеки.

Компиляция шаблона, корневая vnode (или initialVNode) и patch-функция

app.createApp() уже создала контекст и имеет все необходимые методы для продолжения рендеринга, а именно метод mount, который будет перезаписан на уровне runtime-dom:

export const createApp = (...args) => {   const app = ensureRenderer().createApp();    const { mount } = app    app.mount = (containerOrSelector: Element | ShadowRoot | string) => {     // Здесь проверка containerOrSelector на валидность      const proxy = mount(containerOrSelector)      return proxy   } }

Метод mount вызовет как раз тот самый метод, который создал createApp, используя функции из baseCreateRenderer, передав в качестве аргумента селектор контейнера или сам контейнер, куда будет смонтировано Vue-приложение.

Перейдем в методу mount, который создавался в createAppAPI. Метод mount создаст корневую vnode на основе переданного template, data и т.д.:

export function createAppAPI(   render: RootRenderFunction, ): CreateAppFunction {   return function createApp(rootComponent, rootProps = null) {      // ...      const app = {       mount(rootContainer) {         // Создание корневой vnode (initialVNode)         const vnode = createVNode(rootComponent)          render(vnode, rootContainer)       },     }      return app   } }

Корневая vnode будет выглядеть примерно так:

const vnode = {   dynamicChildren: null,   dynamicProps: null,   patchFlag: 0,   shapeFlag: 4,   data: () => ({ dynamic: 1 }),   template: `           \n<div>\n               <div>foo</div>\n       <div>bar</div>\n               <div>{{ dynamic }}</div>\n           </div>\n ` }

shapeFlag со значением «4» означает STATEFUL_COMPONENT. patchFlag будет также нужен в дальнейшем в процессе перерасчета. Проверки для shapeFlag и patchFlag реализованы через побитовую маску для удобства, кхм, простите, проверок и производительности.

Вернемся к методу mount, подставим сюда эту самую корневую vnode:

mount(rootContainer) {   const vnode = {     dynamicChildren: null,     dynamicProps: null,     patchFlag: 0,     shapeFlag: 4,     data: () => ({ dynamic: 1 }),     template: `             \n<div>\n                 <div>foo</div>\n         <div>bar</div>\n                 <div>{{ dynamic }}</div>\n             </div>\n `   }    render(vnode, rootContainer) }

Функция render, как помним, была объявлена в baseCreateRenderer. Она вызывает процесс «патчинга» новой vnode в container (#app):

function baseCreateRenderer(   options: RendererOptions, ) {   const patch = () => {     // ...   }    const render = () => {     patch(container._vnode || null, vnode, container)   } }

Пожалуй функция patch является одной из самых ключевых функций, big boss в своем пакете.

Эта функция «проксирует» обработку той или иной vnode нужному обработчику (пардон за тавтологию), определяя тип vnode по shapeFlag, а также тип обновления по patchFlag.

То есть она отвечает за управление тем, как тот или узел VDOM будет обработан в процессе обхода VDOM-дерева:

const patch: PatchFn = (     n1,     n2,     container, ) => {     if (n1 === n2) {       // обновляемая виртуальная нода n1 идентична виртуальной ноде n2       // ничего не делать     }      if (n1 && !isSameVNodeType(n1, n2)) {       // обновляемая внода n1 не является одним и тем типом с n2       // размонтировать весь n1, чтобы смонтировать заново без перерасчета     }      const { type, ref, shapeFlag } = n2      switch (type) {       default:         if (shapeFlag & ShapeFlags.ELEMENT) {           // обновить n1 в n2 как елемент         } else if (shapeFlag & ShapeFlags.COMPONENT) {           // обновить n1 в n2 как компонент         }     } }

Проверок и обработчиков намного больше, но лучше сфокусироваться на самом основном.

Как помним, наша корневая vnode имеет shapeFlag равный STATEFUL_COMPONENT, а значит пора выходить на остановке processComponent:

const patch: PatchFn = (     n1,     n2,     container,   ) => {     // ...      const { type, ref, shapeFlag } = n2      switch (type) {       // ...        default:         // ...          if (shapeFlag & ShapeFlags.COMPONENT) {           processComponent(n1, n2, container)         }     } }

Логика работы функций-обработчиков нужного типа vnode схожа между собой, будь то processComponent, processText, processElement и т.д. Проверяется наличие n1 (обновленная vnode), и если она есть, то запускается процесс перерасчета, а если нет — процесс монтирования.

В нашем случае происходит первичное монтирование, поэтому вызовется функция mountComponent:

const processComponent = (     n1: VNode | null,     n2: VNode,     container: RendererElement, ) => {      // n1 равняется null, значит монтируется новый компонент      if (n1 == null) {       mountComponent(         n2,         container,       )     } else {       updateComponent(n1, n2)     } }

Что делает функция mountComponent? Она уже была упомянута в предыдущей статье про компиляцию в Vue, где эта функция помогает произвести компиляцию шаблона компонента в runtime, а потом отрендерить результат компиляции, освежим память:

const mountComponent: MountComponentFn = (   initialVNode,   container, ) => {   const instance: ComponentInternalInstance = (     initialVNode.component = createComponentInstance(initialVNode)       )      // компиляция и оптимизация произойдет здесь   setupComponent(instance)     // а здесь произойдет рендеринг   setupRenderEffect(     instance,     container,   ) }

createComponentInstance создаст контекст инициализации компонента. Полей намного больше, выделим основные:

const instance: ComponentInternalInstance = {     uid: uid++,     vnode, // корневая vnode     type, // { data: { ... }, template: `` }     appContext, // контекст приложения (mount, render, directives)     render: null, // render-функция, будет установлена после парсинга template     isMounted: false, // флаг проверки состояния mounted     isUnmounted: false, // флаг проверки состояния unmounted }

Далее вызовется функция setupComponent, которая примет новый instance:

const mountComponent: MountComponentFn = (   initialVNode,   container, ) => {   // ...    setupComponent(instance)     // ... }

Функция setupComponent после некоторых приготовлений вызовет finishSetupComponent, которая скомпилирует шаблон в render-функцию и установит ее в instance.render. Условий много, но скоро прибудет пояснительная бригада:

export function finishComponentSetup(   instance: ComponentInternalInstance, ) {   const Component = instance.type    if (!instance.render) {     if (compile && !Component.render) {       if (Component.template) {         Component.render = compile(template, finalCompilerOptions)       }     }      instance.render = Component.render   }  }

В первую очередь приезжает пояснительная бригада извлекается компонент:

export function finishComponentSetup(   instance: ComponentInternalInstance, ) {   const Component = instance.type // { template: "<div>...", data: () => { ... } }     // ... }

Далее идет проверка на наличие зарегистрированного компилятора compile, шаблона template и установленных render-функций. При успешных проверках запуститься функция compile, результатом которой будет новая рендер-функция:

export function finishComponentSetup(   instance: ComponentInternalInstance, ) {   // может уже есть render-функция?   if (!instance.render) {     // render-функции нет, а компилятор есть!?    if (compile && !Component.render) {        // отлично, нужен еще template…       if (Component.template) {         Component.render = compile(template, finalCompilerOptions)       }     }     // ... }

Новая render-функция установится на инстансе компонента:

export function finishComponentSetup(   instance: ComponentInternalInstance, ) {   // ...    instance.render = Component.render() }

finishComponentSetup завершился и установил render-функцию в instance. В дальнейшем вызов этой функции создаст VDOM.

Теперь пришло время перевести render-функцию  «на бумагу» с помощью функции setupRenderEffect (здесь могла бы быть ваша реклама барабанной дроби):

const mountComponent: MountComponentFn = (   initialVNode,   container, ) => {   // ...     setupRenderEffect(     instance,     container,   ) }

Передается в нее instance с корневой vnode, а также container (#app), куда надо будет отрендерить VDOM.

setupRenderEffect вызовет render-функцию, которая построит VDOM. В самом начале вызовется renderComponentRoot, который создает VDOM-дерево, которое может включать поддеревья, по которым будет произведен обход:

const setupRenderEffect: SetupRenderEffectFn = () => {   // ...   const subTree = (instance.subTree = renderComponentRoot(instance))    // ... }

renderComponentRoot вызовет заветную render-функцию, которая была создана на этапе компиляции, передав в нее Proxy-свойства компонента, для отслеживания их изменений и дальнейших перерасчетов. Например, в прокси-объекте будут $props, $data и т.д.

Конечно, как сказал бы Каневский, это совсем другая история, а поэтому вернемся к renderComponentRoot:

export function renderComponentRoot(   instance: ComponentInternalInstance ): VNode {   const {     proxy,   } = instance    let result: VNode    // Создать новое VDOM-дерево   result = render!.call(     proxy   )    return result }

render-функция вернет следующее VDOM-дерево:

{   type: "div",   shapeFlag: 17,   patchFlag: 0,   children: [     { shapeFlag: 9, patchFlag: -1, children: “foo”, type: 'div' },     { shapeFlag: 9, patchFlag: -1, children: “bar”, type: 'div' },     { shapeFlag: 9, patchFlag: 1, children: “1”, type: 'div' },   ] }

Схематично структуру vnode можно представить как дерево component- и host- элементов, где host-элементы являются конечными узлами дерева, которые могут быть сразу же отрендерены:

То есть корневая vnode div сразу же «запульнется» в DOM-дерево. Однако же остались еще и дочерние vnode-узлы.

Как идти по ним, да и вообще по VDOM? Конечно же рекурсивно (react >= 16 загрустил). Отставим в сторону react-флэшбэки и рассмотрим последний этап — рендеринг VDOM.

Рендеринг VDOM

Вызов patch с корневой vnode приведет к вызову processElement:

const setupRenderEffect: SetupRenderEffectFn = () => {   const subtree = {     type: "div",     shapeFlag: 17,     patchFlag: 0,     children: [       // ...     ]   }    patch(     null,     subtree   )    // ... }

Как помним, эта функция processElement, как и другие функции-обработчики, могла бы вызвать update-функцию для перерасчета vnode-узла, но пока что перерасчитывать нечего, а поэтому vnode смонтируется через вызов mountElement в processElement:

const mountElement = (     vnode: VNode,     container: RendererElement, ) => {     let el: RendererElement      el = vnode.el = hostCreateElement(       vnode.type,     )      if (shapeFlag & ShapeFlags.TEXT_CHILDREN) {       hostSetElementText(el, vnode.children as string)     } else if (shapeFlag & ShapeFlags.ARRAY_CHILDREN) {       mountChildren(         vnode.children as VNodeArrayChildren,         el,       )     }  }

Сначала создается новый экземпляр DOM-элемента, то есть HTMLDivElement:

const mountElement = (     vnode: VNode, // { type: "div", children: [...] }     container: RendererElement, ) => {     let el: RendererElement      el = vnode.el = hostCreateElement(       vnode.type,     )      // ... }

Далее  проверяем, имеет ли текущая vnode «детей» (ох, и тут я понял насколько странно применять это слово в данном контексте), или это конечный текстовый host-элемент, который можно просто отрендерить:

const mountElement = (     vnode: VNode,     container: RendererElement, ) => {     let el: RendererElement      // ...      if (shapeFlag & ShapeFlags.TEXT_CHILDREN) {       hostSetElementText(el, vnode.children as string)     } else if (shapeFlag & ShapeFlags.ARRAY_CHILDREN) {       mountChildren(         vnode.children as VNodeArrayChildren,         el,       )     }  }

В нашем случае текущая корневая vnode («div») является «многодетной» (казалось, страннее чем «дети» vnode-ы ничего быть не может), а значит вызовется mountChildren:

mountChildren(   vnode.children,   el )

mountChildren по сути просто выполняет проход по всех дочерним vnode-ам, вызывая patch для каждой из них:

const mountChildren: MountChildrenFn = (   children,   container, ) => {   for (let i = start; i < children.length; i++) {     const child = children[i]      patch(       null,       child,       container,     )   } }

Если у последующих дочерних элементов будут также children, то и для них функция patch вызовет mountChildren, но в кач-ве container уже будет указан дочерний элемент, который и содержит эти children.

Схематично это можно представить так:

Резюмируем, vnode root div — корневая vnode (выделена красным), который содержит children, вставляется в DOM, а далее вызывается mountChildren, который примет vnode root div в кач-ве контейнера для children.

В вызов patch будут переданы vnode из children и vnode root div и patch отрендерит каждую дочернюю vnode в vnode root div.

Так, раз за разом, из каждой vnode будет создан свой DOM-элемент и вставлен в корневой DOM-элемент (выделены жирным текстом для каждой итерации).

Стоит заметить, что здесь рассмотрена только самая базовая обработка vnode, когда vnode-ы из children являются хост-элементами.

Итак, теперь мы знаем (хоть и поверхностно, но все же) как работает этот «черный ящик» под названием рендеринг во Vue. В следующей статье мы рассмотрим процесс перерасчета VDOM во Vue.