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?)

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?