Repository navigation
What components are coming? #53
Description
Activity
We have the following right now, but they are of varying degrees of completeness.
AxialGradient CameraIOS DatePickerIOS GeoMapIOS Image NavigationIOS PickerIOS ScrollView SliderIOS SpinnerIOS SwitchIOS TabBarIOS Text TextInput View WebViewIOSIs there a reason why Button is not on the list? (just curious :-))
Yeah, there's a cost of bridging elements, it turns out that reimplementing a button in pure JS is easier than trying to fit the iOS button api with React.
Also, since the new iOS, a button is just a label with no real styling associated. We do have TouchableHighlight and TouchableOpacity components to make sure interactions are working correctly.
What's the approach with non-UI libraries? How should I for instance expose something like UIDevice (which gives device information)?
I could imagine something like:
var Device = require('react-native/Device'); console.log('orientation:', Device.currentDevice().orientation);We are working on a lightweight store for device APIs, which we call
Subscribable. It comes with a mixin, and this is how you would use it in a component:var myComponent = React.createClass({ mixins: [Subscribable.Mixin], getInitialState: function() { return { isConnected: AppState.networkReachability.get() !== 'none' }; }, componentDidMount: function() { this._reachSubscription = this.subscribeTo( AppState.networkReachability, (reachability) => { this.setState({ isConnected: reachability !== 'none' }) } ); }, render: function() { return ( <Text> {this.state.isConnected ? 'Network Connected' : 'No network'} <Text onPress={() => this._reachSubscription.remove()}> End reachability subscription </Text> </Text> ); } });
A subscribable is created with an event emitter. For device events, we wrap an internal EventEmitter called
RCTDeviceEventEmitterwhich emits a 'reachabilityDidChange' event. We also provide the subscribable with a mapping function which you can use to transform the emitted value, and a function which subscribable can call to populate the initial data.AppState.networkReachability = new Subscribable( RCTDeviceEventEmitter, 'reachabilityDidChange', (resp) => resp.network_reachability, RCTReachability.getCurrentReachability );
Why are we wrapping EventEmitter with this new thing? A few reasons:
- It is very easy to use EventEmitter improperly and forget to remove the subscription on component unmounting.
SubscribableandSubscribable.Mixinadds protection against this - If we expose a public event emitter, anything can
emitdata from it - EventEmitter requires a string name for each event, which would encourage hardcoded strings and make static analysis more difficult
Feedback is welcome- this API isn't final!
Subscribablewill be available for you in a couple weeks. We will have a few device events exposed and the community can help add the rest. We're actively working on our code syncing process so we can release new things and upstream your pull requests.- It is very easy to use EventEmitter improperly and forget to remove the subscription on component unmounting.
Looks sensible. I like the general rule of avoiding string literals.
What about non-event based non-visuals, like theNSKeyedArchiver? How would the serialization work for that? Maybe just send back JSON using JSONModel?We have a mechanism for exporting constants for JS to consume which can be trivially used to provide device info like screen dimensions, number of processor cores, etc. We'll probably migrate over our internal RCTDevice module soon.
On Feb 24, 2015, at 5:59 PM, Joe Wood notifications@github.com wrote:
Looks sensible. I like the general rule of avoiding string literals.
What about non-event based non-visuals, like the NSKeyedArchiver? How would the serialization work for that? Maybe just send back JSON using JSONModel?—
Reply to this email directly or view it on GitHub.We don't have any Camera implementation inside of Facebook and don't have any project lined up that needs it. Hopefully someone from the community will be able to build it :)
We do have a camera component internally, but it's not longer used so is probably pretty crusty.
On Mar 28, 2015, at 11:04 AM, potsypantsy notifications@github.com wrote:
@vjeux Thanks for the heads up! In that case, maybe I should go ahead and build a component and share it :)
—
Reply to this email directly or view it on GitHub.If you're looking for ideas, would be cool if I could open a share dialog (UIActivityViewController) using js.
+1 for CameraIOS
@ericvicenti - I like that! I assume that calling
subscribeTowill add the subscription to some array that will then be removed upon unmount? Looking forward to seeing that released!Most of the components on this list have been exported, will close this one. Let's recreate an issue
- locked as resolved and limited conversation to collaborators
on May 29, 2018 - addedResolution: LockedThis issue was locked by the bot.This issue was locked by the bot.
on Jul 23, 2018
I'd like to implement an existing IOS component inside React Native, but would prefer to pick something that isn't already implemented by Facebook. Would be great if you guys could clarify the future plans of React Native a bit more, so we could also help out :-).