New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add tracked properties behind a feature flag #16366

Merged
merged 2 commits into from Mar 13, 2018

Conversation

Projects
None yet
3 participants
@wycats
Member

wycats commented Mar 12, 2018

This pull request adds Glimmer's tracked properties (including autotrack) to Ember, but with better Ember integration.

This PR includes "auto-tracking" of tracked getters, added to Glimmer in glimmerjs/glimmer.js#115.


For context, here is the description of the PR when added to Glimmer:

Previously, when defining a tracked computed property, you would write:

class {
  @tracked first;
  @tracked last;

  @tracked('first', 'last') get name() {
    return `${this.first} ${this.last}`;
  }
}

After this change, you can leave off the "dependent keys" and write:

class {
  @tracked first;
  @tracked last;

  @tracked get name() {
    return `${this.first} ${this.last}`;
  }
}

Rather than rely on knowing the full list of dependent properties up front, after this change Glimmer tracks the consumption of all @tracked properties inside the getter, and automatically creates a validator based on the consumed keys.


This PR also integrates tracked properties with Ember's object model.

Concretely, this means:

  • Accessing an Ember-style computed property inside of a Glimmer-style tracked getter is properly tracked.
  • Accessing a Glimmer-style tracked data property inside of an Ember computed property properly invalidates the Ember computed property.

In practice, this means that it is possible to migrate an Ember-style object to an idiomatic Glimmer-style object, and computed properties that consume the Glimmer-style object will work without adding new dependent keys.

There are still an open question about how to usefully tell developers when they have forgotten to mark properties as tracked (.set() gives us an opportunity to notice when an object was mutated without being properly marked, but it's harder to track when the mistake is just mutating a regular JavaScript object.

There is some evidence that it's possible to explain the programming model where forgetting to do something explicit means values won't update (silently) from other communities, but:

  1. it's unclear whether that experience is acceptable for Ember
  2. it's unclear whether the interaction with the Ember-style object model (where .get() and .set() is explicit) will make the failure modes even more confusing.

One thing we've considered is using the existing development-mode proxy we create for Ember-style objects to detect patterns where a property on an Ember object was consumed inside of a computed property or tracked getter and later set, so we could tell the user where they have forgotten to add the tracked annotation. This is a speculative idea that may not pan out, and resolving this open question is important before stabilizing this feature.

wycats and others added some commits Feb 23, 2018

@rwjblue rwjblue merged commit dd93361 into master Mar 13, 2018

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details

@locks locks deleted the tracked branch Mar 13, 2018

@smfoote smfoote referenced this pull request Mar 16, 2018

Open

Available APIs #2

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment