New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Custom class with getters and setters as data in VM #2718

Closed
nervgh opened this Issue Apr 24, 2016 · 9 comments

Comments

Projects
None yet
6 participants
@nervgh
Contributor

nervgh commented Apr 24, 2016

Hi

I try to use my own class as data in VM with getters and setters but it does not works. It is correct behavior?

Example https://jsfiddle.net/okv0rgrk/3019/

Thanks.

@jonagoldman

This comment has been minimized.

Show comment
Hide comment
@jonagoldman

jonagoldman Apr 24, 2016

data must be a plain object, you are giving it a class. its explained here in the docs. recommended reading.

jonagoldman commented Apr 24, 2016

data must be a plain object, you are giving it a class. its explained here in the docs. recommended reading.

@yyx990803

This comment has been minimized.

Show comment
Hide comment
@yyx990803

yyx990803 Apr 24, 2016

Member

All prototype methods are ignored. Using non-plain objects as state is a rabbit hole to complexity and it is not supported by design.

Member

yyx990803 commented Apr 24, 2016

All prototype methods are ignored. Using non-plain objects as state is a rabbit hole to complexity and it is not supported by design.

@yyx990803 yyx990803 closed this Apr 24, 2016

@nervgh

This comment has been minimized.

Show comment
Hide comment
@nervgh

nervgh Apr 24, 2016

Contributor

@jonagoldman , thanks, I read that
@yyx990803 , thanks

I has asked this question, because this example works fine.

Summary:

  • not works
<input v-model="symbol" type="checkbox" />
<input v-model="test" type="checkbox" />
new Vue({
    el: '#app',
    data: obj
})
  • works
<input v-model="bar.symbol" type="checkbox" />
<input v-model="bar.test" type="checkbox" />
new Vue({
    el: '#app',
    data: {
        bar: obj
    }
})
Contributor

nervgh commented Apr 24, 2016

@jonagoldman , thanks, I read that
@yyx990803 , thanks

I has asked this question, because this example works fine.

Summary:

  • not works
<input v-model="symbol" type="checkbox" />
<input v-model="test" type="checkbox" />
new Vue({
    el: '#app',
    data: obj
})
  • works
<input v-model="bar.symbol" type="checkbox" />
<input v-model="bar.test" type="checkbox" />
new Vue({
    el: '#app',
    data: {
        bar: obj
    }
})
@yyx990803

This comment has been minimized.

Show comment
Hide comment
@yyx990803

yyx990803 Apr 24, 2016

Member

you will see that the getter is not reactive.

Member

yyx990803 commented Apr 24, 2016

you will see that the getter is not reactive.

@nervgh

This comment has been minimized.

Show comment
Hide comment
@nervgh

nervgh Apr 24, 2016

Contributor

hmm, exactly 😢

Contributor

nervgh commented Apr 24, 2016

hmm, exactly 😢

@milaniliev

This comment has been minimized.

Show comment
Hide comment
@milaniliev

milaniliev Jan 12, 2018

Sorry to revive an old issue - I couldn't find any relevant discussion of this elsewhere.
@yyx990803, I encounter this problem when trying to separate my presentation logic (in the Vue VM) from the client-side business rules and persistence code (in a model). Having my model be a class instance is pretty natural.

Does the fact a VM's data attributes not support class instances mean a Vue VM instance is intended to contain presentation, business and persistence logic? Or is there some other pattern I haven't considered?

Thanks for creating a reactive view library that can be used progressively instead of taking over your app, by the way.

milaniliev commented Jan 12, 2018

Sorry to revive an old issue - I couldn't find any relevant discussion of this elsewhere.
@yyx990803, I encounter this problem when trying to separate my presentation logic (in the Vue VM) from the client-side business rules and persistence code (in a model). Having my model be a class instance is pretty natural.

Does the fact a VM's data attributes not support class instances mean a Vue VM instance is intended to contain presentation, business and persistence logic? Or is there some other pattern I haven't considered?

Thanks for creating a reactive view library that can be used progressively instead of taking over your app, by the way.

@manast

This comment has been minimized.

Show comment
Hide comment
@manast

manast Apr 5, 2018

hmm, interesting to read about this limitation. For me, a class with custom getters is equivalent to computed properties in Vue, the only difference is that I handle the computed properties somewhere else. I agree this can increase side effects and add complex edge cases, but that could be left to the user, after all, Vue is supposed to be un-opinionated, but by making this somewhat artificial limitation it is in fact imposing an opinion which in some cases it is not trivial to work around.

manast commented Apr 5, 2018

hmm, interesting to read about this limitation. For me, a class with custom getters is equivalent to computed properties in Vue, the only difference is that I handle the computed properties somewhere else. I agree this can increase side effects and add complex edge cases, but that could be left to the user, after all, Vue is supposed to be un-opinionated, but by making this somewhat artificial limitation it is in fact imposing an opinion which in some cases it is not trivial to work around.

@sirlancelot

This comment has been minimized.

Show comment
Hide comment
@sirlancelot

sirlancelot Apr 6, 2018

Contributor

This works fine for me. It just can't be the root data object. Plus you will want to store the original reference to your class instance object. Vue will call the getters and setters every time.

Contributor

sirlancelot commented Apr 6, 2018

This works fine for me. It just can't be the root data object. Plus you will want to store the original reference to your class instance object. Vue will call the getters and setters every time.

@manast

This comment has been minimized.

Show comment
Hide comment
@manast

manast Apr 6, 2018

yeah, reactivity is tricky, probably better to have a limitation than a more complex codebase. Despite inconveniences there are always workarounds, so I take back my previous comment :).

manast commented Apr 6, 2018

yeah, reactivity is tricky, probably better to have a limitation than a more complex codebase. Despite inconveniences there are always workarounds, so I take back my previous comment :).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment