profile
viewpoint
Evan You yyx990803 New Jersey / China http://evanyou.me Creator of @vuejs, previously @meteor & @google

vuejs/vue 157871

🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

vuejs/vetur 4016

Vue tooling for VS Code.

vuejs/vuefire 2731

🔥 Firebase bindings for Vue.js & Vuex

kazupon/vue-validator 2228

:white_check_mark: Validator component for Vue.js

karol-f/vue-custom-element 1469

Vue Custom Element - Web Components' Custom Elements for Vue.js

vuejs/rollup-plugin-vue 609

Roll .vue files

vuejs/vue-jest 428

Jest Vue transformer

TheLarkInn/unity-component-specification 208

This is a WIP draft of the Unity (Single File Web Component) Specification

sdras/vue-hooks-foodapp 178

A food app using a few hooks in Vue to show how they can work (experimental)

vuejs/vue-curated 178

🖼️ The curated Vue packages list

push eventvuejs/vue-next

Evan You

commit sha 3357ff438c6ff0d4fea67923724dd3cb99ff2756

fix(slots): fix conditional slot fix #787

view details

push time in 8 hours

issue closedvuejs/vue-next

Slot drilling error when named slot is missing

Version

3.0.0-alpha.7

Reproduction link

https://codesandbox.io/s/vue-3-slot-drilling-error-92srn

Steps to reproduce

Open the sandbox and check the console

What is expected?

Missing slots skip rendering.

What is actually happening?

Component throws an error and doesn't render any content

TypeError: Cannot read property 'name' of undefined
    at createSlots (https://unpkg.com/vue@3.0.0-alpha.7/dist/vue.global.js:9054:26)
    at Proxy.render (eval at compileToFunction (https://unpkg.com/vue@3.0.0-alpha.7/dist/vue.global.js:10172:24), <anonymous>:15:44)
    at renderComponentRoot (https://unpkg.com/vue@3.0.0-alpha.7/dist/vue.global.js:5056:55)
    at componentEffect (https://unpkg.com/vue@3.0.0-alpha.7/dist/vue.global.js:6891:55)
    at run (https://unpkg.com/vue@3.0.0-alpha.7/dist/vue.global.js:4060:22)
    at reactiveEffect (https://unpkg.com/vue@3.0.0-alpha.7/dist/vue.global.js:4041:18)
    at effect (https://unpkg.com/vue@3.0.0-alpha.7/dist/vue.global.js:4026:11)
    at setupRenderEffect (https://unpkg.com/vue@3.0.0-alpha.7/dist/vue.global.js:6889:29)
    at mountComponent (https://unpkg.com/vue@3.0.0-alpha.7/dist/vue.global.js:6882:11)
    at processComponent (https://unpkg.com/vue@3.0.0-alpha.7/dist/vue.global.js:6808:19)

I realize this might not be a common use case, but the practice of passing slot content to child components is useful for complex library components.

My use case is porting an autocomplete component from the v2 composition-api plugin to v3. One of the slots on the base component, Autocomplete, is named "suggestion", which, if it exists, is handed to the inner AutocompleteList component. It works fine with the v2 plugin but is broken in v3.

This bug also shows up if the fallback content is set for the named slot, which is strange because I would expect that fallback to create the necessary render function.

Offending Code: https://github.com/vuejs/vue-next/blob/master/packages/runtime-core/src/helpers/createSlots.ts#L22

<!-- generated by vue-issues. DO NOT REMOVE -->

closed time in 8 hours

Jexordexan

push eventvuejs/vue-next

Evan You

commit sha 5d952cc051edf3a4cd07e38a022e22819b2a6e50

test: fix options usage of reactive

view details

push time in 8 hours

CommitCommentEvent
CommitCommentEvent

push eventvuejs/vue-next

Evan You

commit sha e67f655b2687042fcc74dc0993581405abed56de

refactor(runtime-core): revert setup() result reactive conversion 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.

view details

push time in 11 hours

issue commentvuejs/vue-next

Reactivity: add and expose a shallow function

@jods fyi: e9024bf

jods4

comment created time in 13 hours

PR closed vuejs/vue-next

fix(build): process.env.KEY should be test as a string
+2 -2

1 comment

1 changed file

djy0

pr closed time in 13 hours

pull request commentvuejs/vue-next

fix(build): process.env.KEY should be test as a string

I don't think this is necessary - all these flags default to false and it is common to do FLAG=1 [some command].

djy0

comment created time in 13 hours

push eventvuejs/vue-next

Evan You

commit sha 439752822c175c737e58896e0f365f2b02bab577

fix(portal): fix portal placeholder text

view details

Evan You

commit sha 11d2fb2594e234bf7f2277194dbd47f5776f9335

refactor(fragments): remove visible anchors for fragments

view details

push time in 13 hours

push eventvuejs/vue-next

Evan You

commit sha d52ffaa20201f9a15861570bc69d3251d89d441b

refactor(compiler-ssr): extract portal processing + emit errors

view details

push time in 15 hours

pull request commentvuejs/vue-next

feat(compiler-ssr): compile portal

Great job!

sh7dm

comment created time in 15 hours

push eventvuejs/vue-next

Dmitry Sharshakov

commit sha d8ed0e7fbf9bbe734667eb94e809235e79e431eb

feat(compiler-ssr): compile portal (#775)

view details

push time in 15 hours

PR merged vuejs/vue-next

Reviewers
feat(compiler-ssr): compile portal

Compile portals & render them using server-renderer helper function.

+116 -17

0 comment

11 changed files

sh7dm

pr closed time in 15 hours

release vuejs/vue-next

v3.0.0-alpha.7

released time in 15 hours

release vuejs/vue-next

v3.0.0-alpha.6

released time in 15 hours

push eventvuejs/vue-next

Evan You

commit sha 312513d255332923a81a99ab24e5d40f6feb46c7

release: v3.0.0-alpha.7

view details

push time in 15 hours

created tagvuejs/vue-next

tagv3.0.0-alpha.7

The next major version of Vue (WIP)

created time in 15 hours

push eventvuejs/vuejs.org

Evan You

commit sha 3334e5926ea462ba76610e21ed6e4cc5507de579

Update Monterail description and link

view details

push time in 15 hours

push eventvuejs/vue-next

Evan You

commit sha e42d6b0712af3c4aca407239b0aa31011aa92d82

refactor: use consistent name for watch invalidation register function

view details

push time in 15 hours

PR closed vuejs/vue-next

chore(runtime-core/apiWatch): simplify code
+3 -5

1 comment

1 changed file

djy0

pr closed time in 19 hours

pull request commentvuejs/vue-next

chore(runtime-core/apiWatch): simplify code

I think a dedicated object here is technically safer, since EMPTY_OBJ is indeed used elsewhere and has a slight chance to be returned in a watcher getter. I know it is highly unlikely, but if it does happen it can be very hard to figure out why.

djy0

comment created time in 19 hours

push eventvuejs/vuejs.org

Evan You

commit sha ad6b6e233d34e8a2903d835aaa786ddb1e77a83e

update security link

view details

push time in 19 hours

push eventvuejs/vue-next

djy0

commit sha 04f83fa6810e07915e98b94c954ff0c1859aaa49

fix(runtime-core): set appContext.provides to Object.create(null) (#781)

view details

push time in 19 hours

issue closedvuejs/vue-next

Lose reactivity in slot

Version

3.0.0-alpha.5

Reproduction link

https://github.com/vankop/vue3-reactivity

Steps to reproduce

run example with yarn run dev. Clicking on tags change state in input but does not apply 'selected' state on tag.

If remove div on https://github.com/vankop/vue3-reactivity/blob/master/src/Profile.vue#L3 :

<template>
	<panel>
			<tag
				v-for="tag in $props.tags"
				:key="tag"
				:text="tag"
				:selected="$props.selectedTags.has(tag)"
				@click="$emit('click', tag)"
			/>
	</panel>
</template>

All works fine..

What is expected?

expect reactivity works properly

What is actually happening?

reactivity lost

<!-- generated by vue-issues. DO NOT REMOVE -->

closed time in 19 hours

vankop

issue commentvuejs/vue-next

Lose reactivity in slot

This has been fixed by 8cb0b83

vankop

comment created time in 19 hours

push eventvuejs/composition-api-rfc

Benoît Burgener

commit sha 8ff2eebb37b5006e03a4b750f51800ae5f0c6ed4

Fix broken link to Global API change RFC (#18)

view details

push time in 19 hours

push eventvuejs/vue-next

djy0

commit sha 59393dd75766720330cb69e22086c97a392dbbe4

fix(template-explorer): rename watch -> watchEffect (#780)

view details

push time in 19 hours

push eventvuejs/vue-next

Praveen Puglia

commit sha 1855a7f4099725b2fba3f1dd5d7366460009fc01

chore: fixes a small typo and prettifies the document (#778)

view details

push time in 20 hours

PR merged vuejs/vue-next

docs(typo): fixes a small typo and prettifies the document

Formatted the document using prettier and got some whitespace changes. Please let me know if I should avoid that.

+17 -11

0 comment

1 changed file

praveenpuglia

pr closed time in 20 hours

issue closedvuejs/vue-next-webpack-preview

[Question] How to enable runtime template compilation

Vue warn]: Component provides template but the build of Vue you are running does not support runtime template compilation. Either use the full build or pre-compile the template using Vue CLI.

What is the best way to enable runtime template compilation? So that components can be registered at runtime using app.component('name',{})

I have tried editing webpack.config.js , changing the alias to 'vue': 'vue/dist/vue.esm.js', but to no effect.

closed time in 20 hours

RobinHavre

issue commentvuejs/vue-next-webpack-preview

[Question] How to enable runtime template compilation

In that case you need to configure your bundler alias so that vue points to the correct dist file (node_modules/vue/dist/vue.esm-bundler.js)

RobinHavre

comment created time in 20 hours

push eventvuejs/rfcs

Evan You

commit sha bbcc027a7e3b1df7bdfe647ca40437eeff2f92a3

Update Composition API: separate `watchEffect` and `watch`

view details

push time in a day

push eventvuejs/composition-api-rfc

Evan You

commit sha bea969873514273c07f969ae344d241869d41ce8

add note about ref unwrapping only applying to objects

view details

Evan You

commit sha 06699647b3786714564a6b9493bbf3fb7b1a8979

separate watchEffect and watch

view details

push time in a day

push eventvuejs/vue-next

Evan You

commit sha 9aaeeede624f3988a1d2f4a4d833d664caaa793b

test: add type test for nested refs in ref.value

view details

Evan You

commit sha 3206e5dfe58fd0e93644d13929558d71c5171888

fix(types): shallowRef should not unwrap value type

view details

push time in a day

issue commentvuejs/vue-next

Refs were broken between alpha.4 and alpha.5

It's been fixed in 3eab143

jods4

comment created time in a day

issue commentvuejs/vue-next

Type-unsafe behavior of watch

That's a good catch. I think ref value unwrapping should happen in its creation signature - see d4c6957

clemyan

comment created time in a day

push eventvuejs/vue-next

Evan You

commit sha 711d16cc65451301e839952e89819e799a4474ff

refactor: remove old watch signature support

view details

Evan You

commit sha d4c6957e2d8ac7920a649f3a3576689cd5e1099f

fix(types): ref value type unwrapping should happen at creation time

view details

push time in a day

push eventvuejs/vue-next

Evan You

commit sha 52cc7e823148289b3dcdcb6b521984ab815fce79

refactor(directives): remove binding.instance BREAKING CHANGE: 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.

view details

push time in a day

push eventvuejs/vue-next

Evan You

commit sha 3eab1438432a3bab15ccf2f6092fc3e4355f3cdd

fix(template-ref): fix string template refs inside slots

view details

Evan You

commit sha c73ec130d03be6b48930962cb1e9b4073051691b

fix(directives): ensure correct directive binding.instance in slots

view details

push time in a day

issue commentvuejs/vue-next

When Importing vue-next with rollup inner components do not mount

Your root instance is still using in-DOM template (in index.html) which requires runtime compilation.

DonNicoJs

comment created time in 2 days

issue closedvuejs/vue-next

When Importing vue-next with rollup inner components do not mount

Version

3.0.0-alpha.6

Reproduction link

https://github.com/vue-leaflet/vue-leaflet/blob/rollup-bug/src/main.js

Steps to reproduce

  • npm install
  • npm run dev
  • open localhost:5000
  • main app onMounted is executed
  • foo markup is missing and onMounted is not executed

What is expected?

Both main app and child components are rendered

What is actually happening?

The child component is not rendered, both by using a template string or a render function


I've prepared another branch where by using vue-next from cdn directly in the html everything works as expected: https://github.com/vue-leaflet/vue-leaflet/blob/rollup-global/src/main.js

Since this bug, I've migrated the whole repo to use the webpack-vue-next-starter template and with SFC everything works as expected.

As a side note, I've tried to import all the version of present in dist/vue/ thinking that I was lacking the live template compiler, but then I noticed that the issue is the same with render functions

Apologize for the messy repo, I've tried to reproduce on codesanbox but It keeps failing to load vue-next.

<!-- generated by vue-issues. DO NOT REMOVE -->

closed time in 2 days

DonNicoJs

issue commentvuejs/vue-next

When Importing vue-next with rollup inner components do not mount

See https://github.com/vuejs/vue-next/tree/master/packages/vue#which-dist-file-to-use

The default build used with a bundler is the runtime-only build so it doesn't support on-the-fly compilation.

Also you probably want to wait until rollup-plugin-vue support vue-next.

DonNicoJs

comment created time in 2 days

issue commentvuejs/vue-next-webpack-preview

[Question] How to enable runtime template compilation

You don't need runtime compilation to register global components:

import Foo from './Foo.vue'

app.component('name', Foo)

The only reason you want to have runtime template compilation is when you have no way but to inline your template a JavaScript strings, or you need to write your templates directly in the DOM. Enabling runtime compilation has performance costs.

RobinHavre

comment created time in 2 days

issue commentvuejs/vue-next

Refs were broken between alpha.4 and alpha.5

I think it never worked inside slots - that's a separate issue though. For now you can use a function ref to get around that:

<v-comp>
  <div :ref="el => (y = el)"></div>
</v-comp>
jods4

comment created time in 2 days

push eventvuejs/composition-api-rfc

Dylan Swanson

commit sha 1115ecb70d6fea554ffc295b6bc4d22966409b82

chore: typo (#15)

view details

push time in 2 days

PR merged vuejs/composition-api-rfc

Fix typo
+1 -1

0 comment

1 changed file

zenkers

pr closed time in 2 days

push eventvuejs/composition-api-rfc

Clement Yan

commit sha 5bf44886c9776215605e4cfa20fb7e39d0aaaf94

Pin links to vue-cli to current commit (#5)

view details

push time in 2 days

PR merged vuejs/composition-api-rfc

Pin links to vue-cli to current commit

The links to the vue-cli repo should be permalinks to the current commit instead of tracking the dev branch.

+3 -3

0 comment

1 changed file

clemyan

pr closed time in 2 days

push eventvuejs/composition-api-rfc

Dave Honneffer

commit sha 1a97eb889f29b21b5b18edc35cd8b8a9eb46e7b8

docs: add warning about props destructure losing reactivity (#16)

view details

push time in 2 days

PR merged vuejs/composition-api-rfc

docs: add warning about props destructure losing reactivity

In reference to this issue in the Vue 2.x plugin.

Is it possible to instead wrap props in toRefs so destructuring is possible? If not, it might be worthwhile to have a note here explaining the rationale (as is done elsewhere in the docs).

+15 -0

0 comment

1 changed file

pearofducks

pr closed time in 2 days

push eventvuejs/vue-next

ysj16

commit sha 8cb0b8308801159177ec16ab5a3e23672c4c1d00

fix(renderSlot): set slot render as a STABLE_FRAGMENT (#776) fix #766

view details

push time in 2 days

issue closedvuejs/vue-next

Bindings are broken on <tr> inside <slot>

Version

3.0.0-alpha.6

Reproduction link

https://codesandbox.io/s/v-model-decomposed-camel-case-d9blu

Steps to reproduce

Open the repro, click on toggle.

What is expected?

All v-if should hide.

What is actually happening?

v-if on <tr> inside <slot> stays visible.


This seems like a bad bug but there's no apparent logic. v-if does work on a div inside the slot, for example.

<!-- generated by vue-issues. DO NOT REMOVE -->

closed time in 2 days

jods4

PR merged vuejs/vue-next

fix(renderSlot): set slot render as a STABLE_FRAGMENT (fix #766)

there is some error when processFragment sub-component's slot fragment. I have some confusion about STABLE_FRAGMENT, I wonder if I can set the slot render return a STABLE_FRAGMENT VNODE

+1 -1

2 comments

1 changed file

ysj16

pr closed time in 2 days

pull request commentvuejs/vue-next

fix(renderSlot): set slot render as a STABLE_FRAGMENT (fix #766)

Oh nvm, I see you are referencing #766

ysj16

comment created time in 2 days

push eventvuejs/composition-api

Evan You

commit sha bde4d1b1900c98e13d7ec3e555425e19afc1b3f1

Update README.md

view details

push time in 2 days

issue commentvuejs/vue-next

Refs were broken between alpha.4 and alpha.5

@jods4 setup() + all lifecycle hooks.

jods4

comment created time in 2 days

pull request commentvuejs/vue-next

fix(renderSlot): set slot render as a STABLE_FRAGMENT (fix #766)

I think this is a good patch - just curious what specific error did you run into that led you to look into this? It'd be nice to have a reproduction to ensure we are not overlooking the original issue.

ysj16

comment created time in 2 days

push eventvuejs/vue-next

Evan You

commit sha 4a5b91bd1faec76bbaa0522b095f4a07ca88a9e5

fix(runtime-core): fix slot fallback + slots typing fix #773

view details

push time in 2 days

issue closedvuejs/vue-next

Missing named slots throw error

Version

3.0.0-alpha.6

Reproduction link

https://codesandbox.io/s/vue-3-named-slot-error-wovpr

Steps to reproduce

Open sandbox, check console.

What is expected?

Named slots skip render if content is missing.

What is actually happening?

Component doesn't render at all, and throws error.

Offending code: https://github.com/vuejs/vue-next/blob/19a799c28b149b14e85d9e2081fa65ed58d108ba/packages/runtime-core/src/helpers/renderSlot.ts#L23


Stacktrace:

TypeError: Cannot read property 'length' of undefined
    at renderSlot (vue.global.js:9011)
    at Proxy.render (eval at compileToFunction (vue.global.js:10150), <anonymous>:11:7)
    at renderComponentRoot (vue.global.js:5027)
    at componentEffect (vue.global.js:6869)
    at run (vue.global.js:4031)
    at reactiveEffect (vue.global.js:4012)
    at effect (vue.global.js:3997)
    at setupRenderEffect (vue.global.js:6867)
    at mountComponent (vue.global.js:6860)
    at processComponent (vue.global.js:6786)

<!-- generated by vue-issues. DO NOT REMOVE -->

closed time in 2 days

Jexordexan

issue commentvuejs/vue-next

Missing named slots throw error

Oh I linked the wrong issue in that commit (it was meant to fix this one)

Jexordexan

comment created time in 2 days

issue commentvuejs/vue-next

Refs were broken between alpha.4 and alpha.5

watch behavior has also changed! (See the last item here)

Eager watchers now fire synchronously (this is necessary to make them work inside Suspense trees and for server rendering). To make the initial run be able to access template refs, wrap them in onMounted:

onMounted(() => {
  watchEffect(() => {
    // can access DOM now
  })
})
jods4

comment created time in 2 days

push eventvuejs/vue-next

Evan You

commit sha 3375687df5e7751d3df69190c99f4ce13b8f1993

fix(runtime-core): fix slot fallback + slots typing fix #772

view details

push time in 2 days

issue closedvuejs/vue-next

Refs were broken between alpha.4 and alpha.5

Version

3.0.0-alpha.6

Reproduction link

https://codesandbox.io/s/v-model-decomposed-camel-case-s05q5

Steps to reproduce

Just open the repro, nothing to do.

What is expected?

Ref should be set to DOM element (-> Page says Ref works).

What is actually happening?

Ref stays null (-> Page says Ref doesn't work).


This a regression that happened between alpha.4 and alpha.5, as can be seen by changing the script source in repro.

<!-- generated by vue-issues. DO NOT REMOVE -->

closed time in 2 days

jods4

issue commentvuejs/vue-next

Refs were broken between alpha.4 and alpha.5

Do note in alpha.4 it leads to an infinite loop warning. This is because the ref was referenced as a dependency for the render and mutated (from null to the element) in the same render cycle.

The fact that a template ref is null during the first render is the expected and correct behavior. To ensure access to the ref you need to do it in onMounted, and it is never recommended to access a template ref in the same template. There's no way for a template ref to be available before it is even rendered.

jods4

comment created time in 2 days

CommitCommentEvent

delete branch vuejs/vue-next

delete branch : gh-actions

delete time in 3 days

push eventvuejs/vue-next

djy0

commit sha 19a799c28b149b14e85d9e2081fa65ed58d108ba

fix(runtime-core): make watchEffect ignore deep option (#765)

view details

push time in 3 days

PR merged vuejs/vue-next

fix(runtime-core): make watchEffect ignore deep option

Make watchEffect behavior not affected by deep option when the callback function returns a nested Reactive or Ref.

+21 -3

0 comment

2 changed files

djy0

pr closed time in 3 days

PR closed vuejs/vue-next

chore: fix typo
+1 -1

1 comment

1 changed file

syuilo

pr closed time in 3 days

pull request commentvuejs/vue-next

chore: fix typo

Thanks, this covered by #764 which includes more fixes.

syuilo

comment created time in 3 days

push eventvuejs/vue-next

djy0

commit sha c11905fe36adbcbb58c4fc02144e81ccdfaceda6

chore: fix typo (#764) [ci skip]

view details

push time in 3 days

PR merged vuejs/vue-next

chore: fix typo
+8 -9

0 comment

4 changed files

djy0

pr closed time in 3 days

PR closed vuejs/vue-next

Reviewers
chore(ci): add github actions workflow
+96 -0

1 comment

1 changed file

clarkdo

pr closed time in 3 days

pull request commentvuejs/vue-next

chore(ci): add github actions workflow

Thanks, I tested this vs. current CircleCI setup and the CircleCI version is still a bit faster.

clarkdo

comment created time in 3 days

push eventvuejs/vue-next

Evan You

commit sha b75300f02ebd862356bfac0a7b897c5a06bb1e8e

chore: fix

view details

push time in 3 days

push eventvuejs/vue-next

Evan You

commit sha cd77d4307ca03221087f668b001a6245105e178c

ci: test setup

view details

push time in 3 days

create barnchvuejs/vue-next

branch : gh-actions

created branch time in 3 days

push eventvuejs/vue-next

Xin Du (Clark)

commit sha 047844cfb87e72ade2c80fbb1f3354ebcce477d5

refactor(ssr): extract buffer resolving and resolvePortals (#771)

view details

push time in 3 days

PR merged vuejs/vue-next

Reviewers
refactor(ssr): extract buffer resolving and resolvePortals

Non-functionality code structure change, extract buffer and portal related code.

+29 -29

0 comment

1 changed file

clarkdo

pr closed time in 3 days

issue closedvuejs/vue-next

Set patch-flags dynamically to vnode

What problem does this feature solve?

The compiler-core sets the patch-flags for optimization when using the template syntax of Vue.js, but when using the rendering function directly or jsx, patch-flags are not set and used.

What does the proposed API look like?

For better performance, what do you think about setting patch-flags when mounting or first patching an element if patch-flag is not set?

<!-- generated by vue-issues. DO NOT REMOVE -->

closed time in 4 days

hareku

issue commentvuejs/vue-next

Set patch-flags dynamically to vnode

The patch flags can only be analyzed via static analysis at compile time.

hareku

comment created time in 4 days

push eventvuejs/vue-next

Evan You

commit sha 20afd4093df48891cd7372eb5487bc95d833b213

chore: changelog edits [ci skip]

view details

push time in 5 days

push eventvuejs/vue-next

Evan You

commit sha 9ab22c7ae66f6bbdbfb7d7d25deb3eee24e753bb

release: v3.0.0-alpha.6

view details

push time in 5 days

created tagvuejs/vue-next

tagv3.0.0-alpha.6

The next major version of Vue (WIP)

created time in 5 days

push eventvuejs/vue-next

Evan You

commit sha 99a2e18c9711d3d1f79f8c9c59212880efd058b9

feat(runtime-core): add watchEffect API BREAKING CHANGE: replae `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?)` signautre.

view details

push time in 5 days

push eventvuejs/vue-next

Evan You

commit sha 610699c34d7b970663bfdcda2c6d49098f894161

test: fix tests for watch -> effect

view details

push time in 5 days

push eventvuejs/vue-next

Evan You

commit sha 37a202b2af4f83b11afe963c60ab32abc6313742

feat(runtime-core): expose effect API BREAKING CHANGE: replae `watch(fn, options?)` with `effect` The `watch(fn, options?)` signature has been replaced by the new `effect` API, which has the same usage and behavior. `watch` now only supports the `watch(source, cb, options?)` signautre.

view details

push time in 5 days

PR closed vuejs/vue-next

fix(effect): optimize effect trigger

fix(effect): optimize effect trigger

+12 -4

1 comment

2 changed files

guaijie

pr closed time in 5 days

pull request commentvuejs/vue-next

fix(effect): optimize effect trigger

Duplicate of #761

guaijie

comment created time in 5 days

issue closedvuejs/vue-next

test cases

What problem does this feature solve?

Can execute code line by line while debugging test cases

I tried to debug the code using the test cases in vue-next, but I found that the code was not debugged line by line, and some of the source code was skipped. For example, the function isReactive (obj) is skipped during debugging

GIF

<!-- generated by vue-issues. DO NOT REMOVE -->

closed time in 5 days

guaijie

issue commentvuejs/vue-next

test cases

This is not a valid feature request.

guaijie

comment created time in 5 days

issue closedvuejs/vue-next

Stable mutation of reactive arrays containing refs

What problem does this feature solve?

Any mutation in a reactive array that changes the position of a ref does not work as expected. Instead of moving the entire ref object only the values are moved.

For example, if we start with this array:

{
  1,
  2,
  // Representing a ref object
  { value: 3 }
}

Calling reverse on this object will swap the values, but leave the ref wrapper at index 2:

{
  3,
  2,
  // Representing a ref object
  { value: 1 }
}

The solution is to first use toRaw to get the underlying object. This doesn't seem like a great user experience, and it isn't obvious at all that this is the solution. Documenting it as a best practice could work, but I don't think it would be that difficult to do this automatically for the user.

If we add all (or most?) Array methods that cause a mutation to this base handler I think we can avoid this issue altogether. (Although it appears that toRaw might be a lot slower?)

I put together a live demo as well: https://codesandbox.io/s/recursing-wood-2ovm5

I ran into this issue after only a couple hours playing with Vue 3, so that makes me think this is a common enough use case to justify fixing.

What does the proposed API look like?

Currently: toRaw(list).reverse()

Proposed: list.reverse()

I would want to go through all Array methods and determine which would need to be included, as well as writing extensive tests for each. It's possible to just use the raw array for all Array methods, but I'm not sure that's all that helpful.

I've only spent a couple hours in this codebase so I'm not sure if there are other implications that a change like this could cause.

Before moving forward with this I wanted to confirm that this is a good direction to move in. I feel this is pretty in keeping with Vue's spirit of making things as simple as possible.

<!-- generated by vue-issues. DO NOT REMOVE -->

closed time in 5 days

tesla3327

issue commentvuejs/vue-next

Stable mutation of reactive arrays containing refs

Arrays will no longer unwrap refs after 775a7c2

tesla3327

comment created time in 5 days

push eventvuejs/vue-next

Evan You

commit sha b36a76fe2382ebd0faff293387a1799c8eb0d11a

chore: remove debugger [ci skip]

view details

push time in 5 days

PR closed vuejs/vue-next

arrayIdentityInstrumentations should trigger effect

arrayIdentityInstrumentations is unreasonable, changed array could change index.

+17 -4

1 comment

2 changed files

guaijie

pr closed time in 5 days

pull request commentvuejs/vue-next

arrayIdentityInstrumentations should trigger effect

See 775a7c2

guaijie

comment created time in 5 days

more