Explanation of Ember 3.0 release notes


#1

Hi all! Can anybody explain me one thing from EmberJS 3 description? :slight_smile:

In Ember 3.0 reading a computed property without using get will cause an assertion failure in development. This addition of this assertion will help applications correct their currently incorrect usage, and in later 3.x releases allow us to remove the requirement to use get to read a computed property’s value.

I see 2 things here:

  1. Adding an assertion failure when reading a computed property without get()
  2. Requirement of using get() in this case will be removed in the nearest future

Aren’t these points contradicts each other?


#2

Thanks for asking to clarify here! I’m assuming you are specifically talking about this section of the Ember 3.0 blog post.

In nearly all 2.x versions of Ember, an odd internal implementation detail slipped through to your object’s prototype. Specifically, this meant that a private implementation detail of the computed property system was actually present on that property of your object.

Lets take a look at an example:

const Person = Ember.Object.extend({
  name: Ember.computed('firstName', 'lastName', function() {
    return `${this.get('firstName')} ${this.get('lastName')}`;
  })
});

let robert = Person.create({ firstName: 'Robert', lastName: 'Jackson' });
robert.get('name'); // => Robert Jackson
robert.name; // => instance of Ember.ComputedProperty

In Ember 3.0 doing anything with that private Ember.ComputedProperty object that lives at robert.name will result in an assertion. For example:

robert.name.somePropertyHere // => Assertion will be triggered here!

Now, back to your specific questions:

The assertion being referenced is only for nested property lookup on a particular CP. In the example above, that means that robert.name will not assert but robert.name.anythingElse will.

EXACTLY!! Please take a look at the Ember 3.1 blog post (specifically this section), and you will see that we have made it possible to remove the usage of .get in many scenarios.

The example above will now look like:

robert.name; // => Robert Jackson

As you can see, we needed to make doing anything with that private internal Ember.ComputedProperty object an error so that we could change the return value of robert.name from Ember.ComputedProperty to the actual computed property value…

Hopefully that helps!