When to Use Ember get() – A Guide

If you’re working in an Ember app that’s been around for a while, you’ve probably wondered when to use get(this, ‘foo’) and when to use this.foo. You’re not alone.

When I first joined an Ember project, I was wondering the same thing. I searched around for an answer, but found that most answers dated from 2015 or 2016 and didn’t seem to apply anymore. I recently did some digging through the Ember documentation in an attempt to find a definitive answer for when to use Ember get().

The Rule

Take a look at Ember’s documentation for Ember get(), and you’ll see this information (from the documentation for Ember v3.14):

If you plan to run on IE8 and older browsers then you should use this method anytime you want to retrieve a property on an object that you don’t know for sure is private. (Properties beginning with an underscore ‘_’ are considered private.)

On all newer browsers, you only need to use this method to retrieve properties if the property might not be defined on the object and you want to respect the unknownProperty handler. Otherwise you can ignore this method.

Note that if the object itself is undefined, this method will throw an error.

Hurray! A definitive answer! In my current project, we aren’t making use of the unknownProperty handler, so we went ahead and converted our calls to ES5 getter syntax (i.e. this.foo).

As I did some more looking around, I realized it wasn’t quite that straightforward, and there were some scenarios where we’d want to keep using Ember.get().

The Exception to the Rule

If you want to chain properties together safely, you still need to use Ember get(). Here’s an example of chaining using ES5 getter syntax that might cause problems: let myListLength = this.myList.length. An error will be thrown in the console when myList is null or undefined.

If you instead use Ember get(), your code will look like let myListLength = get(this, ‘myList.length’) and you won’t get an error when the list is null or undefined. Using this syntax, your myListLength variable will simply be null when myList is null.

I didn’t find this information explicitly called out in Ember’s documentation, but there’s a reference to chaining in the RFC that made it safe to stop using Ember get() when not chaining.

A Note on Readability

Another thing to be aware of as you remove old uses of Ember get() is that its counterpart set() is still very important to the Ember ecosystem. If you’re looking to set a property in Ember, you should still use Ember set().

Ember’s implementation relies on Ember set() to ensure that computed properties update correctly when any of their dependent keys changes. For more information on that, check out the RFC that introduced changes to Ember get() a few years ago.

The important takeaway here is that your code could look a little bit strange when you’re accessing properties using this.foo, but you’re still setting properties using set(this, ‘foo’). Don’t let your lack of Ember get() syntax make it seem like you can start eliminating Ember set() just yet. For the time being, you’ll need to keep using set() universally.

If you’re currently working in an Ember application and are still wondering whether to use Ember get() or ES5 getter syntax, my suggestion is to use ES5 getter syntax whenever you aren’t chaining properties together. I find it to be more readable. If you need to chain together properties, use Ember get() to leverage safe chaining.

When in doubt, just stick with Ember get(). Ember has no plans of deprecating it according to that RFC, so it’s still safe to use in your application.