Mobx: What's difference between @computed decorator and getter function

Created on 15 Mar 2016  ·  10Comments  ·  Source: mobxjs/mobx

I'm not sure when should i use the @computed decorator (without asStructure option) in class instead of the getter function for example

class Test {
    @observable firstName = 'first'
    @observable lastName = 'last'

    @computed
    get fullName () {
        return `${this.firstName} ${this.lastName}`
    }

    getFullName () {
        return `${this.firstName} ${this.lastName}`
    }
}

const test = new Test()
autorun(() => {
    console.log('computed:', test.fullName)
})

autorun(() => {
    console.log('getter:', test.getFullName())
})

test.firstName = 'salmon'
test.lastName = 'sushi'

// computed: first last
// getter: first last
// computed: salmon last
// getter: salmon last
// computed: salmon sushi
// getter: salmon sushi

Thanks

❔ question

Most helpful comment

Both solutions will exhibit the same behavior, but introducing @computed is better in the sense that it allows MobX to optimized it away more smartly.

If getFullName is not computed, and you change firstName, everyone using getFullName will recompute as well.

If, in contrast, @computed get fullName is used, the fullname is cached, so if the firstname is changed, the fullname is recomputed as well, but if the _output_ of fullname doesn't change, nobody would be notified.

Also, if you read test.fullName somwhere, you will (usually) get a cached result back if decorated, while without decorator it would always be recomputed (which is the normal function behavior after all)

So, when in doubt, use it (if your function is pure in terms of depending only on observable values, which it should be)

All 10 comments

From the docs

use @computed if you want to reactively produce a new value that can be used by other observers

...

Computed properties can be optimized away in many cases by MobX as they are assumed to be pure. So they will not be invoked when there input parameters didn't modifiy or if they are not observed by some other computed value or autorun.

So if you're going to observe it, make it a computed property.

What I think is firstName and lastName is being observed in both computed and getter function. At first I thought the use case is for optimize as the docs said that the computed properties will not invoked when there input parameters didn't modify.

class Test {
    @observable firstName = 'first'
    @observable lastName = 'last'

    @computed
    get fullName () {
        return `${this.firstName} ${this.lastName}`
    }

    getFullName () {
        return `${this.firstName} ${this.lastName}`
    }
}

const test = new Test()
autorun(() => {
    console.log('computed:', test.fullName)
})

autorun(() => {
    console.log('getter:', test.getFullName())
})

test.firstName = 'salmon'
test.lastName = 'sushi'

test.firstName = 'salmon' // <---- again

// computed: first last
// getter: first last
// computed: salmon last
// getter: salmon last
// computed: salmon sushi
// getter: salmon sushi

But after I tried, the getter function didn't print duplicate fullName when I assign the firstName "salmon" again.

Thanks.

Both solutions will exhibit the same behavior, but introducing @computed is better in the sense that it allows MobX to optimized it away more smartly.

If getFullName is not computed, and you change firstName, everyone using getFullName will recompute as well.

If, in contrast, @computed get fullName is used, the fullname is cached, so if the firstname is changed, the fullname is recomputed as well, but if the _output_ of fullname doesn't change, nobody would be notified.

Also, if you read test.fullName somwhere, you will (usually) get a cached result back if decorated, while without decorator it would always be recomputed (which is the normal function behavior after all)

So, when in doubt, use it (if your function is pure in terms of depending only on observable values, which it should be)

Got it! thank you very much :)

@mweststrate so it seems there is not much difference between using a computed decorator and a simple getter? (besides optimization?)

Correct. But the optimization can be huge ;-). And computed protects
against common errors like modifying state and such, and clearly signal to
the reader this is derived data.

Op wo 26 jul. 2017 om 00:07 schreef Giorgi Moniava <[email protected]

:

@mweststrate https://github.com/mweststrate so it seems there is not
much difference between using a computed decorator and a simple getter?
(besides optimization?)


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/mobxjs/mobx/issues/161#issuecomment-317887390, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABvGhF4dSxYS_IZCtgY_6DjixFY-kJTnks5sRmcsgaJpZM4Hw0Ta
.

nobody would be notified.

Who can be notified? I tried hard, and every time I get not a cached value. So I confused :)

@mweststrate

@mweststrate

Also, if you read test.fullName somwhere, you will (usually) get a cached result back if decorated, while without decorator it would always be recomputed (which is the normal function behavior after all)

When would I get a cached result instead of getting the function recomputed? I tried the following example and it recomputes.

const {observable, computed} = mobx;

class Test {
    @observable firstName = 'first'
    @observable lastName = 'last'

    @computed
    get fullName () {
        console.log('recompute fullname');
        return `${this.firstName} ${this.lastName}`
    }
}

let test = new Test()

console.log(test.fullName);
//recompute fullname
//first last

console.log(test.fullName);
//recompute fullname
//first last

@windwalker I was confused by that too, but it seems values are cached when used inside a reaction, autorun or in the render of an observable React component.

Something like https://jsbin.com/rujuxe/edit?js,console,output you can see that the computed values are only called once even when we show then twice.

Also the value will be reevaluated if called directly. (check the click handler of the button)

@mweststrate are there any plans to also return a cached value from the normal usages outside of autorun, reaction and render?

No, that would kill garbage collection; every computed would stay alive and
keep recomputing as long as it observes anything that is alive.

Basically you shouldn't care about whether it is cached or not: the result
should be the same. If it matters, that could be a smell

On vr 5 jan. 2018 05:48 Roy Riojas notifications@github.com wrote:

@windwalker https://github.com/windwalker I was confused by that too,
but it seems values are cached when used inside a reaction, autorun or in
the render of an observable React component.

Something like https://jsbin.com/rujuxe/edit?js,console,output you can
see that the computed values are only called once even when we show then
twice.

Also the value will be reevaluated if called directly. (check the click
handler of the button)

@mweststrate https://github.com/mweststrate are there any plans to also
return a cached value from the normal usages outside of autorun, reaction
and render?


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/mobxjs/mobx/issues/161#issuecomment-355472239, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABvGhPTK71eTzF8KRld9U9o9qsDW8620ks5tHamNgaJpZM4Hw0Ta
.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

Niryo picture Niryo  ·  3Comments

joey-lucky picture joey-lucky  ·  3Comments

rodryquintero picture rodryquintero  ·  3Comments

weitalu picture weitalu  ·  3Comments

geohuz picture geohuz  ·  3Comments