> Hi,
>
> That doesn't work, kinda work in javascript world where the function has
> finite, fixed set of arguments, were there is a definition of last one.
> Typescript helps a lot with that, because
> it can ensure to a higher degree, that types are correct, js on its own,
> loose so you have
Hi,
The one interesting case you have to look at dealing with, is the one I
came across where by the call of a function can return a results and will
then later async call the callback in the future.
Because with the proposal above, you have lost the ability to, return the
return result and
One of the common refactorings I do is:
let file1 = await readFile(filename1)
let file2 = await readFile(filename2)
// to
let [file1, file2] = await Promise.all([
readFile(filename1),
readFile(filename2),
])
I would be very confused if refactoring it in this way made my code break
because of
>
>
> Hi James,
>
> I did alot of upgrading of javascript codebase to typescript code base
> about 2 years ago for a year, where the goal was to get everything promised
> and then basically
> were possible ideally move to the await method. This required for us to
> come up with peace meal approach
For many legacy code bases that are based on callbacks mechanisms like
node.js' promisify function are required to help facilitate the transition
from callback centric code to Promise-centric. A lot of the time, these can
follow straightforward rules without requiring customization. However, at
5 matches
Mail list logo
