Introduction

Android has 3 types of actions that user can choose to perform while granting the permission - Grant, Deny, Never show again. Developers would want to know exactly which action user has performed. The prompt for permission keeps showing up unless and until the user chooses "Never ask again".

Currently, PermissionsAndroid.check() returns a boolean and it's not clear whether the user has denied access just once or permanently disabled the prompt.

The Core of It

The intro says it all.

Discussion points

• Should PermissionsAndroid.check() return a PermissionsAndroid.RESULTS value?
• Is it even possible to do this?

See docs

Introduction

Android Oreo introduced the AutoFill Framework, for secure communication between an app and autofill services (e.g. Password managers).
Since this is an important security feature, it would be great to add some props to TextInput component to give developers access to configuring AutoFill.

The Core of It

Out-of-the-box, Android Oreo+ already tries to autofill TextInput components based on heuristics (on the placeholder text, for example), but there is no way to actually set configuring options.

Autofill configuration options include field type hints and autofill importance/priority, for example.

References:

Android AutoFill Framework documentation: https://developer.android.com/guide/topics/text/autofill
Related issue / feature request: facebook/react-native#17097

Discussion points

• Should we add props to the TextInput component to allow AutoFill configuration? I think yes.
• This change is Android only

i know react-native will rearchitecture in <State of React Native 2018>
who can tell me the progress of rearchitecture？

Summary

We propose changing the Quick Start docs to use the expo-cli package instead of create-react-native-app.

• Expo CLI is a tool based on CRNA, made by the same team
• It has all the same features, plus some additional benefits (see below)
• Like CRNA, Expo CLI does not require an Expo user account
• The create-react-native-app command will continue to work

Background

