Streams
What about the
react thing?
// server request handling
ASQ.react(function listen(trigger){
httpserv.on("request",trigger);
})
.runner(router)
.or(responseError);
The idea is that JS Promises are very powerful, but don't map well to event streams. Promise can be resolved only once. (My note: I also see it as advantage. Promises can give you caching "for free". For the same request you can then just send the result of the Promise every time and it will only run the first time)
In Node, the request and response objects are streams.
You could do:
stream.on("request", function(req,res){
// big Promsie chain:
foo
.bar
.baz
})
But then you would fire the whole promise chain every time a request comes in.In Reactive Programming (RxJS), they invert this paradigm, to create observables. The observable gets notified every time a new event happens and then sends out some "asynchronous stuff" when an event happens. So this a way to adapt asynchronous flow control to an event stream.
His
react adapter does something similar. It allows you, at the end of react to chain an arbitrary list of async functions that get called every time the trigger gets called in its first parameter. In this case, on a request, the trigger gets called.
ASQ.react(function listen(trigger){
httpserv.on("request",trigger);
})
.runner(router)
.or(responseError);
So the inversion is that the stream (httpserv.on("request",cb) is defined inside the chain. This is basically the 50 000m view of Reactive Programming and flow control.So the first part (lines#1-3) is defining the trigger that will run the rest of the chain.
Creates a new templates files. Copies index.grips.html to about.grips.html. Changes about.grips.html. Shows without do anything else the /about route now works.
Then just updates the master.grips.html template to add the the link to the /about page. Again all he has to do is save this file.
Also, now the site works as a single page app, re-rendering on the client.