Questions about importing tasks from their own files

Hi,

I apologize if this has been answered before, I was looking through the issues and didn’t find it.

Are there any gotchas I should know about before putting task definitions in their own files? E.g. app/tasks/my-task.js and then importing as import myTask from "my-app/tasks/my-task"?

I understand that the concurrency is locked to the object that owns the task. If I have two different objects with this import and I use it in the object properties, do both objects own the same task definition (shared concurrency lock), or do they have separate concurrency patterns?

Is it better to export a generator function from the task file and wrap with task(...) in each usage, or export using the task(...) helper with the generator function in the task file and just add modifiers to each usage in different objects?

Thanks in advance

[xtagon]

Thank you! That helps a lot 👍

[maxfierke]

@xtagon The answer appears to be: Yes, you can export a task(...) and re-use it across components, and they will each maintain their own state. At least, in this limited Twiddle: https://ember-twiddle.com/576423fc578d8023b943ccf1c28bc9df I didn’t test it extensively, so perhaps there’s some hidden gotchas. However, because task(...) returns a TaskProperty, which is a type of ComputedProperty, the semantics are similar to a computed property macro like reads or mapBy.

I think this has something to do with property descriptors. I don’t know enough about them to speak intelligently but perhaps there’s a “late-binding” thing that happens on assignment as a property on an object.