Currently the Quick Start section of docs shows how to get started using Create React Native App (CRNA). In the past few months, I and my colleagues at Expo have been working on Expo CLI, which aims to bring CRNA to the next level. Expo CLI builds on and extends CRNA.
Expo CLI follows the same philosophy as CRNA (from https://github.com/react-community/create-react-native-app/blob/master/README.md#philosophy):

• Minimal "Time to Hello World": Create React Native App should reduce the setup time it takes to try building a mobile app to the absolute minimum, ideally on par with React web development (especially as seen with Create React App).
• Develop on Your Device: It should be easy to develop on a physical device when you want to test how your app feels and responds to inputs.
• One Build Tool: If you just want to get started with React Native, you shouldn't need to install Xcode, Android Studio, NDKs, or mess with environment variables.
• No Lock-In: You can always "eject" to your own build setup if you need to write custom native code or modify how your app is built.

In addition to everything offered by CRNA, Expo CLI also has these additional features:

• Web-based user interface: in addition to the CLI, there's a GUI where you can view logs, launch the app on your devices or simulators, and publish updates.
• Standalone app builds: you can build IPA and APK packages for deploying to App Store and Play Store without using Xcode or Android Studio.
• Publishing: you can push updates to your deployed apps and optionally publish your app to Expo.io.
• Tunnel: your physical device doesn’t need to be in the same wi-fi as your computer to be able to develop using it.
• Optional user accounts: logging in allows listing all your projects in development in the Expo app without having to scan any QR codes and enables additional features like standalone builds. However, just like CRNA, Expo CLI can also be used without a user account.

All apps originally created using CRNA also work with Expo CLI and like before, will be able to use Expo APIs in addition to core React Native APIs.

Why

• Just one tool to learn: previously developers would start with CRNA and then switch to exp or XDE for additional features like standalone builds. Expo CLI is as easy to get started with as CRNA, but also supports everything previously offered by these separate tools.
• Less confusing options: CRNA apps have always been loaded using the Expo app and able to use the Expo APIs in addition to the core React Native APIs. Users are sometimes confused about the differences between plain React Native, CRNA and Expo apps created with tools like exp or XDE. Installing the expo-cli package will make it clearer the additional functionality is provided by Expo.
• Developer experience: as described above, Expo CLI is ahead of CRNA in terms of features and developer experience, and we’re continuously improving it.
• Maintenance: having these two projects as separate codebases requires more maintenance and CRNA has previously falled behind because of this. A single codebase helps us keep it up to date and fix issues as fast as possible.

How

What will happen to the create-react-native-app package?
The create-react-native-app tool is used to create new CRNA projects. The old way to create a project was:

$ npm install -g create-react-native-app
$ create-react-native-app my-app
$ cd my-app/
$ npm start

After the migration, new projects will be created with expo init:

$ npm install -g expo-cli
$ expo init my-app
$ cd my-app/
$ npm start

Additionally, to ease the migration and to ensure that all existing resources and examples using CRNA will keep working in the future, we’ll make create-react-native delegate to Expo CLI by default (unless invoked with the --scripts-version or --reason flags):

$ create-react-native-app my-app
This command requires Expo CLI.
Do you want to install it globally [Y/n]?
Installing the package 'expo-cli'...
? Choose a template: (Use arrow keys)
❯ blank
  The Blank project template includes the minimum dependencies to run and an
  empty root component. 
  tabs
  The Tab Navigation project template includes several example screens. 

What will happen to existing projects and the react-native-scripts package?
When upgrading from react-native-scripts, users will need to change the scripts in package.json to use expo instead of react-native-scripts. The scripts were previously created like this by default:

  "scripts": {
    "start": "react-native-scripts start",
    "eject": "react-native-scripts eject",
    "android": "react-native-scripts android",
    "ios": "react-native-scripts ios",
    "test": "jest"
  }

This needs to be changed to:

  "scripts": {
    "start": "expo start",
    "eject": "expo eject",
    "android": "expo start --android",
    "ios": "expo start --ios",
    "test": "jest"
  }

After this the react-native-scripts can be removed from devDependencies. Running any of the scripts will install expo-cli, unless it’s already installed.

To ease the migration for existing users, we will publish an updated version of react-native-scripts that delegates commands like start, ios , android, and eject to corresponding expo commands automatically, so they’ll keep working even when the scripts in package.json has not been changed. It will also show a warning that explains how to update the scripts to use Expo CLI.

I'd like to start a conversation around how we can make it easier to do patch releases. My understanding is that a lot of this work comes from trying to manage cherry pick requests, ensure things merge cleanly, and work end-to-end.

Right now this seems like a very manual process. People comment with a commit they want merged, and then the people running the releases (for at least the last few patch versions this has been @kelset) try to cherry pick this commit onto the release branch. Often this doesn't merge cleanly and the maintainer is responsible for finding the other commits that are required to make it merge cleanly. Once it is on the branch they go through a manual process to validate that "everything" works. Essentially manually running our end to end flows.

A lot of other projects that do cherry picks have some automation set up to make this easier. I think we should too.

A bot could take the cherry pick requests and open PRs against the release branch. PRs kick off all the normal tests which means that as we beef up our tests this stage will be validated better as well. Community members are able to merge PRs against release branches so unlike normal PRs, these can be handled without someone from Facebook reviewing each one.

Would someone be interested in taking point on trying to identify the ideal workflow and if there are preexisting bots that we can use for this or if we need to build one ourselves?

What

The ability to attach to JSC directly to debug React Native JavasScript code.

Background

Currently, we use Chrome to run the JS code when React Native is in the debug mode. When we start the debug mode, a new web socket connection is established via the packager to an instance of Chrome. We then use Chrome developer tools to debug the JS code. Similar mechanisms are used in the VSCode debugger for React Native, and the Idea react native plugin.

Why

When Native Modules today use a synchronous API, Chrome debugging fails. Sync API for native modules are not common, and at many places, such module provide alternative async calls.
With Fabric, there would be many more cases that utilize the synchronous API. Fabric will also use the new JavaScript Interface (called JSI), which lets JavaScript hold references to C++ objects.
Both these cases may not debuggable with the current setup.

How

There are currently two possible approach to support debugging in the future for OSS React Native projects.

1. Support Synchronous debugging in Chrome. For this, whenever we move over from WebSockets to Sync-XHR whenever a synchronous API is encountered. This could be slow, and may not support the concept of Host Objects.

2. Use Node for Synchronous debugging - Currently VSCode uses this approach. Instead of starting Chrome, it starts up Node, and debugs node using the node debug protocol. Node has support for Synchronous HTTP/XHR, so this could be leveraged. We still need to see how JS holding references to C++ objects would work.

3. Debug JSC directly on the device - this seems to be the best approach, but may also require the maximum amount of work. Currently, Safari allows JSC on the device to be debugged directly. The JSC that we use in Android is pretty old and may not support debugging. We would need to find a good debugging story.

Side Note - We would also need to start supporting debugging Chakra in case of RN-Windows.

Introduction

I need to ensure the integrity of the js bundle loaded, specifically over OTA

The Core of It

Need to ensure the js bundle being loaded is approved and unmodified afterwards

Discussion points

Steps on how this could work:

1. Generate a key pair (ECC e.g.)
2. Use the private key to sign the bundle on the build machine
3. Bake the public key in the native app
4. After RCTJavaScriptLoader.mm downloads the bundle, verify the signature of the bundle using the public key.

That should ensure the owner of the private key approved the bundle, and it was unmodified after.

Thoughts?

Hello.
I work on an app who make pictures from camera and upload them to an API.
Currently i use "react-native-image-crop-picker" package from npm who work very well for resizing and compressing but lost the EXIF data.

Or i need EXIF , i opened a issue on "react-native-image-crop-picker" github but no response after few weeks.

Is there a way to compress and or resize image stored on device with react ? i tryed js lib like "piexifjs" but didn't found how to make it work :(

any advice are welcomed. thanks

Intro

This discussion was born in the RN core team, but since the discussion was fairly recent and lengthy we thought that moving it to an issue would be the best first step to reset our minds about it.

The Gist of it

React Native is has a lot of moving parts, and they all are slightly non-perfect: sometimes these bugs and limitations are not solvable in the short/medium term, so workarounds may be necessary. Or, at least, there should be "easy to reach" knowledge for everyone to know and not waste N hours in vain.

This is the "known issue" definition we agreeded on:

is a way more relaxed interpretation of the word issue: it is something that you will face when using React Native that may or may not be a bug, and is may not be caused by React Native. And when there is a known issue usually I can also expect a workaround to be written there.

What we want to solve is the when/where/how of this broader exposition of known issues, in order to avoid:

1. creating confusion/panic
2. creating too much overhead of work for maintainers

This would also double to help show gaps in the test suite.

Currently, we have a set of labels related to “components or families of components”, and those are indicated by the 🔶 emoji. But it's not covering all the components. And those issues are not all "known issues".

Remembering that it’s possible to give multiple tags to issues and even filter for multiple tags, some ideas have been proposed.

Approach A: issues are the focus

We do PRs to the docs, and to each component page we add a phrase like “To see how this component performs in the wild, you can check its related open issues in the repo” and we link to the open issues with:

Proposal 1

A new label created appositely "Known issue" + the component related label.
This would require the integration of the current list 🔶 emoji with (at least) all the other components listed in the left panel in the docs.

Proposal 2

A new set of label that will mimick 1:1 all the components listed in the left panel in the docs.

Approach B: documentation is the focus

In this scenario, every known issue will be present in the dedicated doc page for that component, in a section like:

## InputAccessoryView known issues

- [Doesn't support multiline `TextInput`s](https://github.com/facebook/react-native/issues/18997)
- [Can't use with a bottom tab bar](https://github.com/facebook/react-native/issues/20157)

With link to an eventual issue in the main repo, if it exists.

This is the closest approach to what happens currently, where usually PRs are submitted to docs to inform about "known issues" for specific things.

For some context, here are some issues that would fit the status of "known issue":

• facebook/react-native-website#425
• facebook/react-native#19859 (comment)
• https://facebook.github.io/react-native/docs/textinput#value
• facebook/react-native#20157
• facebook/react-native#18997

What should be the "final" approach in solving this? Let's discuss!

Introduction

Add event 'onPaging' for ScrollView component, for executing callbacks on each 'page-scroll' event.

The Core of It

So, when you add pagingEnabled to a ScrollView, there is (to my knowledge) no way to know 100% sure when you went to the next or previous page.
Right now I use the onMomentumScrollEnd event callback to determine my position and call an event when reaching a new page, but the problem with that is, that when a user scrolls too fast, the momentum doesn't end, and the callback isn't invoked on each new page. When scrolling fast, the callback is only invoked on the last page you reach.

So why would you need this? (example)

Imagine a bunch of data the user can swipe through, like a slideshow. Underneath is a pager with thumbnails where the user sees on which item they are. The data is not loaded all at once. Only the item you see and 9 items off-screen (so, 10 items in total). When swiping to the next item, the slideshow element detects a new 'onPaging' event and a callback is executed (can be anything, in my case, load some extra data and set the pager correct). When swiping real fast from item 2 to item 5, the callback is only executed on the last item. In this case, the pager jumps from item 2 to item 5, which is a clunky visual experience. If the callback were executed on each 'paging event', the pager could update smoothly.

The new callback could receive the same (or a very similar) event object as the onMomentumScrollEnd callback.

Discussion points

• do we actually need this, or is it possible to do this with existing code?
• if we need this, is onPaging a good name :-) ?
• if we need this, how does the event object look like?

Introduction

Following is mostly valid for iOS.
Currently react-native-cli doesn't provide any support for plugin developers to install and link native modules like frameworks, static libraries, projects.

One can write custom link script and register it in rnpm's postlink phase and "misuse" not very well documented local-cli link scripts. However even with this approach, plugin needs to carry it's native dependencies. With more and more packages, this is slowly becoming a problem. I'm already aware of clang's linker error "IOS build error duplicate symbols for architecture x86_64" caused by two plugins linking same library.

Another popular option is to manage plugin dependencies via cocoapods.
However IMO cocapods/carthage are kind of alien in world of react-native. User need to know, how to install it, how to create podfile, etc. Linking modules should be implementation detail and users should be able to link all modules with just single react-native link command.

The Core of It

For all above reasons I decided to work on project I internally call native-modules. It will:

• augment common native libraries (like fmdb) with package.json with instructions how it should be linked in react-native project. Such a modules will be published to npm and could be used by any rn plugin.
• provide new react-native linker (and new clean xcode project parser) which will install and link all dependencies registered in app package.json

Discussion points

I understand I'm pretty brief here, but before going to deep into describing specification I would like know, if there is broad interest in such a thing.

Introduction

I have some needs for multiples red buttons in ActionSheet. for example, "report", "delete", "withdrawal", etc. everything could be destructive (or dangerous) by needs.

The Core of It

Apple Developer's Human Interface Guidelines says like below. You can see word "buttons", "actions". This means it could be multiple item, right?

Make destructive choices prominent. Use red for buttons that perform destructive or dangerous actions, and display these buttons at the top of an action sheet.

However, React Native's ActionSheetIOS only allow one item with destructiveButtonIndex option. It was implemented like this.

Discussion points

How about you change the option so that it receives multiple indexes?

Introduction

isn't it?

The Core of It

How about making it softer color? ☺️
(like YellowBox)

These look like current implementations.

• iOS https://github.com/facebook/react-native/blob/1151c096dab17e5d9a6ac05b61aacecd4305f3db/React/Modules/RCTRedBox.m#L50
• Android https://github.com/facebook/react-native/blob/5c2720b089dd0fb277771b0ac8b0e7788c493e5d/ReactAndroid/src/main/res/devsupport/values/colors.xml#L3

Discussion points

• How about changing the red color?
• What color value is better?

So I am still fairly new, and one of the most frustrating things I have had to deal with so far is: When using community components there is no standard.

For example, checking if a user has permissions on the react-native-camera component compared to the react-native-contacts component.

For one there is a react-native android way to check permissions and then there is no lib for IOS, but its just expected that IOS doesn't need to be checked and will be automatically prompted.
Would be great to be able to check things the same way on both platforms

Introduction

React Native currently has 52 direct package dependencies which when traversed recursively include 589 packages! This nice little graphing tool show's the extent of the graph: http://npm.anvaka.com/#/view/2d/react-native

The Core of It

The recent compromise of the popular event-stream library brings to light the need for better auditing of the packages we developers rely on.
Given the popularity of React Native and the trust developers place in it, the dependency graph needs to be audited and significantly reduced.

Discussion points

1. Are there already efforts underway to improve this?
2. Is the community open to pulling more code into the library in order to kill dependencies?
3. Have dependencies been audited in the past?

Intro

With this issue I'd like to try and create a "one stop" for all the information available around the future re-architecture of the UI-Layer of React Native, codenamed "Fabric".

Terminology

• JSI: JavaScript Interface, it's a unified lightweight general purpose API for (theoretically) any JavaScript virtual machine. It enables every other piece of the rearchitecture. (dedicated issue)
• TurboModules: re-architecture of NativeModules, also using JSI. (dedicated issue)
• CodeGen: a tool to "automate" the compatibility between JS and native side. (dedicated issue)

TL;DR

From @axe-fb's blogpost, here's a temporary description of Fabric (please consider that this is not yet finalized, it may change in the future)

In the current architecture, all UI operations (like creating native views, managing children, etc). are handled by a native module called UIManagerModule. The React Reconciller sends UI commands over the bridge, which are eventually handled by this module and delegated to UIImplementation. This in turn creates shadow nodes that represent the layout tree and are passed to Yoga to determine the relative co-ordinates based on the Flex box styles that are passed in from JS.
In the new system, the UI operations are directly exposed to JavaScript as functions using the JSI interface described above. The new UI manager can then create ComponentDescriptors and the Shadow Nodes for specific view types (like Text, View or Images), and then communicate with Java/ObjC to draw platform specific UI.

Available Materials

It was first announced in the "State of React Native 2018" blogpost by @sophiebits.

In July, @hramos linked a broadcast of a tech talk that happened in FB, which covered the ongoing work on the new React Native architecture codenamed "Fabric": facebook.com/hramos/videos/10101317533036249 (go to 8:18 for the presentation start - audio is a bit bad)

Further down the line, it was presented at ChainReact Conf 2018 by @axe-fb in the talk "The State of React Native".

At ReactConf 2018 @axe-fb did a talk about React Native's New Architecture, which also explains the 3 concepts above: JSI, Fabric, TurboModule.

On twitter, @shergin shared a presentation about View Flattening -> https://twitter.com/shergin/status/1058393187079704576?s=09

On twitter, @kmagiera shown a early stage implementation of Fabric working on the RNTester app -> https://twitter.com/kzzzf/status/1064891715457294337

IN Q1 2019, @kelset published a high-level/beginner friendly blogpost about it: https://formidable.com/blog/2019/fabric-turbomodules-part-3/ and did a talk about the whole rearchitecture in April 2019 at React Edinburgh.

@kelset also did a more in-depth talk at React Advanced London in Oct 2019: youtube recording & slides.

As of early Jan 2022, a first version of the docs about Fabric are on the main reactnative.dev website.

SWM published a blogpost on how they added Fabric to one of their libraries: https://blog.swmansion.com/introducing-fabric-to-react-native-screens-fd17bf18858e

Q&A

This is also a place for questions related to this effort and its direction.

Intro

With this issue I'd like to try and create a "one stop" for all the information available around the discussion that has been going on for a long time within the Core team about this project - and explain the label.

The Gist of it

React Native is currently a huge repo. Would it make sense to move UI components (ScrollView, Switches, WebView) and Native Modules like PushNotifications, etc into a separate repos?

The basic answer is yes, and in the past few months this has started becoming a reality via a few proposals and some commits from the FB team.

You can check the full list of native components that are being considered for extraction/deprecation here, but proposals can also be about JS-only components.

Advantages

• Chance to deprecate older modules
• Make the codebase more approachable
• Reduce the Bundle size for projects that don't use the "extractable" components, which would lead to faster startup times for the apps
• Help the community move fast and enable pull requests to be reviewed and merged quicker
  Reduce the app size effect of adding React Native to an app
• Reduce the size of dev dependencies (this has been criticized in the past)
• Increase community contributions by reducing the size and complexity of the RN repo

Doubts (with "answers" to discuss about)

A) Should we define a roadmap that each "separation" will have to follow?

The rough rule, for now, is to follow this set of steps:

• version N: the proposal gets merged, new repo gets created and changelog communicates it
• version N+1: the component, if used by the main repo, triggers a Warning about deprecation
• version N+2: the code is fully removed and developers will need to rely on the new repo for it.

For "pure removal" of old code, this may happen in a "2 version" window instead (ex. the old NavigatorIOS, removal announced in 57 and will happen in 58).

This is still a WIP so feedback on how to make it better is appreciated. Ideally we'd have a dedicated document with the details on how the flow of an extraction works, so that everyone on the community can understand all the steps involved and can take ownership of a proposal for an extraction.

B) How would this affect platforms like React-native-windows?

Owners of those out-of-tree platforms should be involved in the conversations to ensure a smooth transition.

B1) What's the best way to ensure that Expo is not left behind when the components are moved outside?

C) Who would retain ownership (and "responsibility to maintain") the separated component?

For "extractions", the new repositories will live under the react-native-community umbrella. Details around npm deployment are still being discussed, expect a dedicated issue about that.

For "deprecations/removals" they will be probably be just removed from the main repo, and eventually "ported" to this repository for deprecated-modules by FB by developers that still need it.

EDIT: this has been massively edited to provide more informations about the slimmening and reflect the ongoing discussion. And since things are still moving, please keep an eye on this post because it will evolve more.

WebView not working any more as expected when used with inline HTML.

Goal

Discuss the breaking change before sending a PR to improve the current docs. It seems counterintuitive to add an originWhitelist wildcard in order to render inline HTML.

Background

This issue was migrated from facebook/react-native/issues/20464.

The regression was introduced in commit 634e7e1 by @mmmulani with commit message:

iOS only: Breaking Change: Restrict WebView to only http(s) URLs

Summary:
To prevent people from linking file:// or other URLs inside RN WebViews, default to not allowing those types of URLs.
This adds the originWhitelist to specify other schemes or domains to be allowed.
If the url is not allowed, it will be opened in Safari/by the OS instead.

This is not well documented in CHANGELOG which leads to unexpected breaking behavior. It is also not described as an iOS specific change.

What was the rationale behind the breaking change?

Expected Behavior

Use inline HTML in WebView by passing only the HTML code to render.

import React from 'react'
import { WebView } from 'react-native'

export default () => (
  <WebView
    source={{ html: '<h1>Hello world</h1>' }}
  />
)

Actual Behavior

WebView expects originWhitelist along with source to render inline HTML as suggested in in #19986's comment.

import React from 'react'
import { WebView } from 'react-native'

export default () => (
  <WebView
    originWhitelist={['*']}
    source={{ html: '<h1>Hello world</h1>' }}
  />
)

Introduction

As you know on Android, you can send intents to open other applications (including Settings), deep linking and more. For example, on Android P, if I was developing the Facebook application, I could give the user the option to open the following screen:

Using this intent:

Intent intent = new Intent(Settings.ACTION_CHANNEL_NOTIFICATION_SETTINGS);
intent.putExtra(Settings.EXTRA_APP_PACKAGE, packageName);
intent.putExtra(Settings.EXTRA_CHANNEL_ID, notificationChannelId);
startActivity(intent);

There is a library out there but only with specific cases https://github.com/lucasferreira/react-native-send-intent/blob/master/android/src/main/java/com/burnweb/rnsendintent/RNSendIntentModule.java (there are too many cases). And to be honest, I think this is quite important (core feature of the platform) to depend on an external library.

The Core of It

I think we should provide a standard way of opening intents in the core. Maybe it makes sense to have it in the Linking module?

Discussion points

• Should we add it as part of React Native? I think yes.
• Should be part of Linking module? I think yes but I don't have much knowledge of the core to be 100% sure.
• This change is Android only

P.S. I am working in a PR that should land soon so you can see it in action + code.

....

What's the differences bewtwee expo-cli and react-native-cli ?

Intro

This discussion was born in the RN core team, but since the discussion was fairly recent and involves a really small group of devs I decided it was better to use this to move the conversation forward (since it impacts all OSS and allows to clarify how the process works).

The Gist of it

React Native as an Open Source project has many peculiarities, among which the fact that the release cycle for open source is unrelated to the internal FB usage of the library.

For this reason, the release cycle has always been decided informally by members of the core, in particular (from my understanding) @grabbou and a few other devs over time.

The timeframe between a release and the next one used to be by-weekly up to a change in late 2016, when it become monthly. Lately with the introduction of some massive changes (ex. Babel 7) the last two versions 0.56 and (currently being released) 0.57 have lagged a bit behind to this monthly cycle.

This was caused because, of course, priority is given to make sure that the release pass some basic manual testing, and until we are able to generate the RNTester project and the RNTestProject we don't proceed to release.

Why standardise

The reasoning behind creating a more "formal/structured" list of steps for a release will allow the community at large to know at any given point why and how the next version is in a certain state, and avoid misscommunication/misunderstanding among the people handling the different pieces of a release. (so, basically, to improve the overall reliability of the process)

A release is, currently, composed of a few different steps, which I list here in the order they are usually (but not necessarely) done:

• a branch with the new version is created, ex v0.XX-stable
• the branch is tested and a commit to set the right semver is done (example). This commit is then tagged with an v0.XX-rcXX version so that the CI can npm publish it. This way we make it easily available for the community to test before doing the "proper" first release. Subsequent RCs can follow if some big bugs are found and fixed.
• after some time (2+ weeks) a first v0.XX.0 tag is created and the first "official" release for that version is avaiable to everyone. This timewindow is related to how buggy or easy to upgrade to the new version is.
• once v0.XX.0 has been out for 1/2 weeks the v0.XX+1-stable branch is created and the cycle starts all over again

A few extra notes:

• At any point between thev0.XX-rc0 and the first v0.XX+1-rc0 tags, on the v0.XX-stable branch cherry picks from the "non-stopping" master branch can happen to get some extra fixes or similar.
• a changelog must be written/created (more or less) by the time v0.XX.0 lands. This is currently mostly handled by @turnrye
• the documentation must be updated to default to v0.XX by the time v0.XX.0 lands. This means that can be bumped even during the RC phase. This step is also necessary to keep the PRs to the doc "clean" in terms of knowing which commits of master need to wait for v0.XX+1 to be merged. (this is mostly handled by @hramos and @charpeni)
• we currently use the issue section of the dedicated repo react-native-releases to try and keep everyone up to date with the status of each release.

Discussion points

Given that:

1. master keeps moving forward at a crazy fast pace
2. we want to "ensure" (or at least try) that each new release "works"
3. React Native is still not in 1.x semver (meaning, things can and will change! Check the Fabric issue for more details)

There are a few things to consider and discuss:

a) in what order should things happen?

Example, I think that we should not bump docs until the first RC version is released, and we should have the changelog ready for when .0 is out.

b) does it make sense to aim to a monthly release cycle?

We want to keep up the pace of master, but since the bus factor to move the release and bugfix is potentially high it may happen that things move slowly. Maybe we should consider releasing every X breaking changes or something other non-time related parameter?

c) should we remove the rc phase completely?

This was pointed out to me by @grabbou and @rozele earlier today: since we are not in 1.x it technically would make sense to start right away with a vXX.0 tag. And consider 0 as the "test bench". I am afraid this could backfire since there would not have been as much RC testing as there is currently, but again, we are not 1.x so if we can communicate properly to the community that "hey step into the .0 only if you are ready for the battle or wait for .1 for stable" it should be fine.

What do you think? Let's discuss!

Error: Unable to resolve module ./../react-transform-hmr/lib/index.js from /Users/zhangxin/Desktop/reactNative/App.js: The module ./../react-transform-hmr/lib/index.js could not be found from /Users/zhangxin/Desktop/reactNative/App.js. Indeed, none of these files exist:

• /Users/zhangxin/Desktop/react-transform-hmr/lib/index.js(.native||.ios.js|.native.js|.js|.ios.json|.native.json|.json|.ios.ts|.native.ts|.ts|.ios.tsx|.native.tsx|.tsx)
• /Users/zhangxin/Desktop/react-transform-hmr/lib/index.js/index(.native||.ios.js|.native.js|.js|.ios.json|.native.json|.json|.ios.ts|.native.ts|.ts|.ios.tsx|.native.tsx|.tsx)
  at ModuleResolver.resolveDependency (/Users/zhangxin/Desktop/reactNative/node_modules/metro/src/node-haste/DependencyGraph/ModuleResolution.js:209:697)
  at ResolutionRequest.resolveDependency (/Users/zhangxin/Desktop/reactNative/node_modules/metro/src/node-haste/DependencyGraph/ResolutionRequest.js:83:16)
  at DependencyGraph.resolveDependency (/Users/zhangxin/Desktop/reactNative/node_modules/metro/src/node-haste/DependencyGraph.js:222:485)
  at Object.resolve (/Users/zhangxin/Desktop/reactNative/node_modules/metro/src/lib/transformHelpers.js:149:25)
  at dependencies.map.result (/Users/zhangxin/Desktop/reactNative/node_modules/metro/src/DeltaBundler/traverseDependencies.js:316:29)
  at Array.map ()
  at resolveDependencies (/Users/zhangxin/Desktop/reactNative/node_modules/metro/src/DeltaBundler/traverseDependencies.js:312:16)
  at /Users/zhangxin/Desktop/reactNative/node_modules/metro/src/DeltaBundler/traverseDependencies.js:169:33
  at Generator.next ()
  at step (/Users/zhangxin/Desktop/reactNative/node_modules/metro/src/DeltaBundler/traverseDependencies.js:271:307)
  
  

