What are the guidelines for exposing native APIs? about react-native HOT 4 CLOSED

I'm sorry if this is premature talk but I'd love to get some sense of the direction of this project.

It's the best time to talk about the hard questions :)

Bridging APIs one-to-one is not trivial in React native for three big reasons:

• iOS/Android APIs are imperative but React is declarative
• iOS/Android APIs are synchronous but React native has an asynchronous bridge
• iOS/Android APIs are written in Obj-c and Java but React native is in JavaScript

So, it's actually non trivial to map 1 to 1 native apis.

So far, the process was to start with a use case that one of the app we are building needs to support. At this point, we look at all the possible ways to expose the API and try to find the best one. One really important point is that we start from a use case, and not take an existing API and just rush to expose it all.

The stance that we've taken so far is to try to make them as web/React friendly as possible.

How fast are we willing to make breaking changes to them? (Unlike React, we have a lot of public API here.)

This is why we want to do this private phase for now. We have never open sourced a project with such a crazy large API surface.

My 5min thoughts on this is that what's in this github repo is going to lag in the APIs that it supports, but we have great extensibility tools that other people can fill the gap for APIs that we don't support yet.

from react-native.

Would it be possible to support some generic FFI-like interface for interacting with the raw imperative native APIs?

I don't know that much about the target platforms, but something like that would reduce pressure for a "proper" react-native supported version of the API and allow userland to experiment with options before committing to a solution in core.

This is roughly how normal React deals with support for DOM stuff not explicitly exposed, and works very well in terms of not constraining the user.

from react-native.

@glenjamin: this is a good idea. So far we worked close with our few users so we've been able to build high quality custom apis for their use case, but that's unlikely to scale.

Right now my thinking was to allow people to write their own bindings via plugins. So if a feature is not yet supported, they can bridge it themselves. But something automatic may be a useful escape hatch as well.

The best way to know is to try it and see if it solves real use cases

from react-native.

Closing as this is a discussion and not super actionable :) Feel free to keep talking here

from react-native.