4 ms·

I think you (or I) misunderstand what you're replying to. When they said "you really don't want this", they're saying you don't want promises to sometimes be as

I think you (or I) misunderstand what you're replying to. When they said "you really don't want this", they're saying you don't want promises to sometimes be async and sometimes resolve in the same tick. Always make them async. That agrees with you, since it would mean you can always treat promises the same.

dvdcxn 11y ago
>sometimes be async and sometimes resolve in the same tick That's still asynchronous though isn't it? (Correct me if I'm wrong I'm just spitballing, still learning). There's no lower bound on the minimum amount of ticks a process can take for it to be async. What gives it that async-ness is that the upper bound is unknown, indeterminate, and changeable. Ergo, if some process is sometimes synchronous, and sometimes asynchronous, it's really a process that is asynchronous, but just so happens to occasionally execute in synchronous-like time.
- wonnage 11y ago
  The meaning of 'tick' here is special, since we're talking about Node. It's not a measure of time, it's an iteration of Node's event loop. Because Node is single-threaded, everything that happens in a single tick (i.e, one run of the event loop) is in the same execution context/stack/call tree/whatever you want to call it. So we generally call this "synchronous", although technically you could be holding onto the tick forever, firing off a bunch of nonblocking IO in there and doing your own polling/event management. Of course, that would be silly, since Node manages an event loop for you. So your nonblocking IO would instead push events onto the queue, and let Node move on to the next tick. If something happens in a different tick, it gets its own clean slate of an execution context, and we call this "async", since the function that triggered it is no longer running.
  - dvdcxn 11y ago
    That makes a lit of sense, thanks for the explanation.
btilly 11y ago
The general pattern is write code to do initial processing, set up promises, return a promise depending on those promises that will do something. The promises you set up should always be assumed to do things in whatever order they happen to happen. Your code that does interesting stuff happens before any promises are seen. The interesting code in your returned promise will happen after the necessary promises are resolved. As long as things are always set up this way, you'll be fine no matter how the promise library is set up. Which is good because unexpected implicit dependencies are a problem.

dvdcxn 11y ago

>sometimes be async and sometimes resolve in the same tick That's still asynchronous though isn't it? (Correct me if I'm wrong I'm just spitballing, still learning). There's no lower bound on the minimum amount of ticks a process can take for it to be async. What gives it that async-ness is that the upper bound is unknown, indeterminate, and changeable. Ergo, if some process is sometimes synchronous, and sometimes asynchronous, it's really a process that is asynchronous, but just so happens to occasionally execute in synchronous-like time.

wonnage 11y ago
The meaning of 'tick' here is special, since we're talking about Node. It's not a measure of time, it's an iteration of Node's event loop. Because Node is single-threaded, everything that happens in a single tick (i.e, one run of the event loop) is in the same execution context/stack/call tree/whatever you want to call it. So we generally call this "synchronous", although technically you could be holding onto the tick forever, firing off a bunch of nonblocking IO in there and doing your own polling/event management. Of course, that would be silly, since Node manages an event loop for you. So your nonblocking IO would instead push events onto the queue, and let Node move on to the next tick. If something happens in a different tick, it gets its own clean slate of an execution context, and we call this "async", since the function that triggered it is no longer running.
- dvdcxn 11y ago
  That makes a lit of sense, thanks for the explanation.

btilly 11y ago

The general pattern is write code to do initial processing, set up promises, return a promise depending on those promises that will do something. The promises you set up should always be assumed to do things in whatever order they happen to happen. Your code that does interesting stuff happens before any promises are seen. The interesting code in your returned promise will happen after the necessary promises are resolved. As long as things are always set up this way, you'll be fine no matter how the promise library is set up. Which is good because unexpected implicit dependencies are a problem.