Hi,
I'm a react-native newbie.
Just a question about FlatList renderItem Component performance and memory usage.

Which of below renderItem Components is faster in performance and which is memory friendly for a large list?

1:

class MyListItem extends React.PureComponent {
  render() {
    return (
     <View style={{width: '100%', height: 60}}>
       {
         this.props.size ===  30 ?
         (
           <View style={{width: 30, height: 30}}>
                <Text>test</Text>
           </View>
         )
         :
         null
       }
       <View>...</View>
     </View>
    )
  }
}

2:

class MyListItem extends React.PureComponent {
  render() {
    return (
         <View style={{width: '100%', height: 60}}>
           <View style={{width: this.props.size, height: this.props.size}}>
                <Text>test</Text>
           </View>
           <View>...</View>
         </View>
    )
  }
}

Thanks.

Introduction

With this discussion, I want to tackle a long lasting conversation that, like a wave, comes and goes in the chats of the React Native Contributors channels.

Historically, as umbrella organisations for react-native projects, there have been for a long time two entities:

• React Native Community
• React Community

And the conversations happened lately seemed to suggest that now there is no more the need for these two to be split.

(one of the main inspirations for me to write this was @brentvatne's talk at ChainConf 2017)

The Core of It

Since I started using React Native, I become more aware of how much developers rely on third party packages to quickly insert new functionalities in their projects (given most of them come from a Web background where this is the approach*).

While a portion of those are hosted in repositories owned by the single person, a few of the 'most used' were instead in React Community or React Native Community. The fact that these two orgs coexisted was always a bit confusing to me, and also created the doubt of a scattered community and a bit of a 'bias' towards one or the other (ex. "oh well if it's hosted on XXX it's better").

Over the past 6-8 months, the React Native Community organisation has become a de-facto "officially endorsed by FB" hosting components from The Slimmening (ex. WebView) and with this very repo and the releases one I become more aware of how much the community is a shaping force in the evolution of React Native.

But this is still history-in-the-making, and I strongly feel that we need to take this chance to resolve this duality, and by doing so establish some structure to it so that everyone can benefit from a trustful place to get involved.

I believe that, similarly to projects like Flutter or Ionic (IIRC), the whole React Native community would benefit from an org that, by enforcing a set of standards for all the packages/repos hosted in it and providing a common place for all the maintainers to help each other, provides quality code for everyone and set the example for everyone in the community.

In conclusion, here's what I'd like to see happen:

1. We write a manifesto to enforce in the React Native Community - we could use the Ocaml community one as starting point (this could happen via a proposal PR in this repo) **
2. We move the repos from React Community into React Native Community
3. When a repo joins the RNCommunity, the maintainer will join the React Native Contributors Discord and we will help them to make sure that the repo is in line with the others/the manifesto
4. Once the migration is done we publish a blogpost in the React Native website to increase awareness

Discussion points

1. Is everyone ok with this happening?
2. What do you think of the manifesto proposal? What should be in it?
3. What happens if a maintainer wants to stop? Or a repo stops following the manifesto?
4. Who owns the npm permissions to publish each pack?
   (this is also related to trying to avoid situations like the bitcoin miner last month using an OSS repo as vector of attack)
5. Is there any way we could make this compatible with sponsorships/making it profitable in some ways to create sustainable ways for people to work on their OSS repos? (related issue)

* on the other hand, mobile devs expect more of a 'all in one' solution

** this whole process would also automatically effect the Slimmening repos, for which there has been talks of creating some guidelines but nothing has been done yet - so yeah we can merge the efforts

so I was trying to build a Flat Roulette using FlatList. something like this

it is working as per the logic , but the scroll animation is too subtle and fast . i want to use my own Animation with custom Easing , duration etc . but cant find a way or even a workaround .
shouldn't there be something to define own Scroll Animation.

Currently we need to use nohoist is there any plan to introduce support for hoisting?

Introduction & The Core of It

In the Button docs here it shows an image which says: Fit to text layout. That is what I am searching for because my button always has full width. But neither in the docs nor in the button code here I can find something related to that. Can you please support? I have found nothing also here in the issues.

Discussion points

Is it easily possible to fit the width of the button with the title text as stated in the docs or not?

This issue is part of What do you dislike about React Native?.

The top voted answer was that upgrading React Native is painful, see #64 (comment).

The problem statement is very broad ("Upgrading is hard") and we would like to gather more context about the actual issues that people are experiencing. Please use this issue to list every piece of content you can related to upgrading React Native: your own stories, links to issues, blog posts, complaints or any other rants you can find. Thank you!

I am about to set up "Prettier" in my project along "ESLint" to keep it consistent across some open-source work that I do and easier for contributors to work without worrying about internal patterns.

I've noticed that we don't have a general "community" preset. There is "eslint-config-fb" that is used by React Native. Unfortunately, it's a part of a project that is not meant to be consumed by 3rd parties.

We also do have "eslint-config-callstack", which is the one that I was planning to use for the CLI. It has Prettier integrated as a ESLint rule and makes it really easy to fix all the issues within your codebase by just running eslint --fix.

However, I am afraid of several inconsistencies that this may cause across community project. For instance, there are projects that don't use Prettier or ESLint at all. There might be some that use a different preset.

Do we care enough to enforce a "standard" ESLint/Prettier config as a part of RNCommunity to make it consistent to contribute? Say, we have "react-native-community/eslint-config-react-native", which also becomes a "recommended" preset for React Native?

Or we don't care and every project is allowed to go on its own?

PS. If we do care, I am happy to do it. We can fork our "callstack" preset as it's already set up for being consumed from "npm" and just adjust the rules.

Edit: See our reply here: #104.

We, the React Native team at Facebook, would like to get a current list of all the things that people in the community are having problems with when using React Native. There are many discussions out there, and this has been done in the past, but let's have a fresh start and make a collection of things that we can then consider looking at in 2019. For now, we'll just make a list. Please don't expect any of these things to be prioritized and fixed right away. For me personally, this is helpful to learn more as I just joined the React Native team.

Please reply with all the issues that you are having with React Native. Keep your descriptions short and ideally link to other places with more context. Feel free to mention not just technical things but rather any issue that can be ascribed to the React Native project. Add hashtags if you like for easier categorization.

Please do not troll, rage, rant or insult people. Please do not comment here asking to merge your PRs or fix your issues right now. Open source discussions can get heated, but being angry about things won't help anyone make progress. If something has been mentioned already, please use the upvote/emoji buttons instead of repeating the same thing so that it's easier to see how many people care about each issue. Please make one comment per topic so that people can upvote just one thing at a time.

Hypothetical Example:

Not enough emoji

The React Native CLI barely prints any emoji and it reduces my satisfaction with React Native. I know that other members of the team have said they would enjoy using more emoji as well. Here is an issue that references emoji: facebook/react-native#22463 #emoji

• Why use emoji?

Introduction

This is a place for discussions around the upcoming "TurboModule" feature.

• Full proposal here: https://github.com/react-native-community/discussions-and-proposals/blob/master/proposals/0002-Turbo-Modules.md
• Previous discussions: #11

Terminology

• Fabric: just the UI layer re-architecture, to take full advantage of concurrent React architecture. (dedicated issue)
• JSI: JavaScript Interface, it's a unified lightweight general purpose API for (theoretically) any JavaScript virtual machine. It enables every other piece of the rearchitecture. (dedicated issue)
• CodeGen: a tool to "automate" the compatibility between JS and native side. (dedicated issue)

TL;DR

From @axe-fb's blogpost, here's a temporary description of TurboModules (please consider that this is not yet finalized, it may change in the future)

The JSI system can also be used to call leverage device capabilities like bluetooth or other sensors by exposing functions that JS can call. This is similar to how browsers expose functions like navigator.geolocation.getCurrentPosition that, when invoked in JavaScript, trigger the respective C++ call in the browser.
In the current system, a table with information about module names and methods is created. When JS calls a specific native module, the indices of the module and methods are passed to Java/ObjC, which then invoke the specific methods. The arguments and return values are also converted between JavaScript and JNI/ObjC objects.
[...] Now that we have a JSI object for "SampleTurboModule", can invoke methods on this JSI object from JavaScript. During the calls, we also need to convert JSI Values to JNI for argument parameters, and the reverse when sending back results.
Like in the current architecture, most types including boolean, strings, Maps, Arrays, Callbacks and Promises are supported.

Available Materials

At ReactConf 2018 @axe-fb did a talk about React Native's New Architecture, which also explains the 3 concepts above: JSI, Fabric, TurboModule.

IN Q1 2019, @kelset wrote a more high-level explanation in a blogpost: https://formidable.com/blog/2019/fabric-turbomodules-part-3/ and did a talk about the whole rearchitecture in April 2019 at React Edinburgh.

@kelset also did a more in-depth talk at React Advanced London in Oct 2019: youtube recording & slides.

Q&A

This is also a place for questions related to this effort and its direction.

Introduction

RNTester is in quite a bit of need of a revamp. This can serve as a bit of a discussion before a proposal on what to do is made. (This is based off of a discussion in RNCore)

The Core of It

• Make it obvious how to structure new examples in there and making it really easy to write automated tests for it (It is never quite clear if all the examples work)

Discussion points

• Can it be made easier for out of tree platforms to use? (see RNWindows' RNTester update process). Perhaps whatever is done to make this easier could also make it easier for out-of-tree components like WebView to make use of RNTester.
• Should a revamped RNTester make use of React Navigation?
• How could it be made clearer that all examples work at-a-glance? One possibility:

  For example, if every example had some sort of indicator next to it, for example a green square showing that it "worked", or a counter that increments on each call, or specific things like that

The problem

Enforcing React prop type safety via propTypes is dubious at best. We've been using Flow for a much stricter enforcement of these props for quite a while. Unfortunately, much of our codebase existed before we typed our React Components and thus a bunch of stuff is still using PropTypes or some mix thereof. For a long time we've had files that export propTypes as well as Flow types and we tried to keep them in sync. However, we want to discourage the usage of propTypes in favor of static typing and only have one source of truth for the APIs of these components. That source of truth is Flow.

An Aside

We have a couple of projects that want to use these Flow types as the source of truth. For example, using them to codegen native code for each component and ensuring the native components supports props of the same type.

The proposal

Deprecate and remove propTypes from core RN!

Right now there are a couple of different ways propTypes are being used.

1. Exposed as APIs from react-native’s main export
2. Components that still use createReactClass
3. Components that no longer use createReactClass but still define propTypes

For open source, since the propType APIs from our main export have been public for a long time, we probably need to actually move these out into a deprecated repo instead of just deleting them. Before we can move them out, we need to fully decouple the propTypes from the rest of the repo.

It is a lot of work to do this, but none of it is very challenging. I'm hoping we can label these individual pieces of work as "Good First Task" and enlist the help of the community. This is the order of changes I think need to be made:

Remove callsites from components:

For a list of files, see the issue here: facebook/react-native#21342

Move and Rename custom propType definitions

For these, I think we should create a new folder, react-native/Libraries/DeprecatedPropTypes. Many of these files have both the Flow definition and the propTypes definition. Split means split these into two files, in the example of EdgeInsetsPropType it would mean having an EdgeInsetsPropType.js file that contains the commented flow types, and a DeprecatedEdgeInsetsPropType.js file inside the DeprecatedPropTypes folder. Eventually that folder will become the source for the new repo that we move out. There are two reasons I'm proposing renaming to have a Deprecated prefix. One is that Haste requires files to have different names. The other is that it will catch our internal usage of these modules. We have an internal lint rule that will start detecting callsites and yelling at teams to remove these requires (because they will include Deprecated in the name).

For a list of files, see the issue here: facebook/react-native#21342

Once these modules are all separated, we can move them to a new repo, perhaps something like facebookarchive/react-native-deprecated-prop-types. react-native can add a devDependency to that repo for a while to support the remaining callsites in core (there are still a few createReactClass callsites that do complicated things with mixins which will take much more work to remove.

Once this new repo exists, we can add deprecation warnings to react-native-implementation.js:

get ColorPropType() {
  // some deprecation warning, tell people to change their requires
  return require('react-native-deprecated-prop-types').ColorPropType;
},
get EdgeInsetsPropType() {
   // some deprecation warning, tell people to change their requires
  return require('react-native-deprecated-prop-types/lib/EdgeInsetsPropType.js');
},
get PointPropType() {
  // some deprecation warning, tell people to change their requires
  return require('react-native-deprecated-prop-types/lib/PointPropType.js');
},
get ViewPropTypes() {
  // some deprecation warning, tell people to change their requires
  return require('react-native-deprecated-prop-types/lib/ViewPropTypes.js');
},

I'm specifically looking at this as a call for help. Both in getting all this work done, and in reviewing and landing PRs. Are there any concerns with this approach or better/easier ways we can go about getting this all done?

Introduction

I would like to be instructed how to make successful Ajax request to SOAP server with enough control over its initialization.
I described my issue thoroughly on SO where I think I wont wait for the answer.
I was redirected here by bot from facebook/react-native#21376.
If there is something I should add more, please ask and I will give more information.

The Core of It

https://stackoverflow.com/questions/52527219/how-to-make-proper-soap-request-from-react-native-0-56-with-jsc-android-224109-x

We already know that the AirBnB style guide discourages using .bind() inside the render function (source). As explained here:

A bind call or arrow function in a JSX prop will create a brand new function on every single render. This is bad for performance, as it will result in the garbage collector being invoked way more than is necessary.

this is what we used to do, passing the param into bind

renderSingleItem = ({item}) => <TouchableOpacity onPress={func.bind(this, item.id)}>
return <FlatList data={data} renderItem={this.renderSingleItem}/>

and this seems to be the only way since the param of onPress in React Native doesn't contain target object like ReactJS do.

ReactJS:

typeof event.taget === 'object'

React Native:

typeof event.taget === 'number'

Is there a better approach for this?

Many issues suggest that Parallelize Build must be disabled in order for subprojects to be compiled in the proper order. I have a project with quite a lot of non-react subprojects, that takes too long to build without Parallelize Build being enabled.

I'm running react-native 0.50.4, using Cocoapods.

Shell-quote is listed as a high security risk node-module. Refer to the report (https://nvd.nist.gov/vuln/detail/CVE-2016-10541) containing the detail about it in National Vulnerabilities Database.

Please help me in fixing this issue.

Introduction

I believe that W3C Pointer Events would be a perfect fit for inclusion in React Native in the future.

This discussion could serve as brainstorming for what various APIs/restrictions could be in place if these were implemented, or if this should be done at all.

The Core of It

They enable handling these kinds of inputs from the same event:

• touch - Already supported by current (and upcoming) RN APIs, but allows for code that handles all 3 types.
• mouse - Useful for desktop platforms, Android, and RNDom/RNWeb. Includes info on which button was pressed.
• pen - Could handle the Apple Pencil on iOS, Galaxy Note stylus (and others) on Android, Wacom, Surface Pen (and others) on desktop platforms. Includes pressure and tilt info.

The additional event props added would be:

• onPointerOver
• onPointerEnter
• onPointerDown
• onPointerMove
• onPointerUp
• onPointerCancel
• onPointerOut
• onPointerLeave
• onGotPointerCapture
• onLostPointerCapture

Of the bits of Fabric that are currently open sourced, there's a great W3C touch events implementation in the works:

https://github.com/facebook/react-native/blob/188cbb04ad264aea32ae235b85b61e626b767b83/ReactCommon/fabric/components/view/TouchEventEmitter.cpp

I suspect that a lot of this could be built on top of the work done on that. When Fabric is released, it'll be easier to reason about this.

Discussion points

• Should there be new components for pointer events in the vein of <TouchableWithFeedback />, like: <PointerPressWithFeedback />, <PointerOverWithFeedback />, etc?
• Being able to handle touch events in the Touch Events implementation and in Pointer Events might be seen as redundant. Is this an issue? If so, is there a better way to support desktop events in core react native? (Level 2 of Touch events will support Styluses too, so an additional area where it could be redundant)

Hi,

First and foremost I'd like to thank you and all the OS contributors for the effort going into this project and enabling so many people to write performant native applications with a single code base and with a great tooling. Me and my team love to hack with react-native.

Currently we use Carthage extensively at my team for dependency management on iOS. I wondered whether it would be possible to use react-native with Carthage as a dynamic framework. This is because
a) we don't want to mix and match multiple dependency management solutions
b) we could cache react-native as a dynamic framework. This way the dependency with all of it third-party dependencies could build one time and after that the CI server could use the cached version.

I think the approach of using react-native as a dynamic framework would increase the build time of our application by a huge factor. Also currently the whole react-native dependency is located in a dynamic framework of ourselves. This framework is then added to an app target which forces us to link the whole Xcode project of our framework and build the sources on the app build because we can't just integrate our framework via Carthage. This is mainly due to the fact that the dynamic framework of ours would need to export all the relevant react-native headers in order to import the framework correctly.

I would love to hear your thoughts whether
a) Carthage support is planned
b) if the support for Carthage is not on your list how we should deal with the current dependency problematic. We currently have to rebuild the whole react-native Xcode project for every app build on our CI server. This leads to huge increases of our build time and prevents us from benefiting the fast iteration cycles react-native could offer.

