Comments (4)
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.
Related Issues (20)
- Sticky views have visual glitches while scrolling in ScrollView HOT 1
- targetSdkVersion 33 to 34 app crash HOT 7
- Error: package com.facebook.react.modules.storage does not exist import com.facebook.react.modules.storage HOT 4
- Heap snapshot throwing `RangeError: Invalid typed array length: -1` on latest chrome version HOT 8
- ☂️ Help us migrate Android tests to AssertJ HOT 23
- Accessibility issue - Android with TalkBack - accessibilityRole="link" is not available when user tries to navigate via links (TalkBack menu)
- App Crash when using ReactNativeFile in apollo upload client HOT 4
- createBundleReleaseJsAndAssets\index.android.bundle:1322:18: warning: the variable "DebuggerInternal" was not declared in function "__shouldPauseOnThrow" typeof DebuggerInternal !== 'undefined' HOT 7
- automaticallyAdjustKeyboardInsets doesn't work in the new arch HOT 2
- App Crashes - On upgrading to Android 14(SDK 34) for "react-native": "0.68.2", HOT 4
- No hot reloading when change font scale
- react-native 0.74.3 new project sync error HOT 3
- Codegen: Int32 generate double on Java HOT 2
- Issue with Top Padding in Text Component on Android (includeFontPadding : false not working🥹) HOT 5
- RTL Layout Direction Not Updating after app reload with New React Native Architecture HOT 10
- Unable to handle hardware back press in Brownfield Setup with BackHandler HOT 5
- App could not Build when trying upgrade sdk 33 to 34 HOT 4
- App could not Build when trying upgrade sdk 33 to 34 (Unexpected error during link, AAPT2 aapt2-4.2.2-7147631-linux Daemon) HOT 4
- react native android crashed in the real device when target API level is changed from 33 to 34. HOT 7
- Upgrade pretty-format to 29 HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from react-native.