What components are coming?

[SanderSpies]

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 :-).

[vjeux]

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
WebViewIOS

[SanderSpies]

Is there a reason why Button is not on the list? (just curious :-))

[vjeux]

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.

[SanderSpies]

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);

[ericvicenti]

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 RCTDeviceEventEmitter which 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:

1. It is very easy to use EventEmitter improperly and forget to remove the subscription on component unmounting. Subscribable and Subscribable.Mixin adds protection against this
2. If we expose a public event emitter, anything can emit data from it
3. 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!

Subscribable will 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.

[joewood]

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?

[sahrens]

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.

[ghost]

@vjeux do you know if the CameraIOS component will be released anytime soon? I wanted to use the native camera but wasn't sure if I should implement something in the meanwhile or wait for the CameraIOS you mentioned. Thanks!

[vjeux]

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 :)

[ghost]

@vjeux Thanks for the heads up! In that case, maybe I should go ahead and build a component and share it :)

[sahrens]

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.

[hinzundcode]

If you're looking for ideas, would be cool if I could open a share dialog (UIActivityViewController) using js.

[danicomas]

+1 for CameraIOS

[brentvatne]

@ericvicenti - I like that! I assume that calling subscribeTo will add the subscription to some array that will then be removed upon unmount? Looking forward to seeing that released!

[vjeux]

Most of the components on this list have been exported, will close this one. Let's recreate an issue