Max Fierke
Max Fierke
Heyo, just updating this issue to point out that the state-tracking has been rewritten and is much more robust in ember-concurrency 2.0.0, especially with regards to avoiding re-computation during state...
One thing I've seen before is adding the check within the task, something like: ```javascript @dropTask *myTask() { if (this.myTask.lastSuccessful?.value) { return this.myTask.lastSuccessful?.value; } // ... other stuff } ```...
Yeah, in general I think `rawTimeout` is probably the best tool for the particular use-case you raised. Can you think of other use-cases (i.e. non-timeout) where an escape from the...
@validkeys I think using computed properties might be the issue. Using normal getters seems to work: ```javascript @task({ enqueue: true }) enqueueTask = { reponse: null, dfd: null, respond() {...
To be clear -- this is may still be a bug, but I don't remember if `@computed` is supposed to work with Glimmer components or not
re: the issues raised w/ `@lastValue`: This seems like it's working exactly as expected. However, we should have documented that `@dependentKeyCompat` is the expected tool to use in the case...
I think this might be the same issue as https://github.com/machty/ember-concurrency/issues/216?
This dovetails nicely with the next RFC I'm working on, which is a public API for `TaskFactory` and opening up task modifiers for extension. All of this stuff already lives...
> @maxfierke do you have a tracking issue for your RFC or anything similar that I can link to? 🙂 Not really 😬 just one of my many projects, but...
@lougreenwood sorry for the long wait, but I have an RFC posted in #441 that will provide some exposure to this data (I think there's still some work to be...