Also if no support for Carthage is planned maybe someone could help out with a sample project or script which includes the static react-native library and exports the headers correctly so we could maintain a dynamic wrapper framework to achieve our goals ?

Since react-native dropped support for iOS8 in 0.56.0 I guess providing a dynamic framework for iOS has no real disadvantage because since iOS8 dynamic frameworks are supported and could help a lot of people as other issues already have stated.

I am happy to hear your answers and to start a discussion about this.

Right now (in 0.56 and the first RC of 0.57) you need to modify jest/hasteImpl.js and local-cli/core/index.js so Metro and Haste can find your platform's JS files, as can be seen with windows (facebook/react-native@5494274) and dom (facebook/react-native#20393)

@matthargett has a pull request in the main RN repo tackling this: facebook/react-native#20662

I have not turned this commit into a PR yet, but I think that an additional "haste" key could be added under a platform's "rnpm" entry in package.json (much like how it works with jest, see here)

Example:

{
  "rnpm": {
    "haste": {
      "providesModuleNodeModules": [
        "react-native-foo"
      ],
      "platforms": [
        "foo"
      ]
    }
}

My commit: empyrical/react-native@d7a0c6b (I have opted not to make a PR until more discussion is had)

I think that also whatever way is added to support custom platform plugins makes its way in, there should be some sort of unit test added in with a dummy platform to help ensure that custom platform support is unbroken. A simple little test fixture with the bare minimum files required for a successful bundle to be built. I will probably take a stab at this too.

Hi,

I dont believe this feature is added yet, therefore I post this in the proposal board. So please consider it a proposal too for something that would be neat if it is not existing yet.

Anyway,

I have not been able to find any way, by which I can achieve this in React Native. And there does not seem to be any post on it yet, so I hope it is okay that I ask:

Is it possible to first of all add any sort of http proxy to a webview? What I want to achieve is to route the browsing traffic through a proxy (that is running Privoxy), which can strip the HTTP content in the communication for tracking scripts and ads.
I can do it on a full-fledged desktop browser, and through global-setting on the iphone which routes all traffic on the iphone through the proxy (the IP and port number of the proxy can be set in network settings on the iPhone).... That is not userfriendly though.

Is it possible to have just a webview achieve this? I cannot seem to get access to any sort of underlying http client or anything in it, so I cannot do something hacky either :/

If it is not possible, is it then possible for react native apps to use a VPN? I have not found any libraries that gives me access to that yet. If I have one, then I can setup an app-wide VPN hopefully, which can reroute all the traffic to a vpn server that sends it through the Privoxy server, and then it works as well! :]

