[w3c/FileAPI] Consider adding `blob.dataUrl()` method, or some other analogue to `readAsDataURL` (Issue #179)

Obviously data URLs should be avoided where possible, but unfortunately developers are often interacting with systems/libraries/APIs outside their control, and, practically, `readAsDataURL` is used a lot -- actually, about as much as `readAsText` and `readAsArrayBuffer` combined:

 * **readAsDataURL**: https://github.com/search?l=JavaScript&q=readAsDataURL&type=Code (1.6 million hits)
 * **readAsText**: https://github.com/search?l=JavaScript&q=readAsText&type=Code (770k hits)
 * **readAsArrayBuffer**: https://github.com/search?l=JavaScript&q=readAsArrayBuffer&type=Code (830k hits)

The `blob.arrayBuffer()` and `blob.text()` methods are delightful to use compared to previous methods, but for data URLs / base64 we're stuck with:
```js
let file = ...;
let dataUrl = await new Promise((resolve, reject) => {
  const reader = new FileReader();
  reader.readAsDataURL(file);
  reader.onload = () => resolve(reader.result);
  reader.onerror = (e) => reject(e);
});
```
which is the opposite of delightful. This is one of those cases where I'm "embarrassed" by how convoluted a simple task is in JS when helping someone who is new to JS.

There are a couple of proposals that are related to this issue:

* https://github.com/lucacasonato/proposal-binary-encoding
* https://github.com/tc39/proposal-arraybuffer-base64

That said, I really like promise-based `blob.methodName()` approach, and I'm hoping that we'll eventually get something like that for data URLs.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/FileAPI/issues/179
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/FileAPI/issues/179@github.com>