This is interesting... I think I understand it a bit better now. It seems not wildly unlike async.auto:
https://github.com/caolan/async#autotasks-callback Which lets you specify dependencies between tasks rather than an order of tasks. However, you've added the idea of streams to that picture. On Thu, Jan 15, 2015 at 8:25 PM, Amir Yasin <[email protected]> wrote: > FRHTTP heavily uses Bacon, but it's not itself an extension of Bacon. To > determine what to call, in the execution phase (when the native node HTTP > server hands it a connection) it builds out a series of combined streams > (bacon combineTemplate is heavily used for this) from a series of dynamic > observables. Where did these dynamic observables come from? That's > determined by looking at the params/produces of all the when blocks in your > route as well as your render block. There's a lot of stuff going on here > that's hard to detail in a short post, but if you're interested you can read > the code for routeExecutor.js (the entry point is the routeExecutor > function). > > As to how you would do a db query, as luck would have it I wrote a sample > for that today :). Here's the sample: > https://github.com/ayasin/frhttp/blob/master/samples/db.simulation.js (that > one deals with async values being produced by something outside of your > control like a DB), here's a sample that deals with just accumulating values > and returning a single result (also using enter to break once it's done): > https://github.com/ayasin/frhttp/blob/master/samples/factorial.js > > My plan is definitely to improve the docs, write more samples and probably > some blog posts about all this. The structure of the doc could definitely > be better, was there a specific section that confused you? > > Also the error handling front, here's what an uncaught exception in a route > in FRHTTP outputs to the console (you can see the code that threw this at > https://github.com/ayasin/frhttp/blob/master/samples/uncaught.exception.js): > > ERROR: function (Crashes On Purpose) threw an exception (TypeError: Object > #<Object> has no method 'crashNow') on input: { > "internal:__ready": 1, > "demo": "a value" > } > > Notice that it tells you who threw it, what the exception was, and most > importantly what the input to the function was that caused it to be thrown. > If you're doing functional programming and only using your inputs it should > be very easy to track down the cause. > > Amir > > On Thursday, January 15, 2015 at 9:23:04 AM UTC-6, Tom Boutell wrote: >> >> >> On Wednesday, January 14, 2015 at 2:45:45 PM UTC-5, Amir Yasin wrote: >>> >>> First, thanks for the comment. It's not really a reinvention of the >>> async module in that there's no "order of execution" specified by the >>> author. Things get executed as data becomes available. Think of it more as >>> "I need these signals to be ready and then I can transform them into this >>> other set of signals". You end up in a situation where you're defining >>> functions that do very specific tasks and produce output. They can be >>> called multiple times if necessary within the context of producing an output >>> or just once. The other part of this is that if any of them throws an >>> exception or has an error you get a nice output to the console "Function >>> suchAndSuch threw an exception (the exception) on inputs {a json object of >>> the inputs}". Much nicer to deal with than the errors you get from >>> callbacks. I'm not sure I understand what you mean by "if/when/each" logic. >>> You can handle all of those in this as far as I can tell between producing >>> values which get consumed by something else (each) and filtering via "enter" >>> (if/when). >>> >>> Amir >> >> >> Hmm. I've started reading about Functional Reactive Programming. As near >> as I can tell your library resembles baconjs, but with bindings specific to >> dealing with express requests. But after reading the documentation and your >> comments I am still pretty lost as to how it decides what to invoke when, >> and how you would handle a situation where you must iterate asynchronously >> over many objects returned from a query, for instance. >> > -- > Job board: http://jobs.nodejs.org/ > New group rules: > https://gist.github.com/othiym23/9886289#file-moderation-policy-md > Old group rules: > https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines > --- > You received this message because you are subscribed to a topic in the > Google Groups "nodejs" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/nodejs/TF6-k4lWKGE/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > To post to this group, send email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/nodejs/04c68ca3-3211-4f10-9b81-cbee5a5f8b17%40googlegroups.com. > > For more options, visit https://groups.google.com/d/optout. -- THOMAS BOUTELL, DEV & OPS P'UNK AVENUE | (215) 755-1330 | punkave.com -- Job board: http://jobs.nodejs.org/ New group rules: https://gist.github.com/othiym23/9886289#file-moderation-policy-md Old group rules: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines --- You received this message because you are subscribed to the Google Groups "nodejs" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/nodejs/CAORXhG%2BJoaKEdp7G%3DhBpJ_A_7uAiw%3DMH%2B3VtdnfqZg8cTM95gA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
