This is a PR to use @tracked for Task and TaskInstance state on Ember 3.16+ to enable use without using @computed when consuming derived state.
In Ember < 3.16, e-c behaves as it currently does requiring @computed to track task-derived state changes.
This PR essentially replaces the state properties on the Ember implementations of Task and TaskInstance with those properties decorated with @tracked (done dynamically, though w/ property descriptors. not redefining them with actual decorator syntax, so there's no dependency on decorator transforms.) This incurs a little bit of a cost, since it's redefining the properties, but practically shouldn't have much effect since it's applied to the Task and TaskInstance prototypes, rather than every instance, so it would only be incurred once.
There's a few outstanding issues/open questions with this:
The no-render-breaking tests are triggering re-render assertions (one of them might technically be a "correct" failure.) Fixed
[X] Seems that setProperties reads the properties it sets, consuming the tag and leading to the error when setting @tracked properties. I think this can be worked around by using Object.assign instead.
[X] performCount needs to be read to be updated. Seems this is fine in some contexts, but not others? (i.e. not in the case in one of the tests) Tracked internally as _performCount and used for reads to ensure write-only to tracked performCount
How does this work for add-ons that depend on ember-concurrency and support multiple Ember versions?
They'll still need to use @computed if they consume ember-concurrency state and support < 3.16. However, @computed Just Works™ with the tracked state, it seems.
Within applications with both tracked & computed properties, if using a native getter to access task state, and wishing to use it alongside a computed property, @dependantKeyCompat will need to be used on the getter as expected with any other tracked-prop using getter.
I'd expect there are probably other edge-cases with this as well.
This is a PR to use
@trackedforTaskandTaskInstancestate on Ember 3.16+ to enable use without using@computedwhen consuming derived state.In Ember < 3.16, e-c behaves as it currently does requiring
@computedto track task-derived state changes.This PR essentially replaces the state properties on the Ember implementations of
TaskandTaskInstancewith those properties decorated with@tracked(done dynamically, though w/ property descriptors. not redefining them with actual decorator syntax, so there's no dependency on decorator transforms.) This incurs a little bit of a cost, since it's redefining the properties, but practically shouldn't have much effect since it's applied to theTaskandTaskInstanceprototypes, rather than every instance, so it would only be incurred once.There's a few outstanding issues/open questions with this:TheFixedno-render-breakingtests are triggering re-render assertions (one of them might technically be a "correct" failure.)Seems thatsetPropertiesreads the properties it sets, consuming the tag and leading to the error when setting@trackedproperties. I think this can be worked around by usingObject.assigninstead.performCountneeds to be read to be updated. Seems this is fine in some contexts, but not others? (i.e. not in the case in one of the tests)_performCountand used for reads to ensure write-only to trackedperformCountHow does this work for add-ons that depend on ember-concurrency and support multiple Ember versions?@computedif they consume ember-concurrency state and support < 3.16. However,@computedJust Works™ with the tracked state, it seems.Within applications with both tracked & computed properties, if using a native getter to access task state, and wishing to use it alongside a computed property,
@dependantKeyCompatwill need to be used on the getter as expected with any other tracked-prop using getter.I'd expect there are probably other edge-cases with this as well.
Resolves #343