Chained Promise: functional tools for recurring promises(github.com)
github.com
Chained Promise: functional tools for recurring promises
https://github.com/google/chained-promise
8 comments
Well, I guess states need to be captured somewhere somehow in order for any computer programs to function. The point of this library is to give a more declarative way of doing it, rather than having them dispersed into different parts of asynchronous handling logic.
It is one thing to say that a protocol is designed to be stateless, it is quite another to say a particular programming technique is so. If anything, functional programming leads to programming style that concerns less with how a particular state leads to another, and more with what transitions we want to make.
It is one thing to say that a protocol is designed to be stateless, it is quite another to say a particular programming technique is so. If anything, functional programming leads to programming style that concerns less with how a particular state leads to another, and more with what transitions we want to make.
The example given in the readme (API pagination) seems better suited to an observable or stream to me, but it left me curious about applicability to other use cases with Promises.
One is retries on failure or timeout. The other is waiting for something to execute a certain number of times. The latter is something I've used only in tests, but it might have other uses I'm not thinking of. I've implemented both of these in the past with recursion, which is great, but scares some folks, esp when mixed with promises.
One is retries on failure or timeout. The other is waiting for something to execute a certain number of times. The latter is something I've used only in tests, but it might have other uses I'm not thinking of. I've implemented both of these in the past with recursion, which is great, but scares some folks, esp when mixed with promises.
I think there's some value in expressing things like retries in terms of recursions and reaching the fixed point.
With regards to your first comment, I'm actually considering porting some of the logics to rxjs or other reactive extensions.
With regards to your first comment, I'm actually considering porting some of the logics to rxjs or other reactive extensions.
Original author of the library here. Will take any questions and comments, thanks!
EDIT: After posting this I just found out the library isn't compatible with the latest node release (6.5.0; still works well with 6.4.0). Will work with nodejs to see how we can address the problem.
EDIT: After posting this I just found out the library isn't compatible with the latest node release (6.5.0; still works well with 6.4.0). Will work with nodejs to see how we can address the problem.
Please don't actually do this. It completely violates all expectations of how both user-facing web servers and REST endpoints are supposed to behave.
The stateless nature of web programming is always frustrating, but attempts to use continuations to pretend a sequence of http requests can be treated as a single linear thread of execution simply don't work.