This is the 7th day of my participation in the August Text Challenge.More challenges in August

Bilibili: BV1Et41197L4

  • faster
  • smaller
  • Easier to maintain
  • Better multi-terminal rendering support
  • New features

faster

Template compilation and Virtual DOM runtime optimization

  • New Virtual DOM implementation
  • Perfect reconstruction
  • Initial render/update speed increased by 100% (Max)
  • More compile-time optimizations
  • To reduce runtime overhead

When we compile the template as a rendering function of the Virtual DOM, the way Vue2.0 works is that both components and browser native HTML elements are unified as a string and passed to the H function, which creates a Virtual Node. When determining whether an element is a component or a native element, Vue2.0 is at runtime and inevitably has runtime overhead, whereas Vue3.0 is made at compile time. This is called the Component Fast Path. In addition, the so-called Monomorphic calls should be generated as much as possible. When generating these virtual nodes, our function calls should have the same shape as possible, that is, the same number of parameters, which will make the generated code easier to be optimized by the JS engine. Finally, directly in the template statically analyze an element contains the type of child elements, such as in the generated code to run time left some Numbers similar to hint, hint this div is now only one child, in the algorithm the corresponding branch can directly jump into the object of this branch of only one child, You can skip a lot of other unnecessary judgments.

Every change before optimization Slots is generated updates the parent component, which updates the new slot content to the child component, which then updates. In the new update mechanism, all slots are unified as a function like scope slot, which can be a lazy function. When you pass a function to a child component, the child component decides when to call the function. When a child calls a function, it simply needs to re-render the child when the component changes, and the parent and child dependencies are separated. This results in a very precise collection of component-level dependencies, which further avoids unnecessary rendering. At any time, only components that actually rely on some data are likely to be rerendered, so there is no need to manually optimize components for excessive redrawing.

Static content extraction is already done with Vue2.0. When some templates are detected to be unchanged, they can be extracted. In subsequent updates, this part of the template can not only be reused directly from the previous Virtual DOM, but also skip the whole tree process. What Vue2 doesn’t do is that when an element has any depth inside it and any dynamic content, the whole element can’t be static, which is a shame; But we can still do a certain degree of optimization, that is if the element itself all the above properties are static, we can give it out, the attribute object extracted, after every time we compare the elements, if the elements of the data are the same, then the element itself does not need to compare, You can just skip it and compare it to its children.

Inline event functions to extract the inline function every time to render will generate a new function, which can lead to child components to render every time, and by a certain degree of optimization, is after the inline function to generate a cache, after each time to reuse the same function, can avoid the useless child components update a result.

Proxy – based new data monitoring system

  • Full language features support + better performance
  • Adding or deleting object attributes
  • Array index/length changed
  • WeakMap, Set, WeakMap, WeakSet
  • Classes

In fact, this proxy-based listening is called Lazy by default, which means we only listen for data when it is being used.

Use Proxy to reduce component instance initialization overhead. Also, we know that each Vue component will delegate all its contained data, Coputed, and props. These proxies are implemented via Object.defineProperty. In fact, a lot of Object.defineProperty is a relatively expensive operation. In Vue3, the this exposed to the user is actually a Proxy for the actual component instance. When you fetch properties from this Proxy, we make internal judgments. This eliminates the use of Object.defineProperty altogether.

smaller

Tree-shaking code structure

Tree-shaking is throwing away code we don’t use at the last compile. Before, the entire Vue code was just a Vue object, everything was on the Vue object, so actually all the stuff you didn’t use couldn’t be thrown away because it was already added to the global Vue object. Vue3 was made imported on demand, with ES Module imports imported on demand. For example, this can be done on demand:

  • Built-in components (keep-alive, transition…)
  • Instruction runtime Helper (V-model, V-for…)
  • Various utility functions (asyncComponent, mixins, memoize…)

And many of these instructions generate code at compile time. When you use the V-Model, the generated code will import the v-Model related code. This ensures that when you only have the most basic functionality, you only use the core code that any Vue will use. This part of the code is about 10KB after Tree-Shakin. (New minimum core runtime: ~ 10KB gzipped)

Easier to maintain

This is true for the team developing Vue. For those who want to read Vue source code and want to participate in Vue development, it is also meaningful.

Flow-> TypeScript (which does not affect user code) will switch to TypeScript altogether, and users can opt out.

Internal modules are decoupled

Compiler reconfiguration

  • Plug-in design
  • Source Maps parser with Location information
  • Pave the way for a better IDE tool chain

Better multi-terminal rendering support

Vue3 will introduce a true Custom Render API. All the developer has to do is import the createRenderer from the Run-time core instead of forkVue source code reprocessing. Run-time core is a platform-independent Vue runtime, it contains all the components of the Vue, all the algorithms of the Virtual DOM, and so on, but it doesn’t contain any code that’s directly related to the DOM, and the DOM code is when you create the runtime, Through the nodeOps, these are node operations, and patchData, which is how to deal with the various properties on an element when it is updated. After providing these functions, you get a render function that lets you render Vue components and the Virtual DOM directly onto your native objects.

import { createRenderer } from '@vue/runtime-core'

const { render } = createRenderer({
    nodeOps,
    patchData
})
Copy the code

New features

Reactive data listening API

Use the Observable function to explicitly create a responsive object. This is the same as when you pass an object into the Vue component’s data, and it becomes responsive after being converted.

import { observable, effect } from 'vue'

const state = observable({
    count: 0
})

effect(() = > {
    console.log(`count is: ${state.count}`)
})

state.count++ // count is 1
Copy the code

The main reason for exposing this API is that you can use Observables to share state across components.

Easily troubleshoot component update triggers

Vue3 provides the renderTriggered API. Every time a component starts an update, you can use the debugger to see which line triggered the update in the browser.

const Comp = {
    render(props){
        return h('div', props.count)
    },
    renderTriggered(event){
        debugger}}Copy the code

Better TypeSCript support, including native Class apis and TSX

Direct built-in native support

Better warning messages

  • The component stack contains functional components
  • You can view the props of the component directly in the warning message
  • Component stack information is provided in more warnings

Experimental

Hooks API (see React)

As a logical reuse mechanism, mixins are likely to be replaced

Time Slicing Support (see React)

Time Slicing is also a concept proposed by React a while ago, called Concurrent React. In other words, the framework can cut the Javascript calculations into blocks and do them frame by frame when conducting Javascript calculations. The most common performance problem with frameworks is that a lot of Javascript in the main thread of the browser blocks the main thread. We can fix this problem by yielding to the browser every 16 milliseconds, or every frame, so that the user event comes back in and triggers the update. It is possible for a user event to cause a new update, making the previous update invalid, that is, not to be done.

About IE

There will be a dedicated version that automatically demotes to the old getter/setter mechanism in IE11; And to IE does not support users to give a warning.