Hope to hear from you, if it is possible to setup any proxy or VPN logic on either the webview or app-wide in a react native app :) Thanks!

NB. What I want to make is an app, where users can browse privately without fear of being monitored and profiled for what they browse and buy.

Hi Guys!!
I am quite new in react native as well as the programming. I am using expo and I am trying to read data from WordPress. but the problem appeared when the post contains a video. .

the video is running well but the video size showed inside the is bigger than the screen size.
I have tried scalesPageToFit={true}, However it did not working for me.
Is there any way to solve this issue?

`import React, { Component } from 'react'
import { View,WebView, Dimensions, Image, Text } from 'react-native'
import HTML from 'react-native-render-html'
import moment from 'moment'
import Entities from 'html-entities'
import sanitizeHtml from 'sanitize-html'
import { Grid, Row, Col, Button} from 'native-base';
import Config from '../Config'
import PostImage from './PostImage'
import PostMeta from './PostMeta'
import PostVideo from './PostVideo'
//import Video from 'react-native-video';
const window = Dimensions.get('window')
const entities = new Entities.AllHtmlEntities()

const styles = {
featuredImage: {
backgroundColor: 'black',
width: window.width,
height: 200
},
title: {
fontFamily: 'roboto-slab-regular',
fontSize: 20,
lineHeight: 22,
marginTop: 16,
marginHorizontal: 16
},

content: {
    flex: 1,
    height: 400, 
    alignItems: 'center'

},

meta: {
marginTop: 16,
marginHorizontal: 16,

}
}

export default class Post extends Component {
webview = null;

constructor(props) {
    super(props);

    this.state = {
        tamanho: 122,
        post: props.post,
     scalesPageToFit: true,

    };
}

_postMessage = ( ) => {
    this.webview.postMessage( "Hello" );
    console.log( "Posted message" );
    scalesPageToFit=true
}

_receivedMessage = ( e )  => {
    console.log("Received message");
    this.setState( { tamanho: parseInt(e.nativeEvent.data)} );
            scalesPageToFit=true

}

componentDidMount() {
    this._postMessage();
}

render() {
let post = this.state.post;

let HTML ='' +
'' +
'<title></title>' +
'' +
'' +
post.content.rendered +
'' +
'';

let javascript = 'window.location.hash = 1;' +
'document.title = document.body.scrollHeight;' +
'window.postMessage( document.body.scrollHeight );';

return (


{entities.decode(post.title.rendered)}

         <Grid>

            <Row>
                <Col>

                    <WebView 
                    scrollEnabled={false}
                
                        ref={webview => { this.webview = webview; }}
                        injectedJavaScript={javascript}
                        javaScriptEnabled={true}
                        javaScriptEnabledAndroid={true}
                        onMessage={this._receivedMessage} 
                        scalesPageToFit={true}
                        allowsInlineMediaPlayback={true}
                        decelerationRate="normal"
                        automaticallyAdjustContentInsets={false}
                        style={styles.content}    
                        domStorageEnabled={true}
                        startInLoadingState={true}
                        source={{html: HTML}} 

                         />

                </Col>
            </Row>
        </Grid>

</View>

);
}

}`

