alidcast / vuency Goto Github PK

There seems to be a bug in task cancellation demo that causes the running task instances count to turn negative. It occurs when you cancel an instance before it starts running (aka drop it). The finally block still seems to run even if the operation is dropped, but this shouldn't occur since dropped operations shouldn't even be started at all.

Rather than returning the promise, can return an object that the user can use as he pleases. (See this post).

Remove onDrop, onRestart etc. subscriptions and just use onCancel and task state instead.

Also, remove afterEnd subscription and just use built intry-finally clause. Keep Vuency as simple as possible.

There's a hidden bug in the task cancellation demo that needs to be fixed.

For example: nthCall(1, { doSomething: true }).

I've encountered a bug.
My code:

<script>
...
    remove: t(function*() {
                try {
                    yield fetch('http://domain.not.exists')          
                } catch (e) {
                    this.handleError(e)
                }
            }).flow('drop'),
...
</script>

<template>
    {{remove.isActive}}
</template>

Every time fetch('http://domain.not.exists') throws an exception I see error in console but task remains active so remove.isActive === true

Maybe I'm using vuency wrongly?

Right now you have to do task.run() but since functions are objects anyway, it'd be nicer to just do task() to start task instance

Need to better distinguish between the instance versus property subscriptions attached to the task.

task = t(taskFn) 
       .abort()   // property level
       .cancel() // instance level 

Also, are instance subscriptions necessary, or should most of the logic per task be the same?

taskInstance = task.run().cancel()

// could maybe even have them nested 
task = t(taskFn) 
       .abort()   
       // nth instance like css? 
       .forInstance(1)
             .cancel() 
       // per call? 
       .runOn('created')
           .onCance() 

Perhaps a better alternative could be to be able to give passed in params to subscriptions or to extend the task instance object.

handle page transition / failure errors better

.. perhaps add a dontWait modifier

Link to the docs at the bottom of the readme is broken.

Just getting a 404 not found

Cheers,
Daniel

Perhaps they can be used as additional task modifiers or injected into the tasks property function to be used the task's internal operation.

After adding support for async functions, the demos in the docs stopped working. After removing its support, they started working.

This is likely due to the fact that async support requires ES6 instance methods to check if a function is a generator or async function. Thus, as explained in babel/babel#3825 it might require babel-polyfill rather than babel-runtime.

Since releasing ember-concurrency, a lot of people have been asking me if/how/when they could use tasks for, say, node.js server development and other use cases. I've started to think about how to extract portions of e-c to a non-Ember-dependent library, and it'd be nice if the other various concurrency libs targeting specific UI libs (like vuency, perhaps react-concurrency) could share the same underlying primitives.

We talked about this briefly on Twitter but I figured I'd open an issue here early to get the ball rolling before we both write the same thing twice.

There's a bug in the concurrency graph demo that needs to be fixed.

Timers and listeners need to be cleaned up so they do not outlive the span of the running task instance.

In order to this for each instance, I need a way to either:

• Identify the timer with the task instance so that it can be cleared when the task instance is canceled.
• Extend the promise to attach the necessary data that is needed to cancel the timer. (Though this might not be possible yet - see babel/babel#1120).
• Figure out a weak map implementation and create the timers/listeners as runnable and cancelable objects. (Limitation here is that the timeout helper would only work for generator functions since they give access to the return value of each yield, thought this might not even matter since ongoing async functions can't be canceled anyways.)

Only named objects are being injected, not named functions.

e.g. if there is a typo and a function is undefined