react-native-fs vs react-native-blob-courier and general thoughts

[pke]

I only recently discovered that RNFS also supports up/download of files. I know this bundle is a replacement for RN-fetch-blob but I have to wonder why do we need so many bundles basically doing the same?

RNFS has a horrible "moveFile" implementation that basically does a copy/delete scheme and not just rename a file with OS help so it could need some improvement there. But it looks like its download/upload capabilities are quite ok. Have you evaluated it before starting this bundle?

Maybe things like transcoding/file hashing/crypting could be supplied via plugins to a general file handling module to keep the main module clean and lean? Think react-native-fs, react-native-fs-sha512, react-native-fs-aes.

I am a sucker for keeping resource usage at an absolute minimum to save device battery and therefore would like to move much of file related operations to native code, especially anything related to transcoding of filestreams. Nothing of that should be handled in JS code. Only resource friendly progress notifications should go over the bridge in the most performant way possible.
The RN docs are seriously lacking in that regard which JS types can go over the bridges for free*. Like ArrayBuffer maybe?

I also don't like to convert everything into base64 when JS strings are perfectly capable to contain binary bytes verbatim since the are not depending on 0-byte termination. node-forge uses this extensively - everything is a byte string. I'd like to be able to hand in byte encoded strings to RN modules but it seems every RN module author uses base64 encoded input and output with all the required conversion as a burden (to me and the devices CPU). Do you know if swift/objectivec/java can't handle strings containing \0 char bytes?

[edeckers]

Hi, thank you for sharing your thoughts. I would like to break it down a little:

1. Why did I start this library, there are several already?
2. What are my thoughts on resource efficiency?
3. Do I know the particular reason why RN module authors resort to base64 encoding of data?

Why did I start this library, there are several already?

I've got a few actively maintained RN-apps in production and most of them used rn-fetch-blob, which to my dismay got discontinued last year, right when a showstopper bug related to forced scoped storage on Android API 29+ reared its head. As you may be aware, all new app releases are required to support API 29+ by Google since November 2020, so I was in kind of a pickle.

Naturally my first course of action was to find an existing alternative, which resulted in a shortlist of react-native-fs, expo-file-system and a new fork of rn-fetch-blob. There are a few problems though:

1. Especially a far as RN-libraries go, I believe it is important to do one thing and do it well, which all those libraries violate; I'm looking for large HTTP-transfer support, not file processing
2. Both react-native-fs and rn-fetch-blob are not tested extensively as far a I am aware, which jeopardizes maintainability
3. At the time react-native-fs looked abandoned to me; There has been a little activity lately, though
4. rn-fetch-blob is now on its third fork in just as many years, which gave me some trust issues

So I figured I'd roll my own; keep it simple and test it thoroughly and simultaniously give back to the community I benefit so much from. I even wrote a little promotional blogpost explaining why I wrote the library, if you're interested.

What are my thoughts on resource efficiency?

I am a sucker for keeping resource usage at an absolute minimum to save device battery and therefore would like to move much of file related operations to native code, especially anything related to transcoding of filestreams.

Even though we have different drivers - battery conservation is not something I focus on in particular; it rather follows from continuously improving the library - I am totally with you on keeping the library as small and lean as possible and we share the same worries about transferring data over the bridge. This is why we came up with two solutions, right? One being an experimental JS+bridge transcoder and the second being a native message bus pubisher which allows you too hook-up native plugins.

As for the actual implementation of plugins: I will personally not be writing any plugins at all, but I do want to facilitate them in the library if we can come up with a workable architecture; I'm open to suggestions! I think the native message bus mentioned before is the way to go here, but since this route will always force you to write some native code anyway this raises the question: wouldn't you be better off to just write your own module for your particular project? i.e. is React Native Blob Courier the right fit?

Do I know the particular reason why RN module authors resort to base64 encoding of data?

I had to do a little research for myself actually and I found the best explanation in this thread, but you found that a month ago as well :)

As far as I am aware Swift, Objective-C and Java all handle \0 terminated strings perfectly fine, but the problem seems to be with JSC

That’s because JSC always handles strings as UTF-8 terminating with NULL.