Add prefer-blob-reading-methods rule

[NotWoods]

Fixes #1269

I opted to allow new Response(blob).arrayBuffer() because it's difficult to flag without type-checking (blob might be a typed array, stream, etc) and because it has better browser support than the blob methods.

[fisker]

because it's difficult to flag without type-checking (blob might be a typed array, stream, etc)

make sense 👍

[fisker]

Can you fix the linting problem?

[silverwind]

It won't trigger on reader.readAsDataURL(), right?

[jimmywarting]

It won't trigger on reader.readAsDataURL(), right?

There are times i think even readAsDataURL is even as equally bad.
Have seen hundreds of ppl on stackoverflow using it along with <img>
it have worse performance than using URL.createObjectURL(blob), it's sync, faster and easier to use. and you don't have to waste time reading the file, convert to/from base64

and most often it's also better to use typed arrays instead of base64 that's ~33% larger in since.

[silverwind]

I wasn't aware of URL.createObjectURL. If it does what it says, I do agree reader.readAsDataURL should be flagged as well. My use case is a simple convertion of an image Blob to a Data URI.

[NotWoods]

This discussion is better for the issues section so it doesn't get lost.

I agree that readAsDataURL has its own issues but it feels like it should be a separate rule. URL.createObjectURL has its own issues - it creates a pointer that should be freed later to avoid memory leaks.

[jimmywarting]

it creates a pointer that should be freed later to avoid memory leaks.

You get a point there! However... if it's a disc based file. then maybe it don't matter as much. Want to quote this guy on SO:

It mainly depends on what you pass to createObjectURL.

If you pass a File selected by the user from an , then the blobURI you created is a direct pointer to the file on the user's disk, nothing apart this mapping URI-file_path is saved in memory. So in this case, you can create a lot of these without ever revoking it with no real risk.

If you pass a Blob (or a File) that you did generate (or which has been fetched), then the Blob has to be stored in memory, and the blobURI will indeed keep being a pointer to this Blob and its data, protecting it from GC, until the document dies. In this case, don't forget to revoke it when you don't need it anymore.

https://stackoverflow.com/a/49346614/1008999

[jimmywarting]

On the + side. if you use <img src="blob:url" loading="lazy"> then it could maybe even possible be read lazily on demand from the disc when the image are in viewport.

and it's so much better than reading a hole video as base64 which would be huge.

[silverwind]

I see URL.createObjectURL does not actually create Data URIs, but /<uuid> style pseudo-URLs that are only valid for current browsing session.

So depending on use case, it's not a replacement for readAsDataURL, like when one needs a portable string. Think UI with a button to copy an image as Data URI to clipboard.