I find it painful to maintain an ActionSheet with entries that can dynamically change.

I would like to propose a change of the showActionSheetWithOptions() signature so that the cancelButtonIndex, the destructiveButtonIndex and the buttons callbacks would be contained in the options array alongside the labels.

showActionSheetWithOptions({
  title: "My ActionSheet",
  options: [
    {
      label: "First Button",
      onPress: () => console.log("First Button pressed")
    },
    {
      label: "Cancel",
      onPress: () => console.log("Canceled"),
      cancel: true
    },
    {
      label: "Delete",
      onPress: () => console.log("Deleted"),
      destructive: true
    },
  ]
})

The goal is that these indices would be taken care of by the library and not the user. It would then be simple to add or remove a button from the options. I did implement this like that:

 showActionSheetWithOptions(
  {
    options: options.map(o => o.label),
    title: this.project.name,
    cancelButtonIndex: options.findIndex(o => o.cancel),
    destructiveButtonIndex: options.findIndex(o => o.destructive),
  },
  index => {
    options[index].onPress && options[index].onPress();
  }
)

but I think it could be done directly in React Native.

I think this is the place to discuss such changes, if not please tell me where :)

Introduction

This conversation started during the last core meeting, when talking about Facebook and Community involvement in moving this project forward.

This issue wants to serve as the 'main focus' around this topic, and some of its subjects are actually explored more in-depth in dedicated issues. Please remember that the the purpose of this discussion is to make the overall environment better for everyone involved: we (community and FB members alike) all love React Native and want to collaborate in the best way possible to see it become (even more) awesome.

The Core of It

React Native is an Open Source project created by Facebook - it is used internally, and the GitHub repository serves as a mirror of the commits that land in the internal react-native-github directory in Facebook's monorepo.

The Open Source version is consumed by the broader developer community through npm releases, that are currently maintained by a restrict group of members of the React Native core team - coordination and decision making about them is (mostly) handled via a dedicated community repository, react-native-releases.

Members of the community are also involved in maintaining the main repository: help with issue triaging (and labelling, and closing) and PR reviews (and a few members are also able to trigger the import process).

Another two, more recents, ways the community is getting more involved in shaping the future of React Native are:

• this very repository, for discussions and proposals and increasing transparency between FB <-> the Core team <-> the broader community
• the Slimmening process

This increasing involvement is helping the project move forward faster, and to reassure everyone of the huge commitment of all the parties involved in seeing RN succeed.

But, as most other Open Source projects, there is an underlying issue which is sustainability: while the FB team is paid to work on React Native, all of the tasks listed above that are handled by the community are not*.

This can generate issues of many forms that mostly boil down to reliability/stability/consistency of involvement in said tasks.

So: what can be done, by all the parties involved, to make sure that both RN and the community continue to be healthy?

Discussion points

1. FB is still (pretty much) owner if RN:
   1. Well, first off, it legally is
   2. It’s an FB repo
   3. Commits from FB lands on master without going through the PR process
   4. Facebook experiments with additional improvements that may or may not make it out to open source, for example additional bundle formats
   5. Landing PRs is locked by FB importing it via the custom internal flow (which historically slowed a lot of PRs from landing)
   6. the technical expertise is very concentrated within FB
2. How can we make more members of the community more involved, what is the nature of the core, is it needed? (dedicated discussion)
3. Can some of the tasks handled by the community made more automatic, in order to reduce the workload? (dedicated discussion about the release cycle)
4. Is there a funding model to support OSS community work that could fit this? So that companies like FB could pay into.

* or, at the best of my knowledge, not directly - best scenario I am aware of is companies giving their developers work hours to dedicate to those tasks

i know react-native will rearchitecture in <State of React Native 2018>
who can tell me the progress of rearchitecture？

Introduction

It seems like support for allowsBackForwardNavigationGestures is not working with useWebKit={true}. Is there any plan to support this feature?

Introduction

I'd like to make SectionList item's keys as a combination of information from item and section.

The Core of It

I have multiple sections with the same items in them, and instead of using an ever changing index as key (changing when filtering the list) I'd like to make a item+section combination as key. I'd would be helpful having a keyExtractor of the form item -> index -> section -> string.

Can it be done? Should it be done? I'm I posting this in the right place?

Introduction

Out of the box, react-native is for building Android and iOS (and TvOS?) apps, so react-native init starts us of with an android and ios folder and project. However we have seen more and more effort to see implementations for new platforms (windows, MacOS, web (react-native-web or react-native-dom), desktop alltogether) which shows us that react-native is more than just iOS and android.

The Core of It

I understand that Facebook started react-native having mobile in mind, but should it stay like that?

Or should we try to move react-native as a Platform that let's you choose which platform you target and treat all of them equally in terms of difficulty to "Add a platform".
I'm imagining a world where you could start a React Native app with only iOS in it, but then add platforms as you go in an easy way, the way react-native-windows seems to handle it.

In the same way, you could start a React Native app with only windows, and then add MacOS and Linux support iterations after iterations.

So I guess the discussion is : should the integration of all platforms be equal (and not have 2 that are "preferred"). Platforms concerned by this discussion being:

• Android
• iOS
• Windows (should UWP and WPF be considered 2 platforms?)
• MacOS
• Linux
• TvOS (which I think should be decoupled from iOS apps, although, as I am not an iOS dev, maybe it does not make sense)
• Android TV
• web (not sure if that should be in scope of this discussion, or should there be a React vs React Native web discussion)

Discussion points

• Is it too early to discuss? (Would this be much easier after the "end of the slimening"?)
• Is it even possible?
• Is it something we want?

Disclaimer :
I haven't tried all the frameworks mentioned above and haven't read all the information which is out there about the slimening and the objectives of React Native, so feel free to tell me to go read the docs and close that issue if this direction is already decided/discussed 😅

Introduction

This discussion is related to the main "sustainability and community involvement" conversation going on in #58.

This issue wants to focus on the 'Core team' aspect, since there are opinions on its importance & role & nature; how to make it more inclusive and diverse is the core question.

The Core of It

My understanding is that, in the early days of React Native, a Slack group was created to help the FB team and the most active non-FB maintainers communicate. Over time, more people were invited to said Slack, which ended up acting as the hub to coordinate the tasks and efforts of the more involved members of the community.

Recently, since the community at large as become more 'central' to the Open Source side of React Native, this and the releases repos were created to create a more neutral and transparent place for these communication to happen.

But a portion of the conversations still happen over in the real-time world of Slack, and this may generate the perception that the Core is an exclusive club without clear rules or boundaries over what gets decided, or who can be included in it.

Discussion points

1. How can we make more members of the community more involved, hence part of the core?
2. Is there a natural limit of people after which said group would be too big to manage/coordinate?
3. Should we have a sign-up form of some sort? Should we keep inviting people directly?
4. What's a good rule of thumb about what makes a core contributor?*
5. Given that the community at large is scattered across many different platforms, how can we better communicate with all of them?

* I find this video from Gatbsy a good source of inspiration for it