Changes

Props

Component no longer need to delcare props in order to receive props. Everything passed from parent vnode's data (with the exception of internal properties, i,e. key, ref, slots and nativeOn*) will be available in this.$props and also as the first argument of the render function. This eliminates the need for this.$attrs and this.$listeners.

When no props are declared on a component, props will not be proxied on the component instance and can only be accessed via this.$props or the props argument in render functions.

You still can delcare props in order to specify default values and perform runtime type checking, and it works just like before. Declared props will also be proxied on the component instance. However, the behavior of undeclared props falling through as attrs will be removed; it's as if inheritAttr now defaults to false. The component will be responsible for merging the props as attrs onto the desired element.

VNodes

Flat Data Format

// before
{
  attrs: { id: 'foo' },
  domProps: { innerHTML: '' },
  on: { click: foo },
  key: 'foo',
  ref: 'bar'
}

// after (consistent with JSX usage)
{
  id: 'foo',
  domPropsInnerHTML: '',
  onClick: foo,
  key: 'foo',
  ref: ref => {
    this.$refs.bar = ref
  }
}

• Less memory allocation & faster diffs
• Makes it consistent with JSX
• Easier spread operations

VNodes are now context-free

h can now be globally imported and is no longer bound to component instacnes. VNodes created are also no longer bound to compomnent instances (this means you can no longer access vnode.context to get the component instance that created it)

Component in Render Functions

No longer resolves component by string names; Any h call with a string is considered an element. Components must be resolved before being passed to h.

import { resolveComponent } from 'vue'

render (h) {
  // only necessary when you are trying to access a registered component instead
  // of an imported one
  const Comp = resolveComponent(this, 'foo')
  return h(Comp)
}

In templates, components should be uppercase to differentiate from normal elements.

NOTE: how to tell in browser templates? In compiler, use the following intuitions:

1. If uppercase -> Component
2. If known HTML elements -> element
3. Treat as unknown component - at runtime, try resolving as a component first, if not found, render as element. (resolveComponent returns name string if component is not found)

Slots

Unifying Normnal Slots and Scoped Slots

Scoped slots and normal slots are now unified. There's no more difference between the two. Inside a component, all slots on this.$slots will be functions and all them can be passed arguments.

Usage Syntax Change

// before
h(Comp, [
  h('div', { slot: 'foo' }, 'foo')
  h('div', { slot: 'bar' }, 'bar')
])

// after
h(Comp, () => h('div', 'default slot'))

// or
import { childFlags } from 'vue/flags'

h(Comp, null, {
  slots: {
    foo: () => h('div', 'foo'),
    bar: () => h('div', 'bar')
  }
}, childFlags.COMPILED_SLOTS)

// also works
h(Comp, null, {
  foo: () => h('div', 'foo'),
  bar: () => h('div', 'bar')
})

Functional Component

Functional components can now really be just functions.

// before
const Func = {
  functional: true,
  render (h, ctx) {
    return h('div')
  }
}

// Now can also be:
const Func = (h, props, slots, ctx) => h('div')
Func.pure = true

Async Component

Async components now must be explicitly created.

import { createAsyncComponent } from 'vue'

const AsyncFoo = createAsyncComponent(() => import('./Foo.vue'))

Directives

• Now are internally on-vnode hooks with the exact same lifecycle as components.

• Custom directives are now applied via a helper:

import { applyDirective, resolveDirective } from 'vue'

render (h) {
  // equivalent for v-my-dir
  const myDir = resolveDirective(this, 'my-dir')
  return applyDirective(h('div', 'hello'), [[myDir, this.someValue]])
}

Styles

No longer performs auto-prefixing.

Attributes

• No longer auto coerces boolean or enumerated attribute values.
• No longer removes attribute if value is boolean false. Instead, it's set as attr="false" instead. To remove the attribute, use null.

Filters

Filters are gone for good (or can it?)

Refs

• Function refs are now supported.
• String refs are no longer supported in render functions (now only supported in templates and compiled into function refs)
• String refs no longer automatically generates an array when used with v-for. Instead, use something like :ref="'foo' + key" or function refs.

So I was wondering about this ... and it's more a question of curiosity than me spotting a problem but ...

We will provide a compatibility version of the observer package that will implement the 2.0 Reactivity system (getters&setters) that people can use for browsers that don't support Proxy (read: IE).

However, also heavily rely on Proxy in the runtime-core (componentProxy.ts)

With this implementation, we don't have to actually add properties to the component instance for each prop and $data property, computed property and so on. We can just catch get and set access in the component's proxy.

But for a compatibility build, we would have to replace this behaviour with code that dpoes add getters & setters to the component instance, right?

In the current implementtion I don't see a clean / easy way to exchange this like we plan to have it for the observer package, do we (@evan) have a plan for how to approach it?

Version

3.0.0-alpha.1

Reproduction link

2.x - https://jsfiddle.net/natuqebm/
3.0.0-alpha.1 - https://jsfiddle.net/u7pt6gjo/

Steps to reproduce

Just open these above reproductions links

What is expected?

There is an inconsistency between Vue 2.x and the latest alpha. 3.x should not render a boolean values in the render function.

What is actually happening?

Renders 0falsetrueNaN instead of 0NaN

Version

3.0.0-alpha.1

Reproduction link

https://docs.jsfiddle.net/

Steps to reproduce

https://guides.github.com/features/mastering-markdown/

What is expected?

no

What is actually happening?

no

no

What problem does this feature solve?

I'm using @vue/reactivity as a low level data service, and there are some heavy computing case in my app. I want to manually check if a reactive object is being used in computed values, so I can do lazy computing when it is not.

What does the proposed API look like?

export function isTracked(target) {
return targetMap.has(target)
}

export function onTrack(target, callback) {
// when a target is being tracked, call callback function.
}

For Reference: https://github.com/vuejs/vue-next/blob/master/packages/runtime-core/src/optional/context.ts

So I took a look at the new implementation and I have some reservations about it.

vuejs/vuex#1417

The current implementation in vue-next

As of this writing, vue-next will implement Context (or as we call it: provide/Inject) as a pair of components:

<!-- Parent.vue -->
<Provide id="someName" :value="{ message: 'Hello Vue!' }">
  <Child />
</Provide>

<!-- Child-vue -->
<Inject id="someName">
  <!-- side note: I couldn't determine if we will still require `slot-scope` 
       to be set on the root slot element, or if we provide a way to define it 
       on the component providing the slot itself.
  -->
  <div slot-scope="{ message }">
    {{ message }}
  <div>
</inject>

Reservations/Issues with this implementation

My reservations mostly originate from the discussions in the vuex repository about the proposed removal of mapXXX helpers in the next major of vuex here:

https://github.com/vuejs/vue-next/blob/master/packages/runtime-core/src/optional/context.ts

The important point is this one:

vuex state/getters/actions are only conveniently available in templates and render functions. That means the convenience is unavailable for computed properties that rely on Vuex state and methods that dispatch Vuex actions, which is a big limitation.

I think <Inject> suffers from similar problems. A component that uses <Inject> can only access the provided data within the template, so computed properties and watch callbacks have no way of accessing that data.

It works for React because React has neither of those things, it only has state, props and methods. So you can easily pass the injected data as an argument to a component method. But a similar thing is not possible for computed or watch functions since those don't take arguments.

Hooks

Maybe the new hot kid in town, Hooks, can solve this problem?

import { useInject } from 'vue'

export default {
  hooks() {
    const [injectedData] = useInject('someName')
    return {  
      injectedData 
    }
  }
}

That doesn't mean we have to drop <Inject>, I think it's still convenient for situations where accessing the injected Data in the template / render function is enough. But we need a way to allow users to actually inject this data as a property on the component instance.

The issue with a hook would be that we make this dependent on an experimental feature.

Backwards compatibility

We sold provide/inject as a feature primarily targeted at library authors. Dropping the old syntax from Vue 2 would be another breaking change that may be a roadblock for people updating their projects, as libs using this feature would have to find a way to make it work with the new component-based approach.

So this is another feature I think we should provide compat version for...

Current proposal:

• Remove inhertiAttrs option
• Remove nativeOn
• Remove automatic attribute fallthrough in all cases
• The only, consistent way to enable attribute fallthrough is to explicitly spread $attrs on desired target element
  • In template: <div v-bind="$attrs">
  • In render functions: return cloneVNode(h('div'), this.$attrs)
  • note if component has no declared props, $attrs will be empty and everything will be in $props, and it should just spread / pass on $props instead. $attrs will just point to $props which includes everything passed to the component.

Rationale

• The fallthrough behavior has already been inconsistent between stateful components and functional components in 2.x. With the introduction of fragments, the fallthrough behavior becomes even more unreliable for component consumers. The implicit behavior is convenient in cases where it works, but can be confusing in cases where it doesn't. By making this an explicit decision of component authors, whether a component accepts additional attributes becomes part of the component's API contract, overall resulting in more consistency.

• The combination of inheritAttrs, nativeOn, $attrs and $listeners makes props passing in higher-order components unnecessarily complex. The new behavior makes it much more straightforward: spreading $attrs means "pass everything that I don't care about down to this element/component".

Drawbacks

• Fallthrough behavior is now disabled by default and is controlled by the component author. If the component is intentionally "closed" there's no way for the consumer to change that. This may cause some inconvenience for users accustomed to the old behavior, but can be easily worked around with by wrapping the component in a wrapper element.

• For accessibility reasons, it should be a best practice for components that are shipped as libraries to always spread $attrs. However this is a straightforward / mechanical code change, and is more of an educational issue. We could make it common knowledge by emphasizing this in all our information channels.

Side Benefit

Not spreading $attrs actually improves performance.

• Start Date: 2019-04-09
• Target Major Version: 3.x
• Reference Issues: N/A
• Implementation PR: N/A

Summary

• Re-design custom directive API so that it better aligns with component lifecycle

• Custom directives usage on components will follow the same rules as discussed in the Attribute Fallthrough Behavior RFC. It will be controlled by the child component via v-bind="$attrs".

Basic example

Before

const MyDirective = {
  bind(el, binding, vnode, prevVnode) {},
  inserted() {},
  update() {},
  componentUpdated() {},
  unbind() {}
}

After

const MyDirective = {
  beforeMount(el, binding, vnode, prevVnode) {},
  mounted() {},
  beforeUpdate() {},
  updated() {},
  beforeUnmount() {}, // new
  unmounted() {}
}

Motivation

Make custom directive hook names more consistent with the component lifecycle.

