for more simple code, sometimes need alias for deep link keys like this
export default {
computed: {
breadcrumb () {
return this.$root.view.breadcrumb.list
}
}
}
I think there should be more convenient way to do this like
export default {
computed: {
breadcrumb: '$root.view.breadcrumb.list'
}
}
before:
export default {
computed: {
breadcrumb () {
return this.$root.view.breadcrumb.list
}
}
}
after:
export default {
computed: {
breadcrumb: '$root.view.breadcrumb.list'
}
}
@yyx990803
I create a pr for this https://github.com/vuejs/vue/pull/6012
and there is the Chinese version description
wish for your suggestion ;)
I feel like rather use the original way, it's more understandable than the string one.
@dsonet
in my opinion,
function(original way u meant) is better for if data need transform
string is more like getter alias.
with vue-class-component
@Component({
computed: {
breadcrumb: '$root.view.breadcrumb.list'
}
})
class Demo extends Vue {
get availableBreadcrumb () {
return this.$root.view.breadcrumb.list.filter(breadcrumb => breadcrumb.status)
}
}
it's more clear, also u can do it better
...
get availableBreadcrumb () {
return this.breadcrumb.filter(breadcrumb => breadcrumb.status)
}
I'd rather prefer if computed properties would get context as argument so you could:
export default {
computed: {
breadcrumb: vm => vm.$root.view.breadcrumb.list
}
}
It doesn't add any magic but makes it shorter.
I like the way proposed by nick and I think it can be added with very little change.
The string syntax is to much magic though
However, what you're trying to do is to create aliases. This could be achieved with a plugin that transforms computed properties or take into account a new alias property. I'll still go for nick's syntax instead of the string one though :)
I like @nickmessing's suggestion.
Also I'm concerning that it makes harder to infer its types statically that deriving a property by using string path.
I like @nickmessing 's idea, but that should be a separate issue/PR (and also need accompanying typing updates, so ideally after we've merged the pending TS typing PR). We are not going to implement string shorthands because of the obvious disadvantages of strings (syntax highlighting, auto completion, type inference, error messages...)
Actually it's able to achieve what @nickmessing proposed now:
export default { computed: { breadcrumb: vm => vm.$root.view.breadcrumb.list } }
@javoski
it's not work for .vue
@nickmessing
nice job, ur is the good way for minimal magic,
but string for computed is just like for watches,
it's alias, I mean it should be a feature but not the only way.
@yyx990803
I'm so sad, wish u think once more for this,
when the app is bigger, for data we really need short alias,
it's just like watches option, maybe can use for setter too.
now we can use vuex to do that,
but $root data is enough in most cases,
and user doesn't need to know vuex concept
@yyx990803
英语词穷我用中文说吧,
先说下我用 vue 的方式以及触发这个需求的场景,
大部分开发 vue 的时候我是不使用 vuex 的,
因为我觉得其实 flux 就是个概念,
重要的是理解它的想法并实践它,
大部分情况下把需要全局处理的数据放到 $root 的 data
import data from '@/store'
new Vue({
...
data,
...
})
因为一个单页应用一般只需要一个根组件,
所以这里 data 没有用 function 而是直接挂载。
store 的话内容大概这样
import storeA from './storeA'
import storeB from './storeB'
export default {
storeA,
storeB
}
// storeA.js
export default {
list: [],
active: {
...
},
...
}
// storeB.js
export default {
list: [],
...
}
在子组件操作的时候就是最开始提到的方式
...
setList () {
this.$root.storeA.active.items = []
}
尤其是随着应用的复杂度的增加会多出很多的一样的代码,
虽然统一设置一个 getter, setter 也可以,
但如果引用的全局状态多的话还是会有很多陈余代码,
我觉的 alias 对于 computed 的意义就和 es6 里的解构一样
能让程序逻辑,或者说代码变得容易理解,对于工作效率会有很大提高
虽然有一定的缺点,比如提到的
syntax highlighting, auto completion, type inference, error messages...
但正如 watch option alias 只是作为一个 options, 并不是 the only one way
所以如果更注重类型推导之类的就继续使用原来的方式就好。
正如 render 方式一样,每种方式都有更适合的场景,
如果能开发的更爽,又不会对现有的方式造成任何影响,
何不让有使用场景的人更爽呢 ;)
希望能再考虑一下;)
最后希望 vue 越来越好用 ;)
That's working on .vue according to my tests.
Anyway, if you really want this feature, you can write your own plugin.
And it may be(not tested):
Vue.mixin({
beforeCreate () {
const computed = this.$options.computed
for (const key in computed) {
const getter = computed[key]
if (typeof getter === 'string') {
computed[key] = parsePath(getter)
}
}
}
})
@javoski
it's not work 😿
Most helpful comment
I like @nickmessing 's idea, but that should be a separate issue/PR (and also need accompanying typing updates, so ideally after we've merged the pending TS typing PR). We are not going to implement string shorthands because of the obvious disadvantages of strings (syntax highlighting, auto completion, type inference, error messages...)