ember-async-data doesn't catch errors, so we can't rely on it to protect us from "leaky errors" during rendering.
When the function passed to trackedFunction throws an error,
that error will be the value returned by this property
Alias for isRejected
Alias for isResolved || isRejected
Alias for isPending
Initially true, and remains true until the underlying promise resolves or rejects.
When true, the function passed to trackedFunction has errored
When true, the function passed to trackedFunction has resolved
Alias for isFinished
which is in turn an alias for isResolved || isRejected
this.data may not exist yet.
Additionally, prior iterations of TrackedAsyncData did not allow the accessing of data before .state === 'RESOLVED' (isResolved).
From a correctness standpoint, this is perfectly reasonable, as it forces folks to handle the states involved with async functions.
The original version of trackedFunction did not use TrackedAsyncData,
and did not have these strictnesses upon property access, leaving folks
to be as correct or as fast/prototype-y as they wished.
For now, trackedFunction will retain that flexibility.
Will re-invoke the function passed to trackedFunction
this will also re-set some properties on the State instance.
This is the same State instance as before, as the State instance
is tied to the fn passed to trackedFunction
error or resolvedValue will remain as they were previously
until this promise resolves, and then they'll be updated to the new values.
Generated using TypeDoc
State container that represents the asynchrony of a
trackedFunction