Hacker News Reader

Comment by hasenj | Hacker News Reader

It's not just that. I also need plugins for basic functionality that RN does not provide it out of the box, like playing audio, accessing the file system, reading sqlite databases, etc.

"Linking" these plugins is black box magic, if anything the fails I have absolutely no clue what is going on.

I have a feeling that some of the hairy errors I've been getting have something to do with the plugins not being up to date with the other libraries.

But like I said, I just have no idea what's going on.

If I'm going to learn how Android and iOS code needs to be structured then I prefer to just write native code. At least I will have more control.

View on HN

Yes a lot of times the issue is that libraries only support certain version of React Native, so for certain sets of libraries there are no versions of React Native compatible with all of them.

Expo has audio (https://docs.expo.io/versions/latest/sdk/audio.html), file system (https://docs.expo.io/versions/latest/sdk/asset.html), and other APIs built in (https://docs.expo.io/versions/latest/sdk/index.html). We don't have sqlite right now but are actively working on it!

The idea is that we provide a lot of nice things out of the box and then if you still need to write native code you can detach (https://docs.expo.io/versions/latest/guides/exponentkit.html) and only write the native code you need while keeping all our other APIs. You can still use `react-native link` after detaching if you want.

Is there a chance that some day your work (expo) will be merged with react native ? Conceptually, I think you are doing what people would expect the rn team to be doing. Namely providing access to the native apis through javascript, except that expo seems to provide much more features. For me, what's holding me back from using expo is the additional complexity of yet another dependency and having to use more tooling (e.g. expo client).

I think right now it makes sense for us to be separate from React Native. Adding all of these libraries adds QA overhead and if Facebook doesn't use them internally it'd be hard for them to keep them up to date. In addition there are some other features we support that definitely don't make sense in core. For example we embed multiple versions of the React Native runtime in our app so that people can choose when they upgrade and we don't break old projects when we push a new version.

I have thousands of images that I need to load dynamically at runtime. I shouldn't be expected to import them all by name.

That's not my idea of a filesystem API.

Reply on news.ycombinator.com