Task Modifiers about ember-concurrency-typescript

[makepanic]

Thanks for creating this addon.

We're currently using ember-concurrency-decorators so I'd prefer the concurrency-decorators style.

It has the advantage, that the task definition is in one place, instead of being split by it's implementation.

[buschtoens]

@dfreeman ember-concurrency-decorators itself has no implicit knowledge of ember-concurrency internals. applyOptions just iterates over all entries of the options object and if the value is true plainly calls the method with that key or for any other case passes the value as the first argument. This way, extensions to the TaskProperty.prototype work out of the box.

The implicit limitation however is, that you can at most pass one argument and the argument itself cannot be true.

This means a hypothetical extension like throttle(spacing: number, immediate: boolean) would currently not be supported. We could make it work by spreading arrays, e.g.

myTask = task({ throttle: [100, true] }, function*() {});

Writing this I just realized, that we actually need something like this, to support .on(eventNames...) and .cancelOn(eventNames...), e.g.

myTask = task({ on: ['init', 'click'] }, function*() {});

[gossi]

I don't mind doing this:

@task({...})
someTask = task(function*() {...});

@restartableTask({...})
someOtherTask = task(function*() { ... });

I do like it for the reason, that at some point we will have this:

@task({...})
someTask*() {...}

The "the upper part" (= decorators) will mostly stay the same for what we write today and in the future, so no relearning here. While we (as TS users) know, that we cannot use method*() for now but have to use "workaround syntax" which is method = task(function* () {...});.

I dunno how often syntax changed over the past 2-3 month. At least this sounds like an approach that will consistency.

Although, yes - you may have a duplicate task here to use the same decorator as task function to give options.

PS. I'm not clear about the current state of e-c and whether task can be used as fn and decorator but I assume it to be possible 🙈

[dfreeman]

I'm generally a fan of accept modifiers as an options object, ember-concurrency-decorators style, but it's not clear to me how that would interact with libraries that add additional methods on TaskProperty.prototype, like ember-concurrency-retryable.

I haven't looked at the implementation as it stands today, but do any of these approaches (putting aside decorators) allow for using augmentations that are made to the base ember-concurrency implementation without needing special knowledge of ember-concurrency-typescript?