Hacker News Reader

Comment by ItsMe000001 | Hacker News Reader

For our use case RN has two major features missing:

- No file system access. We use react-native-fetch-blob (to which I actively contributed to add missing features and improve the code) which itself has quite a few disadvantages, such as a disappearing maintainer (fortunately a new one was found after a while, but the whole code has a few issues)

- The only way to transport binary data across the JS-to-native bridge is base64 encoded strings (expensive, has to be encoded and decoded on each side of the bridge) - if you need to read (raw binary) files and send them via websocket streams, as we do, you are screwed (I'm going to change the app design only because of RN so that this can be done within the native code without going through JS code)

View on HN

https://docs.expo.io/versions/latest/sdk/filesystem

That's not RN but Expo on top of it.

We tried Expo and very quickly decided against it. I forgot the reasons, somebody else did it and reported the findings and we all agreed.

Besides, why would I add an entire pretty big layer on top of still beta RN (version number well below 1) only to get one tiny component? That only makes sense if one wants the entirety of Expo, and this is where our tester (if we should use it) quickly ran into numerous issues.

I understand that it's en vogue to immediately point to this or that npm package or github repo for every problem big or small, but we don't do that. We look at the sources of every package we include, and we look at possible maintenance issues. Our own stuff is trouble enough, we don't need the added problems of all those layers on top of layers of "stuff". I know it's "move quickly and sort it out later when the business has grown" - but we don't want to work like that whenever we can avoid it. Because we don't have an "exit plan", we ourselves will have to maintain the mess we create now...

Didn't finde the filesystem stuff too limiting, it was just different from other systems I was used to. But yeah, it's a bit of a pain.

And FB mentioned the native bridge will be overhauled.

> Didn't finde the filesystem stuff too limiting

I don't understand. You don't need file system access? Then of course that's not a problem, does that need to be mentioned? Or you do need it, use a 3rd party app, and have not found the many issues of having to rely on a 3rd party module, such as when RNFB's maintainer disappeared (plus numerous code issues)? Since I care about future maintenance and I know that unpaid volunteers fed up with the demands placed on them by more and more users of their free packages I am not satisfied when at the time of use the package happens to work, I always look ahead and fear the future. When you have to unravel the whole thing a year later, when you have long moved on and have other things to do but now have a big maintenance issue on your hands because of some 3rd party package that you now have to maintain your own fork of, it's no fun.

> And FB mentioned the native bridge will be overhauled.

That is a plan for the possibly far-away future. In the recent HN thread about RN plans the RN person who responded to questions ("spicyj") said "likely yes", so it's not a done deal yet even as far as plans go. Reference: https://news.ycombinator.com/item?id=17314315

I did a document management app for iPad with RN once.

Used Expo for this. It required me to rethink a few things but in the end it worked like a charm and I didn't event need to detatch.

We looked at Expo but quickly stopped looking at it for a variety of reasons. So it worked for you, and you don't care about the maintenance issues either (you only mention that you what you implemented worked).

I used the library you mentioned in another project and didn't even notice the maintenance issue.

I used it for offline storage of video and audio files.

Didn't touch the code that interacts with that lib for half a year now.

For filesystem access, can't react-native-fs do the job? For a few things I found it less buggy that react-native-fetch-blob.

RNFB and RN-fs are the main two 3rd party modules that provide filesystem access. I chose one of the two after checking the code, the API, and the user base and commits (at that time the RNFB maintainer still was very active and had plans) to see which one looked more promising for my use case. I'm pretty familiar with both those modules down to the code (out of necessity, had to provide a lot of patches, I'm still using my own fork because when the maintainer disappeared there was no chance to get anything merged).

Reply on news.ycombinator.com