vue-concurrency API initially started to be as close as possible to ember-concurrency for a few reasons:
it makes this library easy to understand for people who know ember-concurrency
it helps preserving the same philosophy and keep the lib on the same path as ember-concurrency
however, there are also some challenges:
value
value is a problematic property name for a task instance because it might make it look like a value from Ref is being accessed and that's not the case. result could be a reasonable alternative
instance
I'd argue that the term task instance is a bit confusing in ember-concurrency as well because it might imply that TaskInstance is some kind of instance of a Task class and that's not the case. In ember-concurrency Task + TaskInstance are both completely separate classes and instances are created from both of them (in the OOP sense). But in Ember this is still more tolerable because Ember is overall more OOP than Vue.
vue-concurrency is under the hood not written in OOP, it's plain functions
vue, especially vue 3 also turns rather towards functional programming (using hooks, avoiding classes, this). So coding beginners picking up Vue might have no OOP knowledge and the term Instance is not helpful to understand the concept.
It's harder to come up with a naming alternative here:
vue-concurrency API initially started to be as close as possible to ember-concurrency for a few reasons:
however, there are also some challenges:
value
valueis a problematic property name for a task instance because it might make it look like a value fromRefis being accessed and that's not the case.resultcould be a reasonable alternativeinstance
It's harder to come up with a naming alternative here:
TaskRuntask.runs...TaskCalltask.calls...TaskPerformtask.performsNeither of these seem great.