Check for Blob instead of File

[cretueusebiu]

The File class extends Blob, so this is useful when you create a Blob yourself (from the stream api for example).

Note: When you append a Blob instance to FormData and call FormData.get() you'll get an instance of File instead of Blob.
That's why I added t.true(formData.get('foo') instanceof File) in the new test.

[therealparmesh]

Thank you for the fix! Please see my review comments. 😄

[therealparmesh]

Shouldn't this be instanceof Blob? So we don't check for an instance of a sub-prototype?

[cretueusebiu]

When you append a Blob instance to FormData and call FormData.get() you'll get an instance of File instead of Blob.

Try this in your console:

const foo = new Blob([], {})
const data = new FormData()
data.append('foo', foo)
data.get('foo') // <- will return a File instance

[piranna]

On QuantumBA@13982a4 I'm doing duck-typing checking of Blob and File objects by checking the object attributes. This is needed because in ReactNative there's no File object concept (there will be Blob in ReactNative 0.54), so using object-to-formdata crash the applications. I would do a pull-request, but since all commits were squashed to have a "clean" commits history, now there are no references that could merge them.

[therealparmesh]

@piranna I'm not sure I fully understand the difficulty you're experiencing. Shouldn't the solution be to git remote add my repository, do a git rebase --interactive on top of my repository's master branch, pick only the commits you care about and comment out the rest, and then do a git push --force to your repository's master branch?

[piranna]

Yes, this could be a solution, but this kind of things related to modifying commits history are considered bad practices on public git repos. Both rebase and push --force should never be done in already published code because references are lost and pull-requests can't be done automatically.

[therealparmesh]

I agree that git rebase and git push --force shouldn't be used very often on shared remote branches. And if they do get used, they certainly shouldn't be used over and over again. At the same time if there is a small repository with no active pull requests or open issues pointing to potential work in progress then I think there's room to think about potentially using them once if desired. Again, 99% of the time I agree with that rule. But I don't think any rule should be dogmatically followed 100% of the time because there's almost always exceptions.

[piranna]

Yeah, I use push --force too ofter, but only minutes after doing the original push in case I've done a catastrophic sh*t before nobody else knows :-P But for other things, it's better to do a new commit, you don't know who could have just done a clone that could lost its references in that time...

Anyway, I have just done a pull-request merging both histories and fixing them, and also with the File object duck-typing.

[therealparmesh]

@cretueusebiu I just pulled in #10 from @piranna. Let me know if this unblocks you!

[cretueusebiu]

The file case worked fine before for me, because I was working in the browser.
But it didn't worked for Blob types. That pull still doesn't check for blobs, just for files.

I use a Blob when I read the data of an image and want to send it to server. Since you can't create instances of File in browser, you have to use Blobs.

[piranna]

master now have duck-typing checker functions for both Blob and File objects, the conflict in the pull-request would only be due just only to this thing.

[piranna]

I have just seen that ReactNative support Blob objects since July, and will have support for File objects in ReactNative 0.54 (currently in release candidate), so I'm not fully sure if the duck-typing has been a good idea, or it should be replaced for checking the actual objects, or do some checking for native support of the features on the system previously to use the duck-typing... What do you think?

[therealparmesh]

Closing this because we are explicitly checking for Blobs.