react-native-fs merge with react-native-fetch-blob

[rpopovici]

Guys, I don't know if you are aware of this project https://github.com/wkh237/react-native-fetch-blob, but apparently servers exactly the same purpose as react-native-fs. IMO it better maintained and has more file API coverage, including upload for android, even thus it was originally designed to server a different purpose. So, I was wondering if it makes sense or even possible to merge these two projects as one..

[cjdell]

I have been off this project for a while and feel really bad for that. I want to get back into it now I have more free time.

This library has admittedly fallen behind. The react-native-fetch-blob looks very promising, and it seems to cover everything that our library can do and more. However there are apparently a lot of people using this library who will continue to need support for the foreseeable future.

This just my opinion, but in my view there are two options moving forward:

1. Deprecate react-native-fs, and suggest that people move to react-native-fetch-blob. We could provide a shim to make the transition less painful. Working together behind a single project we may be able to achieve more.

2. Take all the features we like from react-native-fetch-blob and integrate them into react-native-fs. We are both MIT licensed. We can still collaborate, but also maintain the freedom to go in our own directions.

What do people think?

/cc @johanneslumpe @grabbou @corbt @aforty @freshlybakedcode @benvium @esamelson anyone I missed?

[johanneslumpe]

@cjdell Yeah I think adding a deprecation warning makes sense given the fact that neither I nor anyone else actually has time to properly maintain this library.

[aforty]

react-native-fetch-blob looks very promising, in fact I think it can replace 2-3 modules I use for various different things. I think deprecation (with warnings) is probably the best route and we can devote our precious time to getting react-native-fetch-blob up to par, if anything is in fact missing. (I have only glossed over the README)

[benvium]

We'll still be using this for some time at our company - we've got 6 or 7 apps using it at the moment. However, we will investigate react-native-fetch-blob when we start our next project.

One thing that's worth pointing out though is that the _name_ of this library is much better - especially for those from a Node.JS background.
I want to access the file system - well, I use fs in Node so react-native-fs just makes sense. Perhaps in the long term we could consider 'donating' the name to fetch-blob? (just an idea!)

[MarkMurphy]

I also think react-native-fs is a much better name :)

[MarkMurphy]

what would be really nice is if we could get a filesystem api as part of react native's default libraries.
I've add a feature request here so feel free to help vote it up: https://react-native.canny.io/feature-requests/p/baisc-filesystem-api-including-readwrite-streams

[aforty]

@MarkMurphy But fetch-blob does a lot more than just filesystem access.

[MarkMurphy]

@aforty sure, but I don't need a lot of that. I'm just looking to build a TUS compatible (http://tus.io) client so all I need is a readStream method that allows me to specify a start and end offset like that of node's createReadStream. I think I can do that with fetch blob? The docs are a little rough.

And besides, I think it makes sense that react-native should come with at least a basic file system access library, hence the feature request.

[MarkMurphy]

To add to that, the other reason I'd like to see Facebook implement one is because external libraries die off a lot...

[aforty]

I agree with everything you just said, I was only bringing that up in reference to fetch-blob possibly taking this projects name. I don't think it makes sense for that reason. (edit: while I also like this projects name much better)

[MarkMurphy]

I was only bringing that up in reference to fetch-blob possibly taking this projects name.

haha ohhh, gotcha 😄

[hardcodet]

Landed here while looking for the best solution to take. While this thread started quite a while ago, things might have changed a bit - it looks as if fetch-blob has lost its maintainer, who also only rarely contributed through 2017. So while deprecation of native-fs was discussed here - please don't ;)

[spelunk]

In terms of feature parity, what is react-native-fs missing that react-native-fetch-blob currently supports?

[russpitre]

We're using react-native-fs because we need Windows UWP support, however we've come to a point in our app where we need Android Download Manager support which is available in react-native-fetch-blob . It would be great if there was some way to merge these two projects.

[greenais]

Surely we need wider Android support - DocumentDirectory only access looks quite limiting.
In particular, CameraRoll (DCIM/Photos) access should be considered a must have one, probably.

[itinance]

No worries, @hardcodet and all others. There are NO plans to deprecate this library again. It is "too big to fail" in my eyes. Thats why i took it over nearly one year ago. react-native-fs is widely used since Q1 2016 in a bunch of actively managed apps of my company and my customers and so on.

Since it is open source, you all can help to make this library much better! As you can see in the project-history, i give my best to check and merge pull requests. Most PR's have landet in master. In some periods of time faster and sometimes not so fast. It also depends on the extent of the PR, how fast i can act here.

[dallen4]

@itinance react-native-fetch-blob user here,
Is anyone aware of a consistently-maintained fork of that module or will the features be implemented in this module anytime soon? I'm on a team working on an app and we use fetch-blob for our image uploading, there's some things that need updating (i.e. Android build tools) with newer versions of RN and using it with RNFirebase. If anyone has an pointers or knows of a maintained version of react-native-fetch-blob, advice would be appreciated!

[dantman]

Last time I checked react-native-fetch-blob the code handling content URIs on Android looked so terribly implemented I wouldn't want to touch the library. And Blob itself is something that is now built into React Native.

There may be some value in copying some filesystem stuff from RNFB to RNFS, but I don't think the projects should merge together. In fact RNFS would be better off integrating with the built-in Blob that React Native provides instead of what react-native-fetch-blob implements. e.g. So you can fetch() get a Blob back and then use react-native-fs to save that Blob to the filesystem. Or vice versa, use react-native-fs to create a Blob from a file so that it can be uploaded with fetch() and FormData.

[lll000111]

The RNFB maintainer disappeared last year and there are new maintainers, but they have not exactly made much progress.

THIS package right here also seems to be kind of stale though....? I don't fault anybody, I too was a co-maintainer of a widely used package and did not have the time to fix any problems unless they impacted my own company. Github would be in a prime position to create something that could provide monetization for all those many widely used packages where they sit in the middle... Does anybody what's up right here? Quite a few open issues and - worse, PRs (they could be merged, commented on or rejected?).