compiler-sfc: @vue/compiler-sfc's transformAssetUrlsBase option
has been removed. It is merged into trasnformAssetUrls which now also
accepts the format of
{
base?: string
includeAbsolute?: string
tags?: { [name: string]: string[] }
}
withDirectives as public type (583ba0c)Some watch API types are renamed.
BaseWatchOptions -> WatchOptionsBaseStopHandle -> WatchStopHandledefineComponent assignable to Component type (#1032) (f3a9b51), closes #993ToRefs type (#1037) (28b4c31)ComponentCustomOptions for declaring custom options (c0adb67)ExtractPropTypes (#983) (4cf5e07)ComponentCustomProperties interface (#982) (be21cfb)reactivity: Reactivity APIs adjustments:
readonly is now non-tracking if called on plain objects.
lock and unlock have been removed. A readonly proxy can no
longer be directly mutated. However, it can still wrap an already
reactive object and track changes to the source reactive object.
isReactive now only returns true for proxies created by reactive,
or a readonly proxy that wraps a reactive proxy.
A new utility isProxy is introduced, which returns true for both
reactive or readonly proxies.
markNonReactive has been renamed to markRaw.
on (6eb3399), closes #949markReadonly (e8a866e)customRef API (b83c580)toRef API (486dc18)markReadonly has been removed.on followed by an uppercase
letter or a non-letter character are considered event listeners.runtime-core: this.$emit() and setupContext.emit() no longer
return values. For logic that relies on return value of listeners,
the listener should be declared as an onXXX prop and be called
directly. This still allows the parent component to pass in
a handler using v-on, since v-on:foo internally compiles
to onFoo.
(8c17535), closes #945onError option for defineAsyncComponent (e804463)decodeEntities is added.namedCharacterReferences option has been removed.maxCRNameLength option has been removed.retryWhen and maxRetries options for
defineAsyncComponent has been replaced by the more flexible onError
option, per https://github.com/vuejs/rfcs/pull/148undefined (#894) (94562da), closes #892<portal> to <teleport> (eee5095)createAsyncComponent to defineAsyncComponent (#888) (ebc5873)transformElement from compiler-core (#907) (20f4965)<portal> has been renamed to <teleport>.
target prop is also renamed to to, so the new usage will be:
<Teleport to="#modal-layer" :disabled="isMobile">
<div class="modal">
hello
</div>
</Teleport>
The primary reason for the renaming is to avoid potential naming conflict with native portals.
asyncComponent: async component error and loading options have been
renamed to errorComponent and loadingComponent respectively.
runtime-core: createAsyncComponent has been renamed to defineAsyncComponent for consistency with defineComponent.
config.optionMergeStrategies (528621b)ErrorTypes (#840) (760c3e0)RendererOptions.patchProp arguments order has changedThe prevValue and nextValue position has been swapped to keep it
consistent with other functions in the renderer implementation. This
only affects custom renderers using the createRenderer API.
runtime-core: adjust attr fallthrough behavior
Updated per pending RFC https://github.com/vuejs/rfcs/pull/137
Implicit fallthrough now by default only applies for a whitelist of attributes (class, style, event listeners, a11y attributes, and data attributes).
Fallthrough is now applied regardless of whether the component has
runtime-core: revert setup() result reactive conversion
Revert 6b10f0c & a840e7d. The motivation of the original change was
avoiding unnecessary deep conversions, but that can be achieved by
explicitly marking values non-reactive via markNonReactive.
Removing the reactive conversion behavior leads to an usability
issue in that plain objects containing refs (which is what most
composition functions will return), when exposed as a nested
property from setup(), will not unwrap the refs in templates. This
goes against the "no .value in template" intuition and the only
workaround requires users to manually wrap it again with reactive().
So in this commit we are reverting to the previous behavior where
objects returned from setup() are implicitly wrapped with
reactive() for deep ref unwrapping.
directives: custom directive bindings no longer expose instance
This is a rarely used property that creates extra complexity in ensuring it points to the correct instance. From a design perspective, a custom directive should be scoped to the element and data it is bound to and should not have access to the entire instance in the first place.
6b10f0c (a840e7d), closes #738runtime-core: replace watch(fn, options?) with watchEffect
The watch(fn, options?) signature has been replaced by the new
watchEffect API, which has the same usage and behavior. watch
now only supports the watch(source, cb, options?) signature.
reactivity: reactive arrays no longer unwraps contained refs
When reactive arrays contain refs, especially a mix of refs and plain values, Array prototype methods will fail to function properly - e.g. sort() or reverse() will overwrite the ref's value instead of moving it (see #737).
Ensuring correct behavior for all possible Array methods while retaining the ref unwrapping behavior is exceedingly complicated; In addition, even if Vue handles the built-in methods internally, it would still break when the user attempts to use a 3rd party utility function (e.g. lodash) on a reactive array containing refs.
After this commit, similar to other collection types like Map and Set, Arrays will no longer automatically unwrap contained refs.
The usage of mixed refs and plain values in Arrays should be rare in practice. In cases where this is necessary, the user can create a computed property that performs the unwrapping.
<component> (78c4f32)watch: watch behavior has been adjusted.
watch(source, callback, options?) signature, the
callback now fires lazily by default (consistent with 2.x
behavior).Note that the watch(effect, options?) signature is still eager,
since it must invoke the effect immediately to collect
dependencies.
The lazy option has been replaced by the opposite immediate
option, which defaults to false. (It's ignored when using the
effect signature)
Due to the above changes, the watch option in Options API now
behaves exactly the same as 2.x.
When using the effect signature or { immediate: true }, the
initial execution is now performed synchronously instead of
deferred until the component is mounted. This is necessary for
certain use cases to work properly with async setup() and
Suspense.
The side effect of this is the immediate watcher invocation will
no longer have access to the mounted DOM. However, the watcher can
be initiated inside onMounted to retain previous behavior.
createApp related API signatures (c07751f)setup() are no longer implicitly
passed to reactive().The renderContext is the object returned by setup() (or a new object
if no setup() is present). Before this change, it was implicitly passed
to reactive() for ref unwrapping. But this has the side effect of
unnecessary deep reactive conversion on properties that should not be
made reactive (e.g. computed return values and injected non-reactive
objects), and can lead to performance issues.
This change removes the reactive() call and instead performs a
shallow ref unwrapping at the render proxy level. The breaking part is
when the user returns an object with a plain property from setup(),
e.g. return { count: 0 }, this property will no longer trigger
updates when mutated by a in-template event handler. Instead, explicit
refs are required.
This also means that any objects not explicitly made reactive in
setup() will remain non-reactive. This can be desirable when
exposing heavy external stateful objects on this.
createApp API has been adjusted.
createApp() now accepts the root component, and optionally a props
object to pass to the root component.app.mount() now accepts a single argument (the root container)app.unmount() no longer requires arguments.New behavior looks like the following:
const app = createApp(RootComponent)
app.mount('#app')
app.unmount()
<svg> into blocks for correct runtime isSVG (f2ac28b)<svg> and <foreignObject> mount and updates (4f06eeb)For changes between 2.x and 3.0 up to this release, please refer to merged RFCs here.