WeakSets and WeakMaps shows degrading performance as the amount of
observed objects increases. Using hidden keys result in better
performance especially when repeatedly creating large amounts of
reactive proxies.
This also makes it possible to more efficiently declare non-reactive
objects in userland.
Note the behavior is different from Vue 2:
- merge strategies no longer apply to built-in options.
- the default value is now an empty object and no longer exposes merge
strategies for built-in options.
BREAKING CHANGE: 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.
reference: https://github.com/vuejs/rfcs/issues/121
BREAKING CHANGE: object returned from `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`.