Detailed design

Hooks Renaming

Existing hooks are renamed to map better to the component lifecycle, with some timing adjustments. Arguments passed to the hooks remain unchanged.

• bind -> beforeMount
• inserted -> mounted
• beforeUpdate new, called before the element itself is updated
• update removed, use updated instead
• componentUpdated -> updated
• beforeUnmount new
• unbind -> unmounted

Usage on Components

In 3.0, with fragments support, components can potentially have more than one root nodes. This creates an issue when a custom directive is used on a component with multiple root nodes.

To explain the details of how custom directives will work on components in 3.0, we need to first understand how custom directives are compiled in 3.0. For a directive like this:

<div v-foo="bar"></div>

Will roughly compile into this:

const vFoo = resolveDirective('foo')

return applyDirectives(h('div'), this, [
  [vFoo, bar]
])

Where vFoo will be the directive object written by the user, which contains hooks like mounted and updated.

applyDirective returns a cloned VNode with the user hooks wrapped and injected as vnode lifecycle hooks (see Render Function API Changes for more details):

{
  vnodeMounted(vnode, prevVNode) {
    // call vFoo.mounted(...)
  }
}

As a result, custom directives are fully included as part of a VNode's data. When a custom directive is used on a component, these vnodeXXX hooks are passed down to the component as extraneous props and end up in this.$attrs.

This is consistent with the attribute fallthrough behavior discussed in vuejs/rfcs#26. So, the rule for custom directives on a component will be the same as other extraneous attributes: it is up to the child component to decide where and whether to apply it. When the child component uses v-bind="$attrs" on an inner element, it will apply any custom directives used on it as well.

Drawbacks

N/A

Alternatives

N/A

Adoption strategy

• The renaming should be easy to support in the compat build
• Codemod should also be straightforward
• For directives used on components, the warning on unused $attrs as discussed in Attribute Fallthrough Behavior should apply as well.

Unresolved questions

N/A

• Start Date: 2019-03-12
• Target Major Version: 3.x
• Reference Issues: N/A
• Implementation PR: N/A

Summary

• h is now globally imported instead of passed to render functions as argument
• render function arguments changed and made consistent between stateful and functional components
• VNodes now have a flat data structure

Basic example

// globally imported `h`
import { h } from 'vue'

export default {
  // adjusted render function arguments
  render(props, slots) {
    return h(
      'div',
      // flat data structure
      { id: props.id },
      slots.default()
    )
  }
}

Motivation

In 2.x, VNodes are context-specific - which means every VNode created is bound to the component instance that created it (the "context"). This is because we need to support the following use cases:

// looking up a component based on a string ID
h('some-component')

h('div', {
  directives: [
    {
      name: 'foo', // looking up a directive by string ID
      // ...
    }
  ]
})

In order to look up locally/globally registered components and directives, we need to know the context component instance that "owns" the VNode. This is why in 2.x h is passed in as an argument, because the h passed into each render function is a curried version that is pre-bound to the context instance.

This has created a number of inconveniences, for example when trying to extract part of the render logic into a separate function, h needs to be passed along:

function renderSomething(h) {
  return h('div')
}

export default {
  render(h) {
    return renderSomething(h)
  }
}

When using JSX, this is especially cumbersome since h is used implicitly and isn't needed in user code. Our JSX plugin has to perform automatic h injection in order to alleviate this, but the logic is complex and fragile.

In 3.0 we have found ways to make VNodes context-free. They can now be created anywhere using the globally imported h function, so it only needs to be imported once in any file.

Another issue with 2.x's render function API is the nested VNode data structure:

h('div', {
  class: ['foo', 'bar'],
  style: { }
  attrs: { id: 'foo' },
  domProps: { innerHTML: '' },
  on: { click: foo }
})

This structure was inherited from Snabbdom, the original virtual dom implementation Vue 2.x was based on. The reason for this design was so that the diffing logic can be modular: an individual module (e.g. the class module) would only need to work on the class property. It is also more explicit what each binding will be processed as.

However, over time we have noticed there are a number of drawbacks of the nested structure compared to a flat structure:

• More verbose to write
• class and style special cases are somewhat inconsistent
• More memory usage (more objects allocated)
• Slower to diff (each nested object needs its own iteration loop)
• More complex / expensive to clone / merge / spread
• Needs more special rules / implicit conversions when working with JSX

In 3.x, we are moving towards a flat VNode data structure to address these problems.

Detailed design

Globally imported h function

h is now globally imported:

import { h } from 'vue'

export default {
  render() {
    return h('div')
  }
}

Render Function Arguments Change

With h no longer needed as an argument, the render function now receives a new set of arguments:

// MyComponent.js
export default {
  render(
    // declared props
    props,
    // resolved slots
    slots,
    // fallthrough attributes
    attrs,
    // the raw vnode in parent scope representing this component
    vnode
  ) {

  }
}

• props and attrs will be equivalent to this.$props and this.$attrs - also see Optional Props Declaration and Attribute Fallthrough

• slots will be equivalent to this.$slots - also see Slots Unification

• vnode will be equivalent to this.$vnode, which is the raw vnode that represents this component in parent scope, i.e. the return value of h(MyComponent, { ... }).

Note that the render function for a functional component will now also have the same signature, which makes it consistent in both stateful and functional components:

const FunctionalComp = (props, slots, attrs, vnode) => {
  // ...
}

The new list of arguments should provide the ability to fully replace the current functional render context:

• props and slots have equivalent values

• data and children can be accessed directly on vnode

• listeners will be included in attrs

• injections will have a dedicated new API:

  import { resolveInjection } from 'vue'
  import { themeSymbol } from './ThemeProvider'
  
  const FunctionalComp = props => {
    const theme = resolveInjection(themeSymbol)
    return h('div', `Using theme ${theme}`)
  }

• parent access will be removed. This was an escape hatch for some internal use cases - in userland code, props and injections should be preferred.

Flat VNode Data Format

// before
{
  class: ['foo', 'bar'],
  style: { color: 'red' },
  attrs: { id: 'foo' },
  domProps: { innerHTML: '' },
  on: { click: foo },
  key: 'foo'
}

// after
{
  class: ['foo', 'bar'],
  style: { color: 'red' },
  id: 'foo',
  innerHTML: '',
  onClick: foo,
  key: 'foo'
}

With the flat structure, the VNode data props are handled using the following rules:

• key, ref and slots are reserved special properties
• class and style have the same API as 2.x
• props that start with on are handled as v-on bindings
• for anything else:
  • If the key exists as a property on the DOM node, it is set as a DOM property;
  • Otherwise it is set as an attribute.

Due to the flat structure, this.$attrs inside a component now also contains any raw props that are not explicitly declared by the component, including onXXX listeners. This makes it much easier to write wrapper components - simply pass this.$attrs down with v-bind="$attrs" (as a result, this.$listeners will also be removed).

Context-free VNodes

With VNodes being context-free, we can no longer use a string ID (e.g. h('some-component')) to implicitly lookup globally registered components. Same for looking up directives. Instead, we need to use an imported API:

import { h, resolveComponent, resolveDirective, applyDirectives } from 'vue'

export default {
  render() {
    const comp = resolveComponent('some-global-comp')
    const fooDir = resolveDirective('foo')
    const barDir = resolveDirective('bar')

    // <some-global-comp v-foo="x" v-bar="y" />
    return applyDirectives(
      h(comp),
      this,
      [fooDir, this.x],
      [barDir, this.y]
    )
  }
}

This will mostly be used in compiler-generated output, since manually written render function code typically directly import the components and use them by value, and use rarely have to use directives.

Drawbacks

Reliance on Vue Core

h being globally imported means any library that contains Vue components will include import { h } from 'vue' somewhere (this is implicitly included in render functions compiled from templates as well). This creates a bit of overhead since it requires library authors to properly configure the externalization of Vue in their build setup:

• Vue should not be bundled into the library;
• For module builds, the import should be left alone and be handled by the end user bundler;
• For UMD / browser builds, it should try the global Vue.h first and fallback to require calls.

This is common practice for React libs and possible with both webpack and Rollup. A decent number of Vue libs also already does this. We just need to provide proper documentation and tooling support.

Alternatives

N/A

Adoption strategy

• For template users this will not affect them at all.

• For JSX users the impact will also be minimal, but we do need to rewrite our JSX plugin.

• Users who manually write render functions using h will be subject to major migration cost. This should be a very small percentage of our user base, but we do need to provide a decent migration path.

  • It's possible to provide a compat plugin that patches render functions and make them expose a 2.x compatible arguments, and can be turned off in each component for a one-at-a-time migration process.

  • It's also possible to provide a codemod that auto-converts h calls to use the new VNode data format, since the mapping is pretty mechanical.

• Functional components using context will likely have to be manually migrated, but a smilar adaptor can be provided.

Version

3.0.0-alpha.1

Reproduction link

https://github.com/chz/vue-next-test

Steps to reproduce

Clone repository and start Vue
Click "Toggle Visibility" 3-4 times

What is expected?

Div should be inserted to the correct dom.

What is actually happening?

The node before which the new node is to be inserted is not a child of this node.

Version

3.0.0-alpha.1

Reproduction link

https://github.com/chz/vue-next-test

Steps to reproduce

Clone repository and start Vue
Click "Toggle Visibility" 3-4 times

What is expected?

Div should be inserted to the correct dom.

What is actually happening?

The node before which the new node is to be inserted is not a child of this node.

Version

3.0.0-alpha.1

Reproduction link

https://jsfiddle.net/v27hqo1a/

Steps to reproduce

Not sure if this is intended but this code won't work:

watch(reactive({"test": "test"}), () => console.log("foo"))

but for normal refs, this works perfectly fine:

watch(ref(0), () => console.log("foo"))

will reactives also be supported?

What is expected?

reactive object should be watched

What is actually happening?

it will not be watched

to see the error within the fiddle just open the console.

Version

3.0.0-alpha.1

Reproduction link

https://codesandbox.io/s/zen-field-ewni3

vue 2 for comparison - https://jsfiddle.net/jfrhgbma/

Steps to reproduce

import { h, createApp } from "vue";

function Button(props, { attrs }) {
  console.log({
    props,
    attrs
  });
}

const App = {
  setup() {
    return () => [
      h(Button, {
        "data-id": 1,
        "aria-label": "Close",
      })
    ];
  }
};

createApp().mount(App, "#root");

What is expected?

Button's props should be in camelCase and attrs in kebab-case

What is actually happening?

Without explicit props declaration Button attrs keys are converted to camelCase.

