This course has been updated! We now recommend you take the Ember Octane Fundamentals course.
Transcript from the "Computed Properties" Lesson
[00:00:00]
>> [MUSIC]
[00:00:03]
>> Mike North: Computed properties work very nicely with the kinds of simple properties that we've seen so far. You can get them, you can set them, but the key difference is that they're properties that are derived from other values. They're evaluated lazily. So you define a function that describes the calculation, how do you establish a value C from dependent values A and B?
[00:00:32] And only when you ask for the value of that computer property is that calculation actually made. The value is cached, meaning subsequent retrievals of that value will not cause the work to be redone unless some dependent property has been changed. So a very powerful concept, a very efficient way of sort of massaging things if you want to capitalize a string and then have that be what you're showing in your UI.
[00:01:05] This is a great way to make that work. So here is an example of a read-only computed property that would be dependent on firstName and lastName, and it just is simply concatenating these two strings together. So only when we ask for full name will this function that takes an array and joins together with a space, only when we ask for the property will it be calculated and that's what we mean by, when we say it is evaluated lazily, this is that concept.
[00:01:43] So this is the sort of old way of defining computer properties and it's still 100% valid and not in anyway deprecated moving forward for read-only computed properties. This is another way to define it. This is sort of the more modern syntax. It was introduced in Ember 1.12, so a very recent release.
[00:02:10] And you'll notice here that, instead of passing a function in to this computed method, this is passing a function in. Instead, here, I'm passing in an object which has a Git function in it. The reason that this was done, it has to do with the way setting computed properties used to be structured.
[00:02:33] Used to be one function and depending on the number of arguments, you would be sort of in getter mode or setter mode and it became difficult to read and maintain. So now the concepts are sort of broken out into separate get and set functions all wrapped in an object, that is, that's sort of the more modern way of defining things.
[00:02:54] But again for simple read-only computed properties, doing things the Ember classic way is totally fine.
>> Mike North: For settable computed properties, as I said, we're gonna provide a method set. And that will take in, as arguments, the property key and the new value of the property that has just been set.
[00:03:21] And you can see here, we've sort of performed the reverse of getting full name. We split the new value by space, and then everything before the space is the first name, everything after the space is the last name. We set those two properties, firstName and lastName, and then very important, in our setter, we return the new value that was just passed in and this has to do with the way that caching works under the hood.
[00:03:54] If you don't return new val at the end of your setter, you will end up with mysterious and hard to track down bugs.
>> Mike North: Everyone get how this works?
>> Speaker 2: What is key in set method?
>> Mike North: In this case, key is gonna be fullName. And the reason that you're passing key in is if you think about how this would look when abstracted a little bit.
[00:04:17] So say that we had something more generic that was a factory that was spitting out the result of calling this function computed. We may not necessarily know exactly which property is being set. This may just be a function that is generally used and we need to be aware of exactly what we're dealing with at that moment.
[00:04:43] So in this case, not so clear how it's useful, but in the case where you abstract it a little bit more, there are situations where you really need to know what is the property that you're dealing with. So you can see the way I defined dependencies. firstName and lastName are the first two arguments passed into computed.
[00:05:09] Actually, everything except for the last argument passed into computed. That's taken as the name of a dependent property. And if you remember when we were talking about get and set, you can have a path deep into a hierarchy like name.first which would be drilling into an object and declaring a dependency on a property deep within a hierarchy.
[00:05:38] And just like we were talking about how you have to treat arrays a little bit differently with get. You have to treat arrays a little bit differently when you deal with computed properties as well. Because the arrays in and of themselves are observable.