Boken: Hylle: idk, react-router 1.0 apparently supports import { Router, Route } from ‘react-router’

Aikins: Boken: that’s very different from what you have up there. Like, the two programs do entirely different things, and import entirely different objects

Solinski: So if I want to dynamically generate ID’s based on a variable called %= property % and insert them into an existing div which looks like div cl***=”cl***1″, can I just append something like id=’%=property %” into the div code?

Carson: And that looks like erb so you may want to hang in #rubyonrails

Danielovich: Oh, everything scrolled p*** me, but I guess no-one answered my question because I see no highlight :

Sorace: What is the best way to wait for something to happen? I have an repeated ajax call that must not restart until the previous execution is done successfully.

Minskey: But when the previous call was a success it should stop waiting and do it’s thing

Carson: Anotheryou_: use promises

Bailie: How do you know when to use promises vs async vs streams? or is it all preference?

Reineck: Steeze: on the level of ease of use promises async streams

Reineck: Promises are most useful when you have a lot of asynchronous operations which you need to combine in different ways

Stuedemann: Steeze, Promises are an object that helps you perform tasks once a seperate task is complete. Async is a way of performing tasks asynchronously and can be either concurrent or parrallel

Reineck: Streams are useful primarily when you need to move around larger amounts of data and process it as it’s available. I’d generally avoid them as they do make life a bit complicated

Heslep: Okay i def need promises for this one then

Norby: Steeze, streams usually refer to streams of data so you can continuously process something like a movie or music file

Arballo: I actually heard a talk on streams today ha

Reineck: If by async you mean “standard” callback oriented functions, then they are fairly flexible but a bit less convenient that promises

Harpe: But didnt seem to fit my use case, but it got me thinking which one to pick and why

Hostler: I meant the async lib

Nuccio: Trying to avoid callback hell

Fredricks: You can stream and process a movie file asychronously then use a promise to load the movie once the processing is completed

Reineck: The async lib is ok, I think it’s mostly useful if you have a bunch of callback-style functions

Reineck: You can use it to somewhat simplify composing them together, but not as convenient as promises I think

Rosell: Basically, i have something like foo = getData; doSomethingElsefoo. but getData is a mongoquery and returns undefined at that point in time

Kalinoski: So i need to wait for the mongoquery to finish. async might actually be okay for this. cause i could do everything i need in the subsequent callbacks

Raygoza: And just make it look good with async

Pinkham: Steeze, Then you want to use promises as a way to know when the query is complete

Alesse: Steeze, Async will simply allow you to perform other tasks while the query is executing

Calahan: Im using mongoose. should i wrap a query in a promise in my model? or just make the promise some other way

Fieldhouse: Literphor, ohhh i got it

Posas: Wrap a mongoose method in a promise*

Cooperrider: Or like, fn getData { var def = Q.defer; . return def } ?

Mohseni: Steeze, Promises are used in tangem with async because.with a synchronous process you always know when it ends because the next immediate consecutive task will be executed or the next line of code

Dauphinais: Steeze, No idea I don’t know what you’re doing

Dietzen: Literphor, cool. thanks for the explanations!

Dutcher: Steeze, If you’re using a framework and using a method that a async from that framework, I would expect them to give you a promise or a callback to use