12 ms·

I'm converting a codebase of Javascript of about 200+ js files to Typescript today. I am about 5% complete... already found two places where the argument list w

I'm converting a codebase of Javascript of about 200+ js files to Typescript today. I am about 5% complete... already found two places where the argument list was wrong and was being sent into a void. I also see the code that was making up for the fact that the third argument was being ignored (basically patching downstream because they thought the feature was broken). Now this codebase was written with a high degree of quality (it's pretty good but not perfect), but the lack of compile (and of course runtime)-time checks has caused waste. The second phase of my project to convert all promises to RX Observables :)

kjaer 9y ago
If you're just rewriting these Promises because the syntax is too verbose, you might be interested in checking out async/await as another alternative; I just rewrote some Promises to that recently, and it's really, really nice. Of course, if you prefer RX Observables, go right ahead :)
- coding123 9y ago
  Thanks for the note, I am looking into it right now. One area that may grind my head with async await however is that there is a lot of Promise.all work in this codebase. Would you still use async/await constructs when you need to do a lot of fork/join/merge stuff? (sorry for the derail HN)
  - kjaer 9y ago
    If you're using Promise.all to run code in parallel, then async await can't really replace that, as far as I know. But you can still use `await Promise.all(...)`, which will free you from having callbacks everywhere; running parallel code will no longer have to look so different from running it sequentially, which is quite nice.
  - Longwelwind 9y ago
    Yes, of course ! https://jsfiddle.net/0wc0vjw2/1/ https://jsfiddle.net/0wc0vjw2/1/
flavio81 9y ago
>I'm converting a codebase of Javascript of about 200+ js files to Typescript today. Pity you! I fear such tasks. As mentioned,take advantage of async/await. Also, make sure you wrap everything in modules and access from outside through module exports.
fineline 9y ago
Promises (representing the result of a single asynchronous operation) and Observables (representing an ongoing stream of emitted values) aren't really equivalent. I know you can create an Observable from a Promise, which will emit a single value when that promise is fulfilled and then be marked as completed or closed - but this is more for integration - such as being able to combine inputs from single-shot async calls into broader observable operations. If your Promises are discrete async calls, I'm curious why you would want to convert them?

kjaer 9y ago

If you're just rewriting these Promises because the syntax is too verbose, you might be interested in checking out async/await as another alternative; I just rewrote some Promises to that recently, and it's really, really nice. Of course, if you prefer RX Observables, go right ahead :)

coding123 9y ago
Thanks for the note, I am looking into it right now. One area that may grind my head with async await however is that there is a lot of Promise.all work in this codebase. Would you still use async/await constructs when you need to do a lot of fork/join/merge stuff? (sorry for the derail HN)
- kjaer 9y ago
  If you're using Promise.all to run code in parallel, then async await can't really replace that, as far as I know. But you can still use `await Promise.all(...)`, which will free you from having callbacks everywhere; running parallel code will no longer have to look so different from running it sequentially, which is quite nice.
- Longwelwind 9y ago
  Yes, of course ! https://jsfiddle.net/0wc0vjw2/1/ https://jsfiddle.net/0wc0vjw2/1/

flavio81 9y ago

>I'm converting a codebase of Javascript of about 200+ js files to Typescript today. Pity you! I fear such tasks. As mentioned,take advantage of async/await. Also, make sure you wrap everything in modules and access from outside through module exports.

fineline 9y ago

Promises (representing the result of a single asynchronous operation) and Observables (representing an ongoing stream of emitted values) aren't really equivalent. I know you can create an Observable from a Promise, which will emit a single value when that promise is fulfilled and then be marked as completed or closed - but this is more for integration - such as being able to combine inputs from single-shot async calls into broader observable operations. If your Promises are discrete async calls, I'm curious why you would want to convert them?