hassan-object

• Start Date: (fill me in with today's date, YYYY-MM-DD)
• RFC PR: (leave this empty)
• Ember Issue: (leave this empty)

Summary

Provide a modernized object model that takes advantage of the latest features of the language.

Motivation

Ember pioneered several features to improve the productivity of JavaScript developers working at application scale, such as a class system, mixins, and computed properties. Now that the language has adopted many of these features, we can reduce runtime cost and the size of Ember itself by migrating to the language constructs that supersede Ember's object model.

Why are we doing this? What use cases does it support? What is the expected outcome?

Detailed design

This is the bulk of the RFC. Explain the design in enough detail for somebody familiar with the framework to understand, and for somebody familiar with the implementation to implement. This should get into specifics and corner-cases, and include examples of how the feature is used. Any new terminology should be defined here.

Non-Computed Properties

Properties that are used as dependent keys must be annotated using the @property decorator.

Getter Compatibility

CPs should use the built-in getter/setter syntax + decorators, so that it's "just JavaScript" and computed properties feel like a thin layer on top of built-in accessors.

Caching

Today Ember memoizes/caches by default but this comes with significant memory overhead. For cheap/infrequently used computations it doesn't make sense to pay the memory cost. In this proposal, computed properties are not cached by default, but can be opted in to via the @cached decorator.

Examples

Simple computed property, no dependent keys

class Person extends EmberObject {
  // this decorator is optional—works the same with or without it
  @computed
  get fullName() {
    return "Tom";
  }
}

let person = new Person();
expect(person.fullName).to.equal("Tom");

Computed property with dependent keys:

class Person extends EmberObject {
  firstName = "Tom";
  lastName = "Dale";

  @computed("firstName", "lastName")
  get fullName() {
    return this.firstName + " " + this.lastName;
  }
}

let person = new Person();
expect(person.fullName).to.equal("Tom Dale");

How We Teach This

What names and terminology work best for these concepts and why? How is this idea best presented? As a continuation of existing Ember patterns, or as a wholly new one?

Would the acceptance of this proposal mean the Ember guides must be re-organized or altered? Does it change how Ember is taught to new users at any level?

How should this feature be introduced and taught to existing Ember users?

Drawbacks

Why should we not do this? Please consider the impact on teaching Ember, on the integration of this feature with other existing and planned features, on the impact of the API churn on existing apps, etc.

There are tradeoffs to choosing any path, please attempt to identify them here.

Alternatives

What other designs have been considered? What is the impact of not doing this?

Unresolved questions

Invalidation

Per-object invalidation, or per-prop? keep tag on entire object, any property mutation increments the value of that tag

Dependent Keys

Support chain nodes? If doing per-object invalidation, this basically just means entangling a parent objects invalidation/tag with a child object's.

Configuration

Do decorators operate on descriptors at invocation time, or do we just record configuration info and apply correct implementation at class/instance construction time?

E.g. if we mutate descriptors directly, there's a (confusing) difference between:

@computed
@cached
get foo() {
}

@cached
@computed
get foo() {
}

Mixins?

What is the syntax for this?