镜像站点 · 本页由第三方 GitHub 只读镜像提供,非 GitHub 官方站点,不接受任何登录或凭据输入。前往 github.com
Skip to content

What components are coming? #53

Description

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

Activity

  1. vjeux commented on Feb 8, 2015

    @vjeux
    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
    
  2. SanderSpies commented on Feb 8, 2015

    @SanderSpies
    Author

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

  3. vjeux commented on Feb 8, 2015

    @vjeux
    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.

  4. SanderSpies commented on Feb 10, 2015

    @SanderSpies
    Author

    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);
    
  5. ericvicenti commented on Feb 10, 2015

    @ericvicenti
    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.

  6. joewood commented on Feb 25, 2015

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

  7. sahrens commented on Feb 25, 2015

    @sahrens
    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.

  8. vjeux commented on Mar 28, 2015

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

  9. sahrens commented on Mar 29, 2015

    @sahrens
    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.

  10. hinzundcode commented on Mar 29, 2015

    @hinzundcode

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

  11. danicomas commented on Mar 30, 2015

    @danicomas

    +1 for CameraIOS

  12. brentvatne commented on Mar 30, 2015

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

  13. vjeux commented on Apr 1, 2015

    @vjeux
    Contributor

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

  14. locked as resolved and limited conversation to collaborators on May 29, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions