Consider adding `blob.dataUrl()` method, or some other analogue to `readAsDataURL`

Obviously data URLs and base64 in general 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.

In fact, readAsDataURL is used 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:

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.

Nell’issue non sono identificati alcun file del repository né alcun test. Inizia esaminando i metodi arrayBuffer() e text() esistenti di Blob insieme alle proposte collegate binary-encoding e ArrayBuffer base64, quindi determina se esiste una direzione definita per un’API di data URL basata sulle promise. Il completamento richiede un design dell’API concordato, non una modifica localizzata.