Promises supported?

[GitToTheHub]

trafficstars

Hi, does this API supports Promises, so that i can do resolveLocalFileSystemURL(url).then(...) or must i wrap every api call in Promises?

Thanks for responding!

[breautek]

Promises are not supported.

[GitToTheHub]

Can you maybe integrate it? I did a polyfill and it was not so much work.

[breautek]

I'll treat this as a feature request, but I don't think we can support promises for as long as we support Android 4.4, not without a polyfill library anyway.

I can't guarantee when this will be done as Cordova is a bunch of volunteers with limited time. You are however welcome to make a PR.

[GitToTheHub]

Thank you, for treating it as a feature request. I looked for the minimum Android version of promise support, and saw the minimum version 4.4.3. Would this not be enough to support? I'll see, if i can make pr or something else.

[breautek]

I believe Cordova supports 4.4.x. Additionally, plugins that offer the Browser platform support I believe needs to be able to support IE. So polyfills will also be needed in those cases.

[GitToTheHub]

Ok, it's not that hard to add a polyfill. I will see, what i can do.

[Nashorn]

Now all hope is on 1 man, the GitToTheHub

[GitToTheHub]

;)

[brody4hire]

I would actually favor using some kind of Promise-like utility such as https://github.com/joelnet/XPromise rather than an actual polyfill for multiple reasons, major is unpredictability of behavior and interference with other modules & packages. Some nice arguments here: https://ponyfoo.com/articles/polyfills-or-ponyfills

[breautek]

I Disagree. The arguments in that article is mostly for language syntax features such as arrow functions (Which you can't really polyfill properly anyway, as stated in the article).

Using a promise-like utility is just another piece of software that will need to be kept up-to-date. Using a polyfill is something that can be activated for older browsers that don't support a particular feature and can be safely removed in the future without refactoring anything, as the codebase is already using the same interface as the browser API.

Additionally, using Promise that is supplied by the native code will likely outperform any javascript implementation of a feature which is why polyfilling when required is generally better than using an alternate "feature-like" library in my opinion. I think this is particularly important in this case because asynchronous code obviously happens very frequently in most applications, so if promises are used, they should as efficient as possible.

I've used es6-promise to support IE, older versions of Safari, as well as android 4.1+ in my projects. It has consistent behaviour native-browser Promise on modern browsers.

Also, https://github.com/joelnet/XPromise is not a production library. It's built as a challenge to create usable/tangible library without the use of variables for fun.

The challenge is to create a piece of software (something real, tangible and more than a hello world) without any variables. The idea came from a tweet of Samer Buna’s article. Which I responded (in jest) with try to “code without variables”.

[GitToTheHub]

@breautek Really good explained. For the majority, we don't even need a polyfill. iOS has support since iOS 8 and Android since 4.4.3.

What i don't understand is, that there are so many Promise polyfill solutions. When i'm searching for a polyfill, the first entry i found is https://www.npmjs.com/package/promise-polyfill So i don't understand, for example, why @breautek is choosing another package, or why e.g. the creator of cordova-plugin-googlemaps was choosing https://github.com/then/promise

Maybe a lot ot this persons wanted to understand the techniques behind the scenes and published there experiences. But i think the api is not that hard and it should be not a great thing which polyfill to choose or which is better then the others.

[Nashorn]

This might be a stupid question but why do you even need promises?

[breautek]

What i don't understand is, that there are so many Promise polyfill solutions.

You'll likely always find multiple people building their own solution for a problem.

For the majority, we don't even need a polyfill. iOS has support since iOS 8 and Android since 4.4.3.

This is true, but we also do support 4.4.x, including the patch versions prior to 4.4.3. Additionally the browser platform should also support IE11, which doesn't support promises natively.

This might be a stupid question but why do you even need promises?

It's not really a need, but a nice to have feature. Chaining promises is much better than trying to chain callbacks. Makes the code much cleaner in my opinion.

[GitToTheHub]

This might be a stupid question but why do you even need promises?

It's really a weired question for me. It's for doing your code much more cleaner and simpler (e.g. for getting rid of the callback hell).

And Promises are the necessary step to use the async/await command in your JavaScript, so you can simply write

let fileEntry = await resolveLocalFileSystemURL("file://...");
let content = await new FileReader().readAsText(await fileEntry.file());

[Crash--]

@GitToTheHub Since you have -already- done the work, can you share it to make a first review possible?

[GitToTheHub]

Hi, sorry, I didn't found time currently to make a PR. I only made a promise polyfill for the plugin but didn't add it directly in the plugin code. I only could share the polyfill currently.

[GitToTheHub]

Hi I won't implement the promises in this plugin, because I don't find time for this and have other projects to do. I hope someone else could do it :)