Computed Property vs Getter

#1

With the advent of ES6 we can now use getters as in:

export class col {
    constructor(left, width = 140) {
        this.left = left;
        this.width = width;
    }

    get middle() {
        return this.left + this.width/2;
    }
}

Previously I would have used a computed property in the example above to obtain the middle value. Is there any advantage to either approach? The get seems ideal to me as I don’t have to import anything and remember to identify the key fields I will be watching. Just wondered if there are any disadvantages to this (performance?) compared to traditional Ember computed properties or any gotchas of which I need to be aware.

0 Likes

#2

I’m using native getters in https://emberclear.io, but I’m also using tracked properties and auto-tracking.

I ‘think’ it’d be faster, because you to longer have a cache layer from computed. And with small properties, I that is preferred.

0 Likes

#3

Sorry, just to clarify - you think getters would be faster than computed? I’m guessing if there is a property that is accessed a lot or involves heavy computation then the caching of a computed property would probably win though.

0 Likes

#4

Yeah. However, I don’t know how well this works pre-octane. My only concern pre-octane is if a change in the getter value will result in a template update.

Potentially. But in octane, you don’t need to worry about it, thanks to tracked and auto tracking, you can just use getters. :slight_smile:

0 Likes

#5

Thanks. Octane isn’t out yet is it? I’m on 3.4 LTS at the moment.

0 Likes

#6

Correct, all pieces of it will hopefully be in non-canary on the next releases and then hopefully the release after will be the octane release :slight_smile:

0 Likes