make compatible with node fs API

[mvayngrib]

would be cool to be able to use this to shim node's fs

"browser":{
 "fs": "react-native-fs"
}

// then use as node fs
var fs = require('fs')
fs.readFile('path/to/file', options, function(err, buf) {
 // etc
})

[johanneslumpe]

Ok just to make sure that I understood you correctly: you're requesting the ability to pass a node-style callback as last param, yes? Or are you asking for a 100% identical api (Buffer objects et al.)? I'm not sure how feasible a full re-implementation of the node fs api would be, given the fact that data transfer from js to obj-c is really slow for bigger files.

As for passing options to readFile, writeFileetc. - the only relevant part would be the encoding I assume. Currently everything is handled as UTF8.

[mvayngrib]

I guess I do mean an identical API, like level-filesystem. You're right that it's not a trivial problem. And parts wouldn't even be possible, like all the synchronous methods. Another way to go that I'm considering, is using level-filesystem on top of react-level which would write to AsyncStorage as opposed to the actual file system.

[johanneslumpe]

The use-case for this was actually to be able to read data from the caches and document directory and not to provide an arbitrary filesystem-replacement. I can see that some things need to change or should be improved, but I'm not sure whether this module will/can be a full re-implementation of the fs modulle.

[mvayngrib]

no worries, thanks for the useful module!

[johanneslumpe]

Yeah sure :) I will try to make it resemble the node api a bit closer at least.
That will include:

• being able to pass callbacks instead of using the promise based api
• use a generic options object as 2nd parameter for functions

Would that at least help you a bit?

[mvayngrib]

yes, thanks :) I'll try to help out when I get time. Right now I'm still on dgram, trying to get some p2p stuff working. I'm curious, how did you go about building the static library for this? I'm not an expert at Xcode so I ended up using a ./new-library.sh script from an unmerged react-native PR.

[johanneslumpe]

Oh I just copied one of my other projects and then renamed some stuff. Initially I set up my project by creating it manually in Xcode (iOS -> Framework & Libs -> static lib).

[agenthunt]

Hi , I am interested in node fs like shim. Will try to contribute when I find time. Added some IntegrationTests for existing API as a start. Have sent a pull request.

[mvayngrib]

if you just want a node fs api in react-native, there's already one on top of level-filesystem and asyncstorage-down: react-native-level-fs.

[agenthunt]

Right. But it uses leveldb backend. I wanted to use regular file system backend.

[mvayngrib]

great, I'm looking forward to it then!

[johanneslumpe]

@agenthunt can you elaborate a bit what you want the shim to look like? Especially since writing data from js to obj-c is kind of slow, it might not make sense to implement the full api. What are your thoughts? I'll take a look at the integration tests as soon as I can!

[agenthunt]

Hi @johanneslumpe, As @mvayngrib discussed earlier, the shim should be as much as possible be compatible with node fs. I understand that a lot of it will not be possible (ex: synced stuff), but that can be left out. My goal is to minimise writing different(backend) code for different platforms.

My initial thoughts with react-native was that we could do something like that easily, but as I delved deep I realised it is missing a lot of node core apis. I hope there will be more similar modules that fill the gap for different platforms so that we can have similar backend code and maximise user experiences with react-native ui code.

[agenthunt]

If you plan to make the api node like, are you still planning to keep the existing promise based apis or would it be good idea to make the api node like and then provide a promisified api on top of that ?

[johanneslumpe]

That's a good question. If we provide a node-ish api, then we could use bluebird's promisification methods to create a promise based api on top of it.

I'm still not quite sure how compatible to the node api we can make this, just because of the fact that a lot of stuff won't work properly via the bridge.