This would allow for automatic data prefetching (for example with apollo) on the server.

Ideas:

• waitCounter = 0
• mount the App and render the whole component tree
• user/lib code can hook into renderToString with this.waitForPrefetch() (waitCounter++)
• if waitCounter is 0, resolve renderToString
• else, we wait for user/lib code that should call this.prefetchDone() after fetching data
  • we re-render the component
  • eventually code in children can call this.waitForPrefetch() again
  • then waitCounter--
  • then if waitCounter is 0 we resolve renderToString
• a re-render could trigger new this.waitForPrefetch() (maybe make this parametrable, like maxReRenders)
• <NoSSR> component prevents both server-side render and async prefetching
• some way of skipping a component (and its children) only for async prefetching, like a skipPrefetch () { return this.myProp } option?

I think it would be nice to have an official way of "pre-rendering" the components tree to gather prefetching data when doing SSR. Ideally much lighter than a real render, with ways to mock global/local properties and methods to speed it up, maybe with an API libraries can use to mock themselves.

This would hugely improve the SSR story because currently we are limited to the routes components. I recently made some experimentation with this in the vue-apollo SSR API that allows the user to prefetch all the GraphQL queries in his app without manually adding them if they are in rotue sub-components (or even outside of router views). However, I think it would be better as an official API so it's less exposed to breaking due to Vue internal changes.

The vue-apollo implementation also recognizes a special attribute like no-prefetch which skips a components sub-tree to optimize the tree walking if it is known that no queries will be found there.

Note: this has been split into two separate RFCs: #24 & #25

• Start Date: 03-05-2019
• Target Major Version: 2.x & 3.x
• Reference Issues: N/A
• Implementation PR: N/A

Summary

A set of React-hooks-inspired APIs for composing and reusing stateful logic across components.

Basic example

In Object API

import { value, computed, watch, useMounted, useDestroyed } from 'vue'

export default {
  created() {
    // value returns a value "ref" that has a .value property
    const count = value(0)

    // computed returns a computed "ref" with a read-only .value property
    const plusOne = computed(() => count.value + 1)

    // refs can be watched directly (or explicitly with `() => count.value`)
    watch(count, (count, oldCount) => {
      console.log(`count changed to: ${count}`)
    })

    watch(plusOne, countPlusOne => {
      console.log(`count plus one changed to: ${countPlusOne}`)
    })

    useMounted(() => {
      console.log('mounted')
    })

    useDestroyed(() => {
      console.log('destroyed')
    })

    // bind refs as properties to the instance. This exposes
    // this.count as a writable data property and this.plusOne as a read-only
    // computed property
    return {
      count,
      plusOne
    }
  }
}

In Class API

Usage in a Class-based API would be exactly the same:

import Vue, { useMounted } from 'vue'

export default class MyComponent extends Vue {
  created() {
    useMounted(() => {
      console.log('mounted')
    })
  }
}

Motivation

• React hooks like composition, but fits Vue's idiomatic usage
• A more composable replacement for Mixins

Detailed design

Summary

This proposal consists of three parts:

1. A set of APIs centered around reactivity, e.g. value, computed and watch. These will be part of the @vue/observer package, and re-exported in the main vue package. These APIs can be used anywhere and isn't particularly bound to the usage outlined in this proposal, however they are quintessential in making this proposal work.

2. A set of call-site constrained APIs that registers additional lifecycle hooks for the "current component", e.g. useMounted. These functions can only be called inside the created() lifecycle hook of a component.

3. The ability for the created() lifecycle hook to return an object of additional properties to expose on the component instance.

Reactivity APIs

In Vue 2.x, we already have the observable API for creating standalone reactive objects. Assuming we can return an object of additional properties to expose on this from created(), we can achieve the following:

import { observable } from 'vue'

const App = {
  created() {
    const state = observable({
      count: 0
    })

    const increment = () => {
      state.count++
    }

    // exposed on `this`
    return {
      state,
      increment
    }
  },
  template: `
    <button @click="increment">{{ state.count }}</button>
  `
}

The above is a contrived example just to demonstrate how it could work. In practice, this is intended mainly for encapsulating and reusing logic much more complex than a simple counter.

Value Container

Note in the above example we had to expose an object (so that Vue can register the dependency via the property access during render) even though what we are really exposing is just a number. We can use the value API to create a container object for a single value, called a "ref". A ref is simply a reactive object with a writable value property that holds the actual value:

import { value } from 'vue'

const countRef = value(0)

// read the value
console.log(countRef.value) // 0

// mutate the value
countRef.value++

The reason for using a container object is so that our code can have a persistent reference to a value that may be mutated over time.

A value ref is very similar to a plain reactive object with only the .value property. It is primarily used for holding primitive values, but the value can also be a deeply nested object, array or anything that Vue can observe. Deep access are tracked just like typical reactive objects. The main difference is that when a ref is returned as part of the return object in created(), it is bound as a direct property on the component instance:

import { value } from 'vue'

const App = {
  created() {
    return {
      count: value(0)
    }
  },
  template: `
    <button @click="count++">{{ count }}</button>
  `,
}

A ref binding exposes the value directly, so the template can reference it directly as count. It is also writable - note that the click handler can directly do count++. (In comparison, non-ref bindings returned from created() are readonly).

Computed State

In addition to writable value refs, we can also create standalone computed refs:

import { value, computed } from 'vue'

const count = value(0)
const countPlusOne = computed(() => count.value + 1)

console.log(countPlusOne.value) // 1
count.value++
console.log(countPlusOne.value) // 2

Computed refs are readonly. Assigning to its value property will result in an error.

Watchers

All .value access are reactive, and can be tracked with the standalone watch API.

import { value, computed, watch } from 'vue'

const count = value(0)
const double = computed(() => count.value * 2)

// watch and re-run the effect
watch(() => {
  console.log('count is: ', count.value)
})
// -> count is: 0

// 1st argument (the getter) can return a value, and the 2nd
// argument (the callback) only fires when returned value changes
watch(() => count.value + 1, value => {
  console.log('count + 1 is: ', value)
})
// -> count + 1 is: 1

// can also watch a ref directly
watch(double, value => {
  console.log('double the count is: ', value)
})
// -> double the count is: 0

count.value++
// -> count is: 1
// -> count + 1 is: 2
// -> double the count is: 2

Note that unlike this.$watch in 2.x, watch are immediate by default (defaults to { immediate: true }) unless a 3rd options argument with { lazy: true } is passed:

watch(
  () => count.value + 1,
  () => {
    console.log(`count changed`)
  },
  { lazy: true }
)

The callback can also return a cleanup function which gets called every time when the watcher is about to re-run, or when the watcher is stopped:

watch(someRef, value => {
  const token = performAsyncOperation(value)
  return () => {
    token.cancel()
  }
})

A watch returns a stop handle:

const stop = watch(...)

// stop watching
stop()

Watchers created inside a component's created() hook are automatically stopped when the owner component is destroyed.

Lifecycle Hooks

For each existing lifecycle hook (except beforeCreate and created), there will be an equivalent useXXX API. These APIs can only be called inside the created() hook of a component. The prefix use is an indication of the call-site constraint.

import { useMounted, useUpdated, useDestroyed } from 'vue'

export default {
  created() {
    useMounted(() => {
      console.log('mounted')
    })

    useUpdated(() => {
      console.log('updated')
    })

    useDestroyed(() => {
      console.log('destroyed')
    })
  }
}

Unlike React Hooks, created is called only once, so these calls are not subject to call order and can be conditional.

useXXX methods automatically detects the current component whose setup() is being called. The instance is also passed into the registered lifecycle hook as the argument. This means they can easily be extracted and reused across multiple components:

import { useMounted } from 'vue'

const useSharedLogic = () => {
  useMounted(vm => {
    console.log(`hello from component ${vm.$options.name}`)
  })
}

const CompA = {
  name: 'CompA',
  created() {
    useSharedLogic()
  }
}

const CompB = {
  name: 'CompB',
  created() {
    useSharedLogic()
  }
}

A More Practical Example

Let's take the example from React Hooks Documentation. Here's the equivalent in Vue's idiomatic API:

export default {
  props: ['id'],
  data() {
    return {
      isOnline: null
    }
  },
  created() {
    ChatAPI.subscribeToFriendStatus(this.id, this.handleStatusChange)
  },
  destroyed() {
    ChatAPI.unsubscribeFromFriendStatus(this.id, this.handleStatusChange)
  },
  watch: {
    id: (newId, oldId) => {
      ChatAPI.unsubscribeFromFriendStatus(oldId, this.handleStatusChange)
      ChatAPI.subscribeToFriendStatus(newId, this.handleStatusChange)
    }
  },
  methods: {
    handleStatusChange(status) {
      this.isOnline = status
    }
  }
}

And here's the equivalent using the APIs introduced in this proposal:

import { value, computed, watch } from 'vue'

export default {
  props: ['id'],
  created() {
    const isOnline = value(null)

    function handleStatusChange(status) {
      isOnline.value = status
    }

    watch(() => this.id, id => {
      // this is called immediately and then very time id changes
      ChatAPI.subscribeToFriendStatus(id, handleStatusChange)
      return () => {
        // this is called every time id changes and when the component
        // is unmounted (which causes the watcher to be stopped)
        ChatAPI.unsubscribeFromFriendStatus(id, handleStatusChange)
      }
    })

    return {
      isOnline
    }
  }
}

Note that because the watch function is immediate by default and also auto-stopped on component unmount, it achieves the effect of watch, created and destroyed options in one call (similar to useEffect in React Hooks).

The logic can also be extracted into a reusable function (like a custom hook):

import { value, computed, watch } from 'vue'

function useFriendStatus(idRef) {
  const isOnline = value(null)

  function handleStatusChange(status) {
    isOnline.value = status
  }

  watch(idRef, id => {
    ChatAPI.subscribeToFriendStatus(id, handleStatusChange)
    return () => {
      ChatAPI.unsubscribeFromFriendStatus(id, handleStatusChange)
    }
  })

  return isOnline
}

export default {
  props: ['id'],
  created() {
    return {
      // to pass watch-able state, make sure to pass a value
      // or computed ref
      isOnline: useFriendStatus(computed(() => this.id))
    }
  }
}

Note that even after logic extraction, the component is still responsible for:

• Declaring all the props it expects
• Declaring all the properties to expose to the template

Even with multiple extracted custom logic functions, there will be no confusion regarding where a prop or a data property comes from. This is a major advantage over mixins.

