per action callback
Closed this issue · 11 comments
complete is useless if you do anything async inside of action
Yes, it is.
I could add an additional callback function as a parameter for action that they must call when they are finished.
yea that would do. honestly I'd be using promises at this stage but nobody seems to like those, some simple CPS based control flow abstractions would go a long way to keeping out of this mechanical stuff. I think the logics a little lost in there at the moment.
I never used promises in Node.js. But I like Akka's/Scala's futures/promises a lot. Can you hint me to the concrete promise implementation you are talking about?
The implementation I had in mind ain't as easy as I thought. How can promises improve the control flow here?
with promises you just think normally I only use callbacks when I'm feeling extra creative. promises are pretty misunderstood though so it wouldn't be a bad idea to stick with CPS since this wouldn't be too bad with a bit of abstraction. I'll PR something with promises if your interested in taking a look at what that looks like.
here is a basic implementation using promises. it won't be obvious exactly how it works but hopefully you see its a nice logic to noise ratio. It doesn't handle any of the options but to an extent you don't need them anymore presuming your users are familiar with promises.
I converted the "all" test so you can run that for proof that it works.
Looks nice, but I don't want to change the API that much. Maybe if you get it working you can make a new package with your promise-style API.
I'd like the API to stay as it is. This package is very open and I don't think (as you already said) that many will like an API that uses promises. I thought it's possible to hide the promises behind the API and make it optional, but I don't want the users of this library to adopt the promise style of async programming.
Anyway, thank you for your effort in the promise version. Nice insight into node-style promises.
yea its foreach thats doing the bulk of the work here and a CPS version of that wouldn't be much worse
-might be closed-
It is absolutely fine as it is and the 2nd callback is not useless in every case then.
Usually you want to implement one (!) promise pattern allover your project to make it readable.
So I'd like to contribute "our way" based on the current dive as a snippet (just as a hint):
We use express for node.js and we use dojo in the client AND in node.js - everywhere ;)
One example is the automatic "in memory" aggregation of all views for Express, naming them and extending them. We would like to use dojo/Deferred everywhere :
The 1st callback sends the file async to our read function which reads its content async but returns another promise.
In the 2nd callback we can check if all of the 2nd promises are fulfilled (implement your own error handling there) and if so we can work with our "in memory views object", e.g.
{ "projectA/index" : " {{ helloworld }} ...", "projectA/protected":" {{hellouser}} ..."}
To keep the example simple, I have put the relevant parts in a gist (thankful for improvements) :
https://gist.github.com/redaktor/9546054