Using Ember Octane Tracked Properties to Simplify Reactive State

The problem with implicit dependencies

In classic Ember, computed properties declare their dependent keys as strings. When a dependency is missed or mistyped, the UI can show stale data, and debugging requires tracing which keys actually affect the value. As applications grow, these implicit dependencies become hard to maintain.

How tracked properties change the model

Ember Octane introduced @tracked decorators and autotracking. A property marked @tracked signals to Ember that its value can change. Any getter that reads a tracked property during its execution is automatically considered dependent on that property. When the tracked value updates, Ember recomputes the getter without extra dependency strings.

Worked example: a user‑name component

Generate a component:

ember g component user-name

Replace user-name.js with:

import Component from '@glimmer/component';
import { tracked } from '@glimmer/tracking';
import { action } from '@ember/object';

export default class UserNameComponent extends Component {
  @tracked firstName = '';
  @tracked lastName = '';

  get fullName() {
    return `${this.firstName} ${this.lastName}`.trim();
  }

  @action
  updateFirstName(event) {
    this.firstName = event.target.value;
  }

  @action
  updateLastName(event) {
    this.lastName = event.target.value;
  }
}

The template user-name.hbs can bind inputs and display the name:

<label>First name:
  <input value={{this.firstName}} oninput={{this.updateFirstName}} />
</label>
<label>Last name:
  <input value={{this.lastName}} oninput={{this.updateLastName}} />
</label>
Hello, {{this.fullName}}!

When either input changes, the tracked property updates, autotracking notices that fullName read the changed value, and the displayed name refreshes instantly—no extra observers or dependency arrays needed.

Trade‑offs and migration considerations

• Version requirement: Tracked properties need Ember 3.13 or later. Running ember -v should show at least that version; otherwise the decorator will throw a runtime error.
• Mental shift: Developers must stop listing dependent keys and instead rely on the getter’s read‑track pattern. Existing computed properties can coexist, but mixing them in the same class risks missing dependencies if a getter reads a tracked property while a computed property expects a string key.
• Debugging: While autotracking reduces boilerplate, tracing why a value recomputed can be less obvious than reading a dependency list. Ember’s inspector tooling can help visualize tracked property changes.

Actionable next steps

1. Upgrade your Ember CLI project to >=3.13 if it isn’t already (npm install ember-source@~3.28.0 or the latest LTS).
2. Create a new component using the pattern above, or refactor an existing computed property by replacing it with a @tracked field and a getter.
3. Run the app (ember serve) and verify that UI updates correspond to input changes without adding observers.
4. Gradually migrate other computed properties, testing each change in isolation.