Drawbacks

• Type inference of returned values. This actually works better in the object-based API because we can reverse infer this based on the return value of created(), but it's harder to do so in a class. The user will likely have to explicitly annotate these properties on the class.

• To pass state around while keeping them "trackable" and "reactive", values must be passed around in the form of ref containers. This is a new concept and can be a bit more difficult to learn than the base API. However, this isn't intended as a replacement for the base API - it is positioned as a advanced mechanism to encapsulate and reuse logic across components.

Alternatives

Compared to React hooks:

• same composition capability
• closer mapping to Vue's existing usage
• no repeated invocation, less wasted memory on repeated render
• watch has automatic dependency tracking, no need to worry about exhaustive deps
• reactive state are always referenced via refs so no confusion of stale closures
• does not rely on call order

Adoption strategy

TODO

Unresolved questions

• We can also use data() instead of created(), since data() is already used for exposing properties to the template. But it feels a bit weird to perform side effects like watch or useMounted in data().

  • Maybe we can introduce a new option dedicated for this purpose, e.g. state()? (replaces data() and has special handling for refs in returned value)

• We probably need to also expose a isRef method to check whether an object is a value/computed ref.

Appendix: More Usage Examples

Data Fetching

This is the equivalent of what we can currently achieve via scoped slots with libs like vue-promised. This is just an example showing that this new set of API is capable of achieving similar results.

function useFetch(endpointRef) {
  const res = value({
    status: 'pending',
    data: null,
    error: null
  })

  // watch can directly take a computed ref
  watch(endpointRef, endpoint => {
    let aborted = false
    fetch(endpoint)
      .then(res => res.json())
      .then(data => {
        if (aborted) {
          return
        }
        res.value = {
          status: 'success',
          data,
          error: null
        }
      }).catch(error => {
        if (aborted) {
          return
        }
        res.value = {
          status: 'error',
          data: null,
          error
        }
      })
    return () => {
      aborted = true
    }
  })

  return res
}

// usage
const App = {
  created(props) {
    return {
      postData: useFetch(computed(() => `/api/posts/${props.id}`))
    }
  },
  template: `
    <div>
      <div v-if="postData.status === 'pending'">
        Loading...
      </div>
      <div v-else-if="postData.status === 'success'">
        {{ postData.data }}
      </div>
      <div v-else>
        {{ postData.error }}
      </div>
    </div>
  `
}

Use the Platform

Hypothetical examples of exposing state to the component from external sources. This is more explicit than using mixins regarding where the state comes from.

export default {
  created() {
    const { x, y } = useMousePosition()
    const orientation = useDeviceOrientation()
    return {
      x,
      y,
      orientation
    }
  }
}

Version

3.0.0-alpha.1

Reproduction link

https://have.not

Steps to reproduce

I accidentally noticed that if I write setup function like this, I will not receive the context parameter.

export default {
  setup(...args) {
    console.log(args[1]) // null
  }
}

What is expected?

args[1] is context

What is actually happening?

args[1] is null

I found why:
https://github.com/vuejs/vue-next/blob/master/packages/runtime-core/src/component.ts#L293

I know most people won't write like this, but it's a little weird for me.

Just for discuss.

Rationale

https://twitter.com/youyuxi/status/1056673771376050176

Hooks provides the ability to:

• encapsulate arbitrarily complex logic in plain functions
• does not pollute component namespace (explicit injection)
• does not result in additional component instances like HOCs / scoped-slot components
• superior composability, e.g. passing the state from one hook to another effect hook. This is possible by referencing fields injected by other mixins in a mixin, but that is super flaky and hooks composition is way cleaner.
• compresses extremely well

However, it is quite different from the intuitions of idiomatic JS, and has a number of issues that can be confusing to beginners. This is why we should integrate it in a way that complements Vue's existing API, and primarily use it as a composition mechanism (replacement of mixins, HOCs and scoped-slot components).

Proposed usage

Directly usable inside class render functions (can be mixed with normal class usage):

class Counter extends Component {
  foo = 'hello'
  render() {
    const [count, setCount] = useState(0)
    return h(
      'div',
      {
        onClick: () => {
          setCount(count + 1)
        }
      },
      this.foo + ' ' + count
    )
  }
}

For template usage:

class Counter extends Component {
  static template = `
    <div @click="setCount(count + 1)">
      {{ count }}
    </div>
  `

  hooks() {
    const [count, setCount] = useState(0)
    // fields returned here will become available in templates
    return {
      count,
      setCount
    }
  }
}

In SFC w/ object syntax:

<template>
  <div @click="setCount(count + 1)">
    {{ count }}
  </div>
</template>

<script>
import { useState } from 'vue'

export default {
  hooks() {
    const [count, setCount] = useState(0)
    return {
      count,
      setCount
    }
  }
}
</script>

Note: counter is a super contrived example mainly to illustrate how the API works. A more practical example would be this useAPI custom hook, which is similar to libs like vue-promised.

Implementation Notes

Proposed usage for useState and useEffect are already implemented.

Update: Mapping w/ Vue's existing API

To ease the learning curve for Vue users, we can implement hooks that mimic Vue's current API:

export default {
  render() {
    const data = useData({
      count: 0
    })

    useWatch(() => data.count, (val, prevVal) => {
      console.log(`count is: ${val}`)
    })

    const double = useComputed(() => data.count * 2)

    useMounted(() => {
      console.log('mounted!')
    })
    useUnmounted(() => {
      console.log('unmounted!')
    })
    useUpdated(() => {
      console.log('updated!')
    })

    return [
      h('div', `count is ${data.count}`),
      h('div', `double count is ${double}`),
      h('button', { onClick: () => {
        // still got that direct mutation!
        data.count++
      }}, 'count++')
    ]
  }
}

Version

3.0.0-alpha.1

Reproduction link

https://jsfiddle.net/fva48tsr/

Steps to reproduce

I tried out the basic store pattern example from the docs, but it doesn't ever update.

<template>
  <div>{{ sharedState.counter }}</div>
</template>

<script>
var store = {
  state: {
    counter: 0
  },
  increment: function() {
    this.state.counter  ;
  }
};

export default {
  data: function() {
    return {
      sharedState: store.state
    };
  },
  mounted: function() {
    setInterval(() => {
      store.increment();
    }, 1000);
  }
}
</script>

What is expected?

The counter goes up

What is actually happening?

The counter doesn't change

@yyx990803
Hi Evan, the new diff algorithm is really amazing, thank you for your efforts, but I have a question about this, assuming the following code is generated by the compiler:

(
  openBlock(),
  createBlock('div', null, [        // block_one
    h('p', 123),
    h('p', this.name),
    this.isTruth
      ? (
          openBlock(),
          createBlock('div', null, [  // block_two
            h('p', 456),
            h('p', this.text1) 
          ])
        )
      : (
          openBlock(),
          createBlock('div', null, [  // block_three
            h('p', this.text2) 
          ])
        )
  ])
)

When isTruth is true then:

block_one.dynamicChildren = [ // oldBlockTree
  h('p', this.name),
  block_two
]

When isTruth becomes false:

block_one.dynamicChildren = [ // newBlockTree
  h('p', this.name),
  block_three
]

When diff oldBlockTree and newBlockTree, since block_two and block_three are different blocks, their children may have different structures. If we only diff their dynamic children, it should be incorrect. I just checked the code here https://github.com/vuejs/vue-next/blob/master/packages/runtime-core/src/createRenderer.ts#L367-L380 What important information did I miss? I am not sure if the above example is reasonable, If not, then simply close the issue.

The transparent wrapper pattern is very convenient and increasingly common, but still a little clunky in Vue 2.x. For example, to get a BaseInput component that can be used exactly like a normal input element, we need to do this:

<script>
export default {
  props: {
    value: {
      type: String
    }
  },
  computed: {
    listeners() {
      return {
        ...this.$listeners,
        input: event => {
          this.$emit('input', event.target.value)
        }
      }
    }
  }
}
</script>

<template>
  <input
    :value="value"
    v-on="listeners"
  >
</template>

In Vue 3, that will currently translate to:

<script>
class InputText extends Component {
  // Currently, `v-model` on a component assumes `value` is a 
  // prop, so it will never be included in $attrs, even if no
  // `value` prop is defined. This forces users to always define 
  // `value` as a prop, even if it's never needed by the component.
  static props = {
    value: String
  }

  get attrs () {
    return {
      ...this.$attrs,
      // We have to manually include the `value` prop to `attrs`,
      // due to `v-model`'s assumption that `value` is a prop.
      value: this.value,
      // Since `v-model` listens to the `input` event by default, 
      // the user is forced to override it when using binding 
      // $attrs in order to prevent the unwanted behavior of the
      // `event` object being emitted as the new value.
      onInput: event => {
        this.$emit('input', event.target.value)
      }
    }
  }
}
</script>

<template>
  <input v-bind="attrs">
</template>

Still quite a bit of work. 😕

However, if we remove v-model's assumption that value is a prop, then it no longer has to be added separately. And if we also make v-model listen for an update:value event by default (as @posva suggested here), instead of input, then we no longer have to override input and can just add a new listener.

With these 2 changes, our BaseInput component would simplify to:

<template>
  <input
    v-bind="$attrs"
    @input="$emit('update:value', $event.target.value)"
  >
</template>

To me, this is much more convenient and intuitive. 🙂

@yyx990803 @posva @johnleider What do you think?

• Start Date: 2019-05-30
• Target Major Version: 2.x / 3.x
• Reference Issues: vuejs/rfcs#22 vuejs/rfcs#23
• Implementation PR: (leave this empty)

Summary

Expose logic-related component options via function-based APIs instead.

Basic example

import { value, computed, watch, onMounted } from 'vue'

const App = {
  template: `
    <div>
      <span>count is {{ count }}</span>
      <span>plusOne is {{ plusOne }}</span>
      <button @click="increment">count++</button>
    </div>
  `,
  setup() {
    // reactive state
    const count = value(0)
    // computed state
    const plusOne = computed(() => count.value + 1)
    // method
    const increment = () => { count.value++ }
    // watch
    watch(() => count.value * 2, val => {
      console.log(`count * 2 is ${val}`)
    })
    // lifecycle
    onMounted(() => {
      console.log(`mounted`)
    })
    // expose bindings on render context
    return {
      count,
      plusOne,
      increment
    }
  }
}

Motivation

Logic Composition

One of the key aspects of the component API is how to encapsulate and reuse logic across multiple components. With Vue 2.x's current API, there are a number of common patterns we've seen in the past, each with its own drawbacks. These include:

• Mixins (via the mixins option)
• Higher-order components (HOCs)
• Renderless components (via scoped slots)

These patterns are discussed in more details in the appendix - but in general, they all suffer from one or more of the drawbacks below:

• Unclear sources for properties exposed on the render context. For example, when reading the template of a component using multiple mixins, it can be difficult to tell from which mixin a specific property was injected from.

• Namespace clashing. Mixins can potentially clash on property and method names, while HOCs can clash on expected prop names.

• Performance. HOCs and renderless components require extra stateful component instances that come at a performance cost.

The function based API, inspired by React Hooks, presents a clean and flexible way to compose logic inside and between components without any of these drawbacks. This can be achieved by extracting code related to a piece of logic into what we call a "composition function" and returning reactive state. Here is an example of using a composition function to extract the logic of listening to the mouse position:

function useMouse() {
  const x = value(0)
  const y = value(0)
  const update = e => {
    x.value = e.pageX
    y.value = e.pageY
  }
  onMounted(() => {
    window.addEventListener('mousemove', update)
  })
  onUnmounted(() => {
    window.removeEventListener('mousemove', update)
  })
  return { x, y }
}

// in consuming component
const Component = {
  setup() {
    const { x, y } = useMouse()
    const { z } = useOtherLogic()
    return { x, y, z }
  },
  template: `<div>{{ x }} {{ y }} {{ z }}</div>`
}

Note in the example above:

• Properties exposed to the template have clear sources since they are values returned from composition functions;
• Returned values from composition functions can be arbitrarily named so there is no namespace collision;
• There are no unnecessary component instances created just for logic reuse purposes.

See also:

• Appendix: Comparison with React Hooks

Type Inference

One of the major goals of 3.0 is to provide better built-in TypeScript type inference support. Originally we tried to address this problem with the now-abandoned Class API RFC, but after discussion and prototyping we discovered that using Classes doesn't fully address the typing issue.

The function-based APIs, on the other hand, are naturally type-friendly. In the prototype we have already achieved full typing support for the proposed APIs.

See also:

• Appendix: Type Issues with Class API

Bundle Size

Function-based APIs are exposed as named ES exports and imported on demand. This makes them tree-shakable, and leaves more room for future API additions. Code written with function-based APIs also compresses better than object-or-class-based code, since (with standard minification) function and variable names can be shortened while object/class methods and properties cannot.

Detailed design

The setup function

A new component option, setup() is introduced. As the name suggests, this is the place where we use the function-based APIs to setup the logic of our component. setup() is called when an instance of the component is created, after props resolution. The function receives the resolved props as its argument:

const MyComponent = {
  props: {
    name: String
  },
  setup(props) {
    console.log(props.name)
  }
}

Note this props object is reactive - i.e. it is updated when new props are passed in, and can be observed and reacted upon using the watch function introduced later in this RFC. However, for userland code, it is immutable during development (will emit warning if user code attempts to mutate it).

State

Similar to data(), setup() can return an object containing properties to be exposed to the template's render context:

const MyComponent = {
  props: {
    name: String
  },
  setup(props) {
    return {
      msg: `hello ${props.name}!`
    }
  },
  template: `<div>{{ msg }}</div>`
}

This works exactly like data() - msg becomes a reactive and mutable property, but only on the render context. In order to expose a reactive value that can be mutated by a function declared inside setup(), we can use the value API:

import { value } from 'vue'

const MyComponent = {
  setup(props) {
    const msg = value('hello')
    const appendName = () => {
      msg.value = `hello ${props.name}`
    }
    return {
      msg,
      appendName
    }
  },
  template: `<div @click="appendName">{{ msg }}</div>`
}

Calling value() returns a value wrapper object that contains a single reactive property: .value. This property points to the actual value the wrapper is holding - in the example above, a string. The value can be mutated:

// read the value
console.log(msg.value) // 'hello'
// mutate the value
msg.value = 'bye'

Why do we need value wrappers?

Primitive values in JavaScript like numbers and strings are not passed by reference. Returning a primitive value from a function means the receiving function will not be able to read the latest value when the original is mutated or replaced.

Value wrappers are important because they provide a way to pass around mutable and reactive references for arbitrary value types. This is what enables composition functions to encapsulate the logic that manages the state while passing the state back to the components as a trackable reference:

setup() {
  const valueA = useLogicA() // logic inside useLogicA may mutate valueA
  const valueB = useLogicB()
  return {
    valueA,
    valueB
  }
}

Value wrappers can also hold non-primitive values and will make all nested properties reactive. Holding non-primitive values like objects and arrays inside a value wrapper provides the ability to entirely replace the value with a fresh one:

const numbers = value([1, 2, 3])
// replace the array with a filtered copy
numbers.value = numbers.value.filter(n => n > 1)

If you want to create a non-wrapped reactive object, use observable (which is an exact equivalent of 2.x Vue.observable API):

import { observable } from 'vue'

const object = observable({
  count: 0
})

object.count++

Value Unwrapping

Note in the last example we are using {{ msg }} in the template without the .value property access. This is because value wrappers get "unwrapped" when they are accessed on the render context or as a nested property inside a reactive object.

You can mutate an unwrapped value binding in inline handlers:

const MyComponent = {
  setup() {
    return {
      count: value(0)
    }
  },
  template: `<button @click="count++">{{ count }}</button>`
}

Value wrappers are also automatically unwrapped when accessed as a nested property inside a reactive object:

const count = value(0)
const obj = observable({
  count
})

console.log(obj.count) // 0

obj.count++
console.log(obj.count) // 1
console.log(count.value) // 1

count.value++
console.log(obj.count) // 2
console.log(count.value) // 2

As a rule of thumb, the only occasions where you need to use .value is when directly accessing value wrappers as variables.

Computed Values

In addition to plain value wrappers, we can also create computed values:

import { value, computed } from 'vue'

const count = value(0)
const countPlusOne = computed(() => count.value + 1)

console.log(countPlusOne.value) // 1

count.value++
console.log(countPlusOne.value) // 2

A computed value behaves just like a 2.x computed property: it tracks its dependencies and only re-evaluates when dependencies have changed.

Computed values can also be returned from setup() and will get unwrapped just like normal value wrappers. The main difference is that they are read-only by default - assigning to a computed value's .value property or attempting to mutate a computed value binding on the render context will be a no-op and result in a warning.

To create a writable computed value, provide a setter via the second argument:

const count = value(0)
const writableComputed = computed(
  // read
  () => count.value + 1,
  // write
  val => {
    count.value = val - 1
  }
)

Watchers

All .value access are reactive, and can be tracked with the standalone watch API, which behaves like the 2.x vm.$watch API but with important differences.

The first argument passed to watch can be either a getter function or a value wrapper. The second argument is a callback that will only get called when the value returned from the getter or the value wrapper has changed:

watch(
  // getter
  () => count.value + 1,
  // callback
  (value, oldValue) => {
    console.log('count + 1 is: ', value)
  }
)
// -> count + 1 is: 1

count.value++
// -> count + 1 is: 2

Unlike 2.x $watch, the callback will be called once when the watcher is first created. This is similar to 2.x watchers with immediate: true, but with a slight difference. By default, the callback is called after current renderer flush. In other words, the callback is always called when the DOM has already been updated. This behavior can be configured.

In 2.x we often notice code that performs the same logic in mounted and in a watcher callback - e.g. fetching data based on a prop. The new watch behavior makes it achievable with a single statement.

Watching Props

As mentioned previously, the props object passed to the setup() function is reactive and can be used to watch for props changes:

const MyComponent = {
  props: {
    id: number
  },
  setup(props) {
    const data = value(null)
    watch(() => props.id, async (id) => {
      data.value = await fetchData(id)
    })
  }
}

Watching Value Wrappers

// double is a computed value
const double = computed(() => count.value * 2)

// watch a value directly
watch(double, value => {
  console.log('double the count is: ', value)
}) // -> double the count is: 0

count.value++ // -> double the count is: 2

Stopping a Watcher

A watch call returns a stop handle:

const stop = watch(...)
// stop watching
stop()

If watch is called inside setup() or lifecycle hooks of a component instance, it will automatically be stopped when the associated component instance is unmounted:

export default {
  setup() {
    // stopped automatically when the component unmounts
    watch(/* ... */)
  }
}

Effect Cleanup

Sometimes the watcher callback will perform async side effects that need to be invalidated when the watched value changes. The watcher callback receives a 3rd argument that can be used to register a cleanup function. The cleanup function is called when:

• the watcher is about to re-run
• the watcher is stopped (i.e. when the component is unmounted if watch is used inside setup())

watch(idValue, (id, oldId, onCleanup) => {
  const token = performAsyncOperation(id)
  onCleanup(() => {
    // id has changed or watcher is stopped.
    // invalidate previously pending async operation
    token.cancel()
  })
})

We are registering cleanup via a passed-in function instead of returning it from the callback (like React useEffect) because the return value is important for async error handling. It is very common for the watcher callback to be an async function when performing data fetching:

const data = value(null)
watch(getId, async (id) => {
  data.value = await fetchData(id)
})

An async function implicitly returns a Promise, but the cleanup function needs to be registered immediately before the Promise resolves. In addition, Vue relies on the returned Promise to automatically handle potential errors in the Promise chain.

Watcher Callback Timing

By default, all watcher callbacks are fired after current renderer flush. This ensures that when callbacks are fired, the DOM will be in already-updated state. If you want a watcher callback to fire before flush or synchronously, you can use the flush option:

watch(
  () => count.value + 1,
  () => console.log(`count changed`),
  {
    flush: 'post', // default, fire after renderer flush
    flush: 'pre', // fire right before renderer flush
    flush: 'sync' // fire synchronously
  }
)

Full watch Options

interface WatchOptions {
  lazy?: boolean
  deep?: boolean
  flush?: 'pre' | 'post' | 'sync'
  onTrack?: (e: DebuggerEvent) => void
  onTrigger?: (e: DebuggerEvent) => void
}

Lifecycle Hooks

All current lifecycle hooks will have an equivalent onXXX function that can be used inside setup():

import { onMounted, onUpdated, onUnmounted } from 'vue'

const MyComponent = {
  setup() {
    onMounted(() => {
      console.log('mounted!')
    })
    onUpdated(() => {
      console.log('updated!')
    })
    onUnmounted(() => {
      console.log('unmounted!')
    })
  }
}

Dependency Injection

import { provide, inject } from 'vue'

