You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The functions in the library support two ways of getting the result of the request back. One of them is through a promise that is returned in the call, and the other one is a callback parameter that gets called with the data and eventual error.
The support for Promise is quite widespread at the moment and additions to the language like async/await, which allows a concise syntax around Promises, make this option the preferred one.
The idea is to get through some of the packages and projects that depend on the library and analyze how frequently they use the callback function before getting rid of it.
The text was updated successfully, but these errors were encountered:
I'm currently working on a TypeScript rewrite with backwards compatibility in mind (I'll see how far I get). Would it be a good compromise to keep callbacks but implement Promise support using the standard API available in ES6 and TypeScript? I feel like quite a few people still use this library in an ES5 environment, so requiring them to use a Promise polyfill and convert code might be a little overwhelming for some.
Thanks for your input @adamgrieger! Promises are widely supported these days and they are easy to polyfill for those projects targeting browsers like IE 11 and older. I tend to prefer having one way of doing something in the library instead of having 2 and then keep supporting the magic that assumes callback or options depending on the type of the parameter passed.
The functions in the library support two ways of getting the result of the request back. One of them is through a promise that is returned in the call, and the other one is a
callback
parameter that gets called with the data and eventual error.The support for Promise is quite widespread at the moment and additions to the language like async/await, which allows a concise syntax around Promises, make this option the preferred one.
The idea is to get through some of the packages and projects that depend on the library and analyze how frequently they use the
callback
function before getting rid of it.The text was updated successfully, but these errors were encountered: