New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

What components are coming? #53

Closed
SanderSpies opened this Issue Feb 8, 2015 · 15 comments

Comments

Projects
None yet
9 participants
@SanderSpies

SanderSpies commented Feb 8, 2015

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

This comment has been minimized.

Show comment
Hide comment
@vjeux

vjeux Feb 8, 2015

Contributor

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
Contributor

vjeux commented Feb 8, 2015

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

This comment has been minimized.

Show comment
Hide comment
@SanderSpies

SanderSpies Feb 8, 2015

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

SanderSpies commented Feb 8, 2015

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

@vjeux

This comment has been minimized.

Show comment
Hide comment
@vjeux

vjeux Feb 8, 2015

Contributor

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.

Contributor

vjeux commented Feb 8, 2015

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

This comment has been minimized.

Show comment
Hide comment
@SanderSpies

SanderSpies Feb 10, 2015

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

SanderSpies commented Feb 10, 2015

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

This comment has been minimized.

Show comment
Hide comment
@ericvicenti

ericvicenti Feb 10, 2015

Contributor

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.

Contributor

ericvicenti commented Feb 10, 2015

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

This comment has been minimized.

Show comment
Hide comment
@joewood

joewood Feb 25, 2015

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?

joewood commented Feb 25, 2015

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

This comment has been minimized.

Show comment
Hide comment
@sahrens

sahrens Feb 25, 2015

Contributor

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.

Contributor

sahrens commented Feb 25, 2015

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

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Mar 28, 2015

@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!

ghost commented Mar 28, 2015

@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

This comment has been minimized.

Show comment
Hide comment
@vjeux

vjeux Mar 28, 2015

Contributor

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

Contributor

vjeux commented Mar 28, 2015

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

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Mar 28, 2015

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

ghost commented Mar 28, 2015

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

@sahrens

This comment has been minimized.

Show comment
Hide comment
@sahrens

sahrens Mar 29, 2015

Contributor

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.

Contributor

sahrens commented Mar 29, 2015

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

This comment has been minimized.

Show comment
Hide comment
@hinzundcode

hinzundcode Mar 29, 2015

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

hinzundcode commented Mar 29, 2015

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

@danicomas

This comment has been minimized.

Show comment
Hide comment
@danicomas

danicomas Mar 30, 2015

+1 for CameraIOS

danicomas commented Mar 30, 2015

+1 for CameraIOS

@brentvatne

This comment has been minimized.

Show comment
Hide comment
@brentvatne

brentvatne Mar 30, 2015

Collaborator

@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!

Collaborator

brentvatne commented Mar 30, 2015

@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

This comment has been minimized.

Show comment
Hide comment
@vjeux

vjeux Apr 1, 2015

Contributor

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

Contributor

vjeux commented Apr 1, 2015

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

@vjeux vjeux closed this Apr 1, 2015

@facebook facebook locked as resolved and limited conversation to collaborators May 29, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.