const CountSymbol = Symbol()

const Ancestor = {
  setup() {
    // providing a value can make it reactive
    const count = value(0)
    provide({
      [CountSymbol]: count
    })
  }
}

const Descendent = {
  setup() {
    const count = inject(CountSymbol)
    return {
      count
    }
  }
}

If provided key contains a value wrapper, inject will also return a value wrapper and the binding will be reactive (i.e. the child will update if ancestor mutates the provided value).

Drawbacks

Makes it more difficult to reflect and manipulate component definitions. (Maybe that's a good thing?)

Alternatives

• Class API (dropped)

Adoption strategy

The proposed APIs are all new additions and can theoretically be introduced in a completely backwards compatible way. However, the new APIs can replace many of the existing options and makes them unnecessary in the long run. Being able to drop some of these old options will result in considerably smaller bundle size and better performance.

Therefore we are planning to provide two builds for 3.0:

• Compatibility build: supports both the new function-based APIs AND all the 2.x options.

• Standard build: supports the new function-based APIs and only a subset of 2.x options.

Current 2.x users can start with the compatibility build and progressively migrate away from deprecated options, until eventually switching to the standard build.

Preserved Options

Preserved options work the same as 2.x and are available in both the compatibility and standard builds of 3.0. Options marked with * may receive further adjustments before 3.0 official release.

• name
• props
• template
• render
• components
• directives
• filters *
• delimiters *
• comments *

Options deprecated by this RFC

These options will only be available in the compatibility build of 3.0.

• data (replaced by value and value.raw returned from setup())
• computed (replaced by computed returned from setup())
• methods (replaced by plain functions returned from setup())
• watch (replaced by watch)
• provide/inject (replaced by provide and inject)
• mixins (replaced by function composition)
• extends (replaced by function composition)
• All lifecycle hooks (replaced by onXXX functions)

Options deprecated by other RFCs

These options will only be available in the compatibility build of 3.0.

• el

  Components are no longer mounted by instantiating a constructor with new, Instead, a root app instance is created and explicitly mounted. See RFC#29.

• propsData

  Props for root component can be passed via app instance's mount method. See RFC#29.

• functional

  Functional components are now declared as plain functions. See RFC#27.

• model

  No longer necessary with v-model arguments. See RFC#31.

• inheritAttrs

  Deperecated by RFC#26.

Appendix

Comparison with React Hooks

The function based API provides the same level of logic composition capabilities as React Hooks, but with some important differences. Unlike React hooks, the setup() function is called only once. This means code using Vue's function APIs are:

• In general more aligned with the intuitions of idiomatic JavaScript code;
• Not sensitive to call order and can be conditional;
• Not called repeatedly on each render and produce less GC pressure;
• Not subject to the issue where useEffect callback may capture stale variables if the user forgets to pass the correct dependency array;
• Not subject to the issue where useMemo is almost always needed in order to prevent inline handlers causing over-re-rendering of child components;

Type Issues with Class API

The primary goal of introducing the Class API was to provide an alternative API that comes with better TypeScript inference support. However, the fact that Vue components need to merge properties declared from multiple sources onto a single this context creates a bit of a challenge even with a Class-based API.

One example is the typing of props. In order to merge props onto this, we have to either use a generic argument to the component class, or use a decorator.

Here's an example using generic arguments:

interface Props {
  message: string
}

class App extends Component<Props> {
  static props = {
    message: String
  }
}

Since the interface passed to the generic argument is in type-land only, the user still needs to provide a runtime props declaration for the props proxying behavior on this. This double-declaration is redundant and awkward.

We've considered using decorators as an alternative:

class App extends Component<Props> {
  @prop message: string
}

Using decorators creates a reliance on a stage-2 spec with a lot of uncertainties, especially when TypeScript's current implementation is completely out of sync with the TC39 proposal. In addition, there is no way to expose the types of props declared with decorators on this.$props, which breaks TSX support. Users may also assume they can declare a default value for the prop with @prop message: string = 'foo' when technically it just can't be made to work as expected.

In addition, currently there is no way to leverage contextual typing for the arguments of class methods - which means the arguments passed to a Class' render function cannot have inferred types based on the Class' other properties.

Vue 2

So right now, in Vue 2, we have 14 different builds

Why? Because we have 4 different dimensions that define a build:

1. Compiler?

• Runtime+compiler
• Runtime only

2. Format

• Commonjs
• ESM
• ESM.browser
• UMD

3. Minification (~ "mode")

• Minified (= prod)
• non-minified (= dev)

Vue 3

In Vue 3, we get 2 additional dimensions to the existing ones through compatibility builds:

4. API comptibility

• Function-based API only
• ^+ compatibilty for Vue 2 object notation

5. IE compatibility

• Proxy-based reactivity
• getter/setter based reactivity (a la Vue 2)

The issue

If we want to keep all permutations supported, we end up with:

14 * 4 = 56 different builds!

That's a lot of builds 👀 - and certainly too many to leave for the user to pick from.

Alternatives / Mitigation

Drop some dimension variations

1. no commonjs for non-compatiblity builds? New APIs = new build systems = ES modules?
2. ...?

compose at the package level?

import { createVue } from '@vue/core'
import apifrom '@vue/api-compat'
import ractivity from '@vue/reactivity-compat'
export default createVue({
  reactivity,
  api,
})

Seems cumbersome, especially since this combo will be the default starting point for migrating existing projects.

So... Toughts?

Version

3.0.0-alpha.0

Reproduction link

https://jsfiddle.net/bn08c9rL/2/

Steps to reproduce

1. Create a reactive() object.
2. Create a reactive() set.
3. add() the reactive object to the set.
4. Attempt to delete() the reactive object from the set. The item is not deleted.

What is expected?

The item should be deleted from the set.

What is actually happening?

The item is not deleted from the set.

• Start Date: (fill me in with today's date, YYYY-MM-DD)
• Target Major Version: (2.x / 3.x)
• Reference Issues: (fill in existing related issues, if any)
• Implementation PR: (leave this empty)

Summary

Re-design app bootstrapping and global configuration API.

Basic example

Before

import Vue from 'vue'
import App from './App.vue'

Vue.config.ignoredElements = [/^app-/]
Vue.use(/* ... */)
Vue.mixin(/* ... */)
Vue.component(/* ... */)
Vue.directive(/* ... */)

new Vue({
  render: h => h(App)
}).$mount('#app')

After

import { createApp } from 'vue'
import App from './App.vue'

const app = createApp()

app.config.ignoredElements = [/^app-/]
app.use(/* ... */)
app.mixin(/* ... */)
app.component(/* ... */)
app.directive(/* ... */)

app.mount(App, '#app')

Motivation

Vue's current global API and configurations permanently mutate global state. This leads to a few problems:

• Global configuration makes it easy to accidentally pollute other test cases during testing. Users need to carefully store original global configuration and restore it after each test (e.g. resetting Vue.config.errorHandler). Some APIs (e.g. Vue.use, Vue.mixin) don't even have a way to revert their effects. This makes tests involving plugins particularly tricky.

  • vue-test-utils has to implement a special API createLocalVue to deal with this

• This also makes it difficult to share the same copy of Vue between multiple "apps" on the same page, but with different global configurations:

  // this affects both root instances
  Vue.mixin({ /* ... */ })
  
  const app1 = new Vue({ el: '#app-1' })
  const app2 = new Vue({ el: '#app-2' })

Detailed design

Technically, Vue 2 doesn't have the concept of an "app". What we define as an app is simply a root Vue instance created via new Vue(). Every root instance created from the same Vue constructor shares the same global configuration.

In this proposal we introduce a new global API, createApp:

import { createApp } from 'vue'
import App from './App.vue'

const app = createApp(App)

Calling createApp with a root component returns an app instance. An app instance provides an app context. The entire component tree formed by the root instance and its descendent components share the same app context, which provides the configurations that were previously "global" in Vue 2.x.

Global API Mapping

An app instance exposes a subset of the current global APIs. The rule of thumb is any APIs that globally mutate Vue's behavior are now moved to the app instance. These include:

• Global configuration
  • Vue.config -> app.config
    • with the exception of Vue.config.productionTip
• Asset registration APIs
  • Vue.component -> app.component
  • Vue.directive -> app.directive
  • Vue.filter -> app.filter
• Behavior Extension APIs
  • Vue.mixin -> app.mixin
  • Vue.use -> app.use

Global APIs that are idempotent (i.e. do not globally mutate behavior) are now named exports as proposed in Global API Treeshaking.

Mounting App Instance

The app instance can be mounted with the mount method. It works the same as the existing vm.$mount() component instance method and returns the mounted root component instance:

const rootInstance = app.mount('#app')

rootInstance instanceof Vue // true

Provide / Inject

An app instance can also provide dependencies that can be injected by any component inside the app:

// in the entry
app.provide({
  [ThemeSymbol]: theme
})

// in a child component
export default {
  inject: {
    theme: {
      from: ThemeSymbol
    }
  },
  template: `<div :style="{ color: theme.textColor }" />`
}

This is similar to using the provide option in a 2.x root instance.

Drawbacks

• Global APIs are now split between app instance methods and global named imports, instead of a single namespace. However the split makes sense because:

  • App instance methods are configuration APIs that globally mutate an app's behavior. They are also almost always used together only in the entry file of a project.

  • Global named imports are idempotent helper methods that are typically imported and used across the entire codebase.

Alternatives

N/A

Adoption strategy

• The transformation is straightforward (as seen in the basic example).
• A codemod can also be provided.

Unresolved questions

• Vue.config.productionTip is left out because it is indeed "global". Maybe it should be moved to a global method?

  import { suppressProductionTip } from 'vue'
  
  suppressProductionTip()

• Start Date: 03-05-2019
• Target Major Version: 2.x & 3.x
• Reference Issues: N/A
• Implementation PR: N/A

Summary

Introduce APIs for dynamically injecting component lifecycle hooks.

Basic example

import { onMounted, onUnmounted } from 'vue'

export default {
  beforeCreate() {
    onMounted(() => {
      console.log('mounted')
    })

    onUnmounted(() => {
      console.log('unmounted')
    })
  }
}

Motivation

In advanced use cases, we sometimes need to dynamically hook into a component's lifecycle events after the component instance has been created. In Vue 2.x there is an undocumented API via custom events:

export default {
  created() {
    this.$on('hook:mounted', () => {
      console.log('mounted!')
    })
  }
}

This API has some drawbacks because it relies on the event emitter API with string event names and a reference of the target component instance:

1. Event emitter APIs with string event names are prone to typos and is hard to notice when a typo is made because it fails silently.

2. If we were to extract complex logic into external functions, the target instance has to be passed to it via an argument. This can get cumbersome when there are additional arguments, and when trying to further split the function into smaller functions. When called inside a component's data() or lifecycle hooks, the target instance can already be inferred by the framework, so ideally the instance reference should be made optional.

This proposal addresses both problems.

Detailed design

For each existing lifecycle hook (except beforeCreate), there will be an equivalent onXXX API:

import { onMounted, onUpdated, onDestroyed } from 'vue'

export default {
  created() {
    onMounted(() => {
      console.log('mounted')
    })

    onUpdated(() => {
      console.log('updated')
    })

    onDestroyed(() => {
      console.log('destroyed')
    })
  }
}

When called inside a component's data() or lifecycle hooks, the current instance is automatically inferred. The instance is also passed into the callback as the argument:

onMounted(instance => {
  console.log(instance.$options.name)
})

Explicit Target Instance

When used outside lifecycle hooks, the target instance can be explicitly passed in via the second argument:

onMounted(() => { /* ... */ }, targetInstance)

If the target instance cannot be inferred and no explicit target instance is passed, an error will be thrown.

Injection Removal

onXXX calls return a removal function that removes the injected hook:

// an updated hook that fires only once
const remove = onUpdated(() => {
  remove()
})

Appendix: More Examples

Pre-requisite: please read the Advanced Reactivity API RFC first.

When combined with the ability to create and observe state via standalone APIs, it's possible to encapsulate arbitrarily complex logic in an external function, (with capabilities similar to React hooks):

Data Fetching

This is the equivalent of what we can currently achieve via scoped slots with libs like vue-promised. This is just an example showing that this new set of API is capable of achieving similar results.

import { value, computed, watch } from 'vue'

function useFetch(endpointRef) {
  const res = value({
    status: 'pending',
    data: null,
    error: null
  })

  // watch can directly take a computed ref
  watch(endpointRef, endpoint => {
    let aborted = false
    fetch(endpoint)
      .then(res => res.json())
      .then(data => {
        if (aborted) {
          return
        }
        res.value = {
          status: 'success',
          data,
          error: null
        }
      }).catch(error => {
        if (aborted) {
          return
        }
        res.value = {
          status: 'error',
          data: null,
          error
        }
      })
    return () => {
      aborted = true
    }
  })

  return res
}

// usage
const App = {
  props: ['id'],
  data() {
    return {
      postData: useFetch(computed(() => `/api/posts/${this.id}`))
    }
  },
  template: `
    <div>
      <div v-if="postData.status === 'pending'">
        Loading...
      </div>
      <div v-else-if="postData.status === 'success'">
        {{ postData.data }}
      </div>
      <div v-else>
        {{ postData.error }}
      </div>
    </div>
  `
}

Use the Platform

Hypothetical examples of exposing state to the component from external sources. This is more explicit than using mixins regarding where the state comes from.

import { value, onMounted, onDestroyed } from 'vue'

function useMousePosition() {
  const x = value(0)
  const y = value(0)

  const onMouseMove = e => {
    x.value = e.pageX
    y.value = e.pageY
  }

  onMounted(() => {
    window.addEventListener('mousemove', onMouseMove)
  })

  onDestroyed(() => {
    window.removeEventListener('mousemove', onMouseMove)
  })

  return { x, y }
}

export default {
  data() {
    const { x, y } = useMousePosition()
    return {
      x,
      y,
      // ... other data
    }
  }
}

This is a reference of the current implemented version and open to discussion.

Update: don't know since when but latest Chrome Canary now enables class fields by default, so we can already play with the following API without a transpiler.

Plain ES usage:

import { h, Component } from '@vue/renderer-dom'

class App extends Component {
  static props = {
    msg: String
  }

  // data
  count = 0

  // lifecycle
  created() {
    console.log(this.count)
  }

  // getters are converted to computed properties
  get plusOne() {
    return this.count + 1
  }
  
  // a method
  increment() {
    this.count++
  }

  render(props) {
    return h('div', [
      h('span', this.count),
      h('span', props.msg,
      h('button', {
        // methods are auto-bound when they are accessed via the render proxy
        onClick: this.increment
      }, 'increment')
    ])
  }
}

TS Usage:

import { h, Component, ComponentWatchOptions } from '@vue/renderer-dom'

interface Props {
  msg: string
}

interface Data {
  count: number
}

class App extends Component<Props, Data> {
  static props = {
    msg: String
  }
  
  // data fields
  count: number = 0

  // ComponentWatchOptions type is only needed if `this` inference
  // is needed inside options, e.g. in watch callbacks
  static watch: ComponentWatchOptions<App> {
    count(value) {
      console.log(value)
    }
  }

  created() {
    console.log(this.count)
  }

  get plusOne() {
    return this.count + 1
  }

  increment() {
    this.count++
  }

  render(props) {
    // ...
  }
}

I'd like to keep the other breaking changes feedback thread scoped to breaking changes. Here's some TypeScript-specific feedback which doesn't need to be addressed immediately, but which stood out to me while exploring the package.

Generic type parameter for props (P) should come before data (D)

This was the biggest footgun I made when I worked on the Vue .d.ts files the first time. I specified Props first rather than Data and I believe that Vue 3.0 shouldn't make the same mistake. When it comes to components, almost all of them will use props and have a harder time specifying them than data.

Generic type parameter P has defaults

There are a lot of instances of P = Data (which is really just P = Record<string, any>). Is there any reason that's necessary? I feel like the class-based API doesn't really need this since, on the whole, it's mostly inferred, though I could be missing something.

Vue is currently non-generic

Vue (from packages/vue) currently has a different API than Component (from packages/core). Specifically, Vue is generic and seems to be the "full-featured" version of the component. You already mentioned that things are in a state of progress, but is the difference mostly about mount points depending on target runtimes (i.e. DOM vs. native vs. ...)?

.d.ts files are produced using dts-bundle

dts-bundle throws all of your modules into a single global file with several ambient module declarations. The problem with ambient module declarations is that they are in the global scope in the first place. If you have multiple versions of Vue loaded up by a project (via a separate dependency probably), then two ambient modules for the path @vue/renderer-dom can conflict, which can cause problems.

Mitigations

We should consider looking into API Extractor to produce .d.ts files that describe top-level APIs for Vue.

Build process could leverage project references.

Right now it appears that there's a custom TypeScript build that happens, and it seems like that's an all-or-nothing approach. Depending on whether build times are an issue, we could potentially leverage project references. If there's a reason you can't use them, it'd be helpful for our team to get an idea of the challenges. 😃

Currently, when component contains only static HTML, createVNode is imported even though it is not needed, additionally _ctx variable is created which is also not used.

https://vue-next-template-explorer.netlify.com/#%7B%22src%22%3A%22%3Cdiv%3Etest%3C%2Fdiv%3E%22%2C%22options%22%3A%7B%22mode%22%3A%22module%22%2C%22prefixIdentifiers%22%3Afalse%2C%22hoistStatic%22%3Afalse%2C%22cacheHandlers%22%3Afalse%2C%22scopeId%22%3Anull%7D%7D

Right now, the pattern that's been called "renderless components" doesn't make complete sense, because technically, those components still need a render function that just returns null:

render: () => null

What are thoughts on removing the need for either a template or render function in components, by default rendering null?

The Problem

Many on the team would like the functions API to become the new recommended way of writing components in Vue 3. And even if we did not officially recommend it as the standard, many users would still gravitate toward it for its organizational and compositional advantages. That means a schism in the community is inevitable with the current API.

I've also been experimenting with how we might document Vue 3 and have been really struggling. I think I finally have to admit that with the current, planned API, making Vue feel as simple and elegant as it does now is simply beyond my abilities.

Proposed solution

I've been experimenting with potential changes to the API, outlining affected examples to create a gentler and more intuitive learning path. My goals are to:

• Make the recommended API feel intuitive and familiar.
• Make changes we're making feel like a logical simplification or extension of our current strategy, rather than a radical change in direction.
• Reduce the feeling of there being two different ways of writing components.
• Reduce the number of concepts users have to learn.
• Reduce the frequency and severity of context switching.

Finally, I think have a potential learning path that is worth attention from the team, though you may want to read my explanations for the proposed API changes before checking it out.

Proposed API changes

1. Rename setup to create

Example

Vue.component('button-counter', {
  props: ['initialCount'],
  create(props) {
    return {
      count: props.initialCount
    }
  },
  template: `
    <button v-on:click="count++">
      You clicked me {{ count }} times.
    </button>
  `
})

Advantages

• Avoid introducing a new concept with setup, since we already have a concept of instance creation with the beforeCreate and created lifecycle functions.

• With create, it's more obvious and easier to remember when in the lifecycle the function is called.

• Since this is first available in created, it will make more intuitive sense that it's not yet available in the create function.

Disadvantages

• Downsides related to autocomplete and confusion with lifecycle functions can be resolved with proposal 2.

2. Rename lifecycle function options to begin with on

Example

new Vue({
  el: '#app',
  onCreated() {
    console.log(`I've been created!`)
  }
})

Advantages

• Removes any confusion or autocomplete conflicts if setup is renamed to create (see proposal 1).

• Removes the only naming inconsistency between the option and function versions of an API. For example, computed and watch correspond to Vue.computed and Vue.watch, but created and mounted correspond to Vue.onCreated and Vue.onMounted.

• Users only have to make the context switch once, when going from Vue 2 to Vue 3, rather than every time they move between options and functions.

• Better intellisense for lifecycle functions, because when users type the on in import { on } from 'vue', they'll see a list of all available lifecycle functions.

Disadvantages

• None that I can see.

3. Consolidate 2.x data/computed/methods into create and allow its value to be an object just like data currently

Example

const app = new Vue({
  el: '#app',
  create: {
    count: 0,
    doubleCount: Vue.computed(() =>
      return app.count * 2
    ),
    incrementCount() {
      app.count++
    }
  }
})

Vue.component('button-counter', {
  props: ['initialCount'],
  create(props) {
    const state = {
      count: props.initialCount,
      countIncrease: Vue.computed(
        () => state.count - props.initialCount
      ),
      incrementCount() {
        state.count++
      }
    }

    return state
  },
  template: `
    <button v-on:click="incrementCount">
      You clicked me {{ count }}
      ({{ initialCount }} + {{ countIncrease }})
      times.
    </button>
  `
})

Advantages

• It's easier for users to remember which options add properties to the instance, since there would only be one: create.

• Users don't need to be more advanced to better organize their properties. This one change provides the vast majority of the organizational benefit, without the complexity that can arise once you get into advanced composition.

• New users won't have to learn methods as a separate concept - they're just functions.

• It's even less code and fewer concepts than the current status quo.

• Prevents the larger rift of people using create vs data/computed/methods, by having everyone start with create from the beginning. With everyone already familiar with and using the create function, sometimes moving more options there for organization purposes (e.g. watch, onMounted, etc) will be a dramatically smaller leap.

• Makes the transition to a create function feel more natural, both for current users ("oh, it's just like data - when it's a function, I just return the object") and new users ("oh, this is just like what I was doing before, except I return the object").

• Although Vue.computed will return a binding, users won't have to worry about learning the concept of bindings for the entirety of Essentials. Only once we get to advanced composition that splits features into reusable functions will it become relevant, because then you have to worry about whether you're passing a value or binding.

Disadvantages

• If users decided to log a computed property (e.g. console.log(state.countIncrease)) inside the create function, they would see an object with a value rather than the value directly. They won't understand exactly why Vue.computed returns this until they're introduced to bindings, but I don't see it as a significant problem because it won't stop them from getting their work done.

• When doing something very strange, like trying to immediately use the setter on a computed property inside create, the abstraction of a binding would leak. However, if we think this is likely to actually happen, I believe it could be resolved by emitting a warning on the setter of bindings, since I believe that's always likely to be a mistake.

  const state = {
    count: 0,
    doubleCount: Vue.computed(
      () => state.count * 2,
      newValue => {
        state.count = newValue / 2
      }
    )
  }
  
  // This will not work, because `doubleCount` has not yet
  // been normalized to a reactive property on `state`.
  state.doubleCount = 2
  
  return state

4. Make context the same exact object as this in other options

Example

Vue.component('button-counter', {
  create(props, context) {
    return {
      map: context.$parent.map
    }
  },
  onCreated() {
    console.log(this.$parent.map)
  },
  template: '...'
})

Vue.component('username-input', {
  create(props, context) {
    return {
      focus() {
        context.$refs.input.focus()
      }
    }
  },
  onMounted() {
    console.log(this.$refs.input)
  },
  template: '...'
})

Advantages

• Avoids a context switch (no pun intended 😄) when moving between options and the create function, because properties are accessed under the same name (e.g. this.$refs/context.$refs instead of this.$refs/context.refs).

• When users/plugins add properties to the prototype or to this in onBeforeCreate, users can rely on those properties being available on the context object in create.

Disadvantages

• Requires extra documentation to help people understand that this === context, and that properties are added/populated at different points in the lifecycle (e.g. props and state added in onCreated, $refs populated in onMounted, etc). We'll probably need a more detailed version of the lifecycle diagram with these details (or whatever the reality ends up being).

• For TypeScript users, every plugin that adds properties to the prototype (e.g. $router, $vuex) would require extending the interface of the Vue instance. I think they probably want to do this already for render functions though, right? Don't they still have access to this?

5. Reconsider staying consistent with object-based syntax in the arguments for the function versions of the API?

This one is more of a question than an argument. We have a lot of inconsistencies between the object-based and function-based APIs. For example, when a computed property takes a setter, it's a second argument:

Vue.computed(
  () => {}, // getter
  () => {} // setter
)

rather than providing an object with get and set, like this:

Vue.computed({
  get() {},
  set() {}
})

It's my understanding that these changes were made for the performance benefits of monomorphism. However, they have some significant disadvantages from a human perspective:

• They force users to learn two versions of every API, rather than being able to mostly copy/paste when refactoring between options and functions, creating more work and making them feel like a significant context switch.

• They create code that's less explicit and less readable, since either intellisense or comments are necessary to provide more information on what these arguments actually do.

As a starting place, could we create some benchmarks from realistic use cases so we can see exactly how much extra performance we're getting from monomorphism? That could make it easier to judge the pros and cons.

Thoughts?

@vuejs/collaborators What does everyone think about these? They include some big changes, but I think they would vastly simplify the experience of learning and using Vue. I'm also very open to alternatives I may have missed!

Since data in components, state in Vuex, and Vue.observable are all used to register observable state objects, I wonder if we should standardize the language we use to reduce the number of concepts people have to learn. My personal preference would be to settle on state, since this is also the word generally preferred in the React and Angular ecosystems, thus easing migration. So the total renames would be:

• data/$data -> state/$state
• Vue.observable -> Vue.state

The obvious downside is the adjustment pain for current users, but I think that could be mostly alleviated by a period of allowing the old names to work as aliases, while emitting a warning if they're actually used.

What problem does this feature solve?

vuejs/vue#7178

It seems like this still needs to be implemented, in v3 because currently it passes slots as component's prop instead of its children.

https://vue-next-template-explorer.netlify.com/#%7B%22src%22%3A%22%3Cchild%20v-bind%3D%5C%22%7B%20slots%3A%20%24slots%20%7D%5C%22%3E%3C%2Fchild%3E%22%2C%22options%22%3A%7B%22mode%22%3A%22module%22%2C%22prefixIdentifiers%22%3Afalse%2C%22hoistStatic%22%3Atrue%2C%22cacheHandlers%22%3Atrue%2C%22scopeId%22%3Anull%7D%7D

What does the proposed API look like?

<child v-bind="{ slots: $slots }"></child>

Version

3.0.0-alpha.1

Reproduction link

(None)

Steps to reproduce

Attempt to compile this template:

<button @click="foo(); bar()">Click</button>

What is expected?

It should compile without any errors or warnings and when the button is clicked it should call the foo and bar functions sequentially.

What is actually happening?

The generated code is invalid.

The following template fragment works in 2.x:

<button @click="foo(); bar()">Click</button>

The click event handler gets compiled into something like this:

click: $event => { foo(); bar() }

But in 3.0.0-alpha.1 the compiled code is this:

click: _cache[0] || (_cache[0] = $event => (foo(); bar()))

which is invalid JS syntax.

It can be fixed on the user's end by:

• Not having code like that in the template and if you need to execute multiple statements it should be extracted into a method.
• Using a comma instead of a semicolon.

What problem does this feature solve?

  const Vue2ReactWrapper = (vueComponentFactory, componentName) => {
    const ReactPage: React.FC = () => {
      const [loading, setLoading] = useState(true);
      const containerRef = useRef(null);
      useEffect(() => {
        let Vue = require('vue');
        Vue = Vue.default || Vue;
        if (containerRef.current) {
          let vueInstance;
          (async () => {
            let vueApp = await vueComponentFactory();
            vueApp = vueApp.default || vueApp;
            const { createApp } = Vue;
            vueInstance = createApp().mount(vueApp, containerRef.current);
            // vueInstance = new Vue({
            //   render: h => h(vueApp),
            // }).$mount(containerRef.current);
            setLoading(false);
          })();
          return () => {
            if(!vueInstance) return;
            if (vueInstance.$destroy) {
              vueInstance.$destroy();
            } else if (vueInstance.sink) {
              vueInstance.sink.renderer.unmount(vueInstance.$root.vnode);
            }
          }
        }
      }, []);
      ReactPage.displayName = componentName;
      return (
        <div>
          <div ref={containerRef} />
          {loading && <span> 页面加载中 </span>}
        </div>
      );
    }
    return ReactPage;
  }

我希望在 React 元素 unmount 时 ，Vue 元素也能够 unmount。
I hope in the React unmount to elements, also able to unmount to Vue elements.

but now vueInstance.$destroy is undefined...

What does the proposed API look like?

vueInstance.$destroy()

release resources，call beforeUnMount、

Observer

• Object
• Array
• Collections
  • Map
  • WeakMap
  • Set
  • WeakSet
• Immutable
• Computed
• Advanced Reactivity API (vuejs/rfcs#22)
  • value
  • state / value.raw?
  • computed
  • watch
  • setup() hook

Core

• Custom Renderer API - createRenderer

• Component

• Portal

• Fragments

• ref

• Directives

• Options

  • props
    • immutable when passed down
    • runtime validation
  • render

• Global API

  • createApp
    • app.config
      • performance
      • devtools
      • errorHandler
      • warnHandler
      • ignoredElements
      • keyCodes
      • optionMergeStrategies
      • productionTip only show in direct browser builds
      • silent deprecated
    • app.use
    • app.mixin (only for legacy mode)
    • app.directive
    • app.component
  • nextTick
  • compile
  • version

• Lifecycle hooks

  • beforeMount
  • mounted
  • beforeUpdate
  • updated
  • beforeUnmount
  • unmounted
  • errorCaptured
  • renderTracked
  • renderTriggered

• Instance properties

  • $data
  • $props
  • $attrs
  • $slots
  • $refs
  • $root
  • $parent
  • $children
  • $options
  • $el

• Instance methods

  • $forceUpdate

Compiler

• parser
  • HTML parser
  • Vue parser
  • AST types
• optimizer
• codegen
  • tree-shaking mode
  • source maps
• Plugin system
• Slots
• <component is="">
• Directives
  • v-if / v-else / v-else-if
  • v-for
  • v-on
  • v-bind
  • v-model
  • v-show
  • v-pre
  • v-cloak
  • v-once
  • v-text
  • v-html
• string ref -> function ref

On demand features

• createAsyncComponent
• <transition>
• <transition-group>
• <keep-alive>
  • activated
  • deactivated
• <await>

SSR

• SSR optimizing compiler
• server-renderer
  • string
  • stream
    • embed state associated with component as inline <script>
  • special handling for Async components
• Client hydration
• $isServer instance property

2.x Compat

• Global config
• Global API
  • Vue.extend
  • Vue.nextTick
  • Vue.use
  • Vue.compile
  • Vue.version
  • Vue.set
  • Vue.delete
  • Vue.component
  • Vue.directive
  • Vue.filter
• Options
  • data
  • methods
  • computed
    • get
    • set
    • chained
  • watch
    • getter
    • dot-delimited path
    • deep
    • sync
    • immediate
  • template
  • functional
  • el
  • propsData
  • parent
  • mixins
  • extends
  • model
  • comments
  • provide/inject
  • renderError
  • inheritAttrs
• Legacy Lifecycle Hooks
  • beforeCreate
  • created
• Instance Properties
  • $scopedSlots
  • $listeners
• Instance methods
  • $watch
  • $nextTick
  • $mount
  • $destroy
  • $on
  • $once
  • $off
  • $emit