Skip to content
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

Reply from Facebook about "What do you dislike about React Native?" #104

Closed
cpojer opened this issue Feb 26, 2019 · 14 comments
Closed

Reply from Facebook about "What do you dislike about React Native?" #104

cpojer opened this issue Feb 26, 2019 · 14 comments
Labels
👓 Transparency This label identifies a subject on which the core has been already discussing prior to the repo

Comments

@cpojer
Copy link
Member

cpojer commented Feb 26, 2019

More than two months ago in #64 we asked "What do you dislike about React Native?". We have since made progress at Facebook on our incremental rewrite of React Native, via Fabric (#4) and TurboModules (#40), and started deprecating and removing many modules as part of the Lean Core effort. We reduced the number of open pull requests to ~70, compared to ~280 in December, by merging most of them and closing only the ones that weren't applicable any longer. Simultaneously, the average number of Pull Requests that get opened against React Native increased from ~3.5 to ~8 per day.

We are finally done replying to all of the issues that were mentioned in #64. Please read
this comment to understand how we generated this list. I recommend you get a beverage of your choice (coffee?) or a snack and take a break before jumping into this fun read:

Upgrading requires a lot (too much?) effort #

Upgrading from one version to another is hard and requires a lot of work. Especially when you have fallen a couple of versions behind and have to manually upgrade from yours to the latest version by version.

  • Votes: 572
  • Tags: upgrading
  • Estimated time to fix: ~3-6 months
  • Point of contact: Christoph Nakazawa (@cpojer)
  • Comment by Facebook: We asked for more information on GitHub and have a good overview of the problems, however it will likely take a long time and more discipline to make this problem go away entirely. The problems are related to breaking changes, native modules and template changes that are hard to understand. Since then we have integrated rn-diff-purge into react-native upgrade (to be part of 0.59) and we will make Cocoapods the default way to install native dependencies on iOS. We are also planning on writing detailed blog posts that list breaking changes for every release and are looking for ways to integrate this information into the CLI. We will do a more thorough audit of the template to see which parts we can move back into React Native to make upgrading easier.

Debugging exceptions #

I dislike that it's often not really easy to find the root cause of an exception. The stack trace in Chrome debugger console often leads to ExceptionManager and not the original place, which lead to time consuming debugging. Using componentDidCatch does not really help.

image

Surprisingly, when we add a console.error() in our code, we are actually able to get a correct stacktrace and find the root cause easily. It would be very convenient keep this behavior even inside componentDidCatch.

Support of React Native team #

Would be nice to see a bigger involvement from react-native team to the community.

Examples:

  • many github issues are unanswered
  • blog posts on good practices for advanced problems
  • Votes: 240
  • Tags: communitySupport
  • Estimated time to fix: Continuous
  • Point of contact: Christoph Nakazawa (@cpojer)
  • Comment by Facebook: As you may have seen, in the past few months we started a significantly higher investment into the React Native community. As one example, we reduced the number of open pull requests to ~70, compared to ~280 in December, by merging most of them and closing only the ones that weren't applicable any longer. Simultaneously, the average number of Pull Requests that get opened against React Native increased from ~3.5 to ~8 per day. We are also planning to triage open issues around March 18–20 but we would like to ask for continued help by the open source community to help maintain our issue tracker – we can only do this as a community. We are also hoping to rewrite our documentation to be much easier to understand.

Performance, performance, performance #

First of all, I am an Android user. I don't use an old phone, I use Pixel 2 which is one of the top game. It's still noticeable when an app is in greenfield or not. Mostly, startup time. Startup time is quite crucial difference between pure native and RN. Not only when you open the app but for deep linking too. Imagine clicking an Android widget that opens the app, in RN the waiting time is just slow. You can mask that with a splash screen, brownfield apps, etc. But it's just a workaround. The feeling is not "native".

One of the problems on this has been navigation too. I think the problem here is that Facebook probably just uses its own navigation system (native app that has some RN views). So they don't really need to help or invest in a common solution. That is a pity. When you develop an Android app or an iOS app, you don't need to care of navigation performance (mostly). It just works.

  • Votes: 232
  • Estimated time to fix: 2019
  • Point of contact: React Native team at Facebook
  • Comment by Facebook: We are currently working on a significant amount of incremental rewrites and changes to React Native. You can find more information here: Fabric, TurboModules, Lean Core. While none of these in isolation will help with performance, once we are done with all of the projects we have ongoing we believe React Native will be significantly faster and feel more “native”. React Native 0.59 will come with a brand new version of JSC on Android that should be significantly faster, we will enable optimizations (“inline-requires” and “RAM bundles”) that should result in ~10-30% speed-ups over the course of this year and we are also working on some stuff you'll hear more about soon.

Metro follow symlinks #

Currently Metro does not follow symlinks, which makes it harder for the community to:

  • use monorepo tools like LernaJS
  • iterate on internal RN libraries, when the project is split on multiple packages (using npm link)
  • contribute to RN open-source libraries and actually testing your own changes in an example project

Related issue:

  • Follow symlinks? facebook/metro#1
  • Votes: 195
  • Tags: dx, packaging, symlinks, metro
  • Estimated time to fix: 1 month (actual coding time: a few days, get it shipped + released will take a while)
  • Point of contact: Christoph Nakazawa (@cpojer)
  • Comment by Facebook: This has been Metro's top voted issue for the entirety of its existence. We'll fix this so that people will stop running into this frustrating issue.

The solution to lots of problems is rm everything and re-install #

I think there could be better documentation around how to recover from the kinds of issues that are frequently resolved by a "fresh install". We could also codify the nuclear option as a feature of the CLI, so that react-native nuke rm's everything that should, clears watchman, reinstalls node_modules etc.

Edit: it's clear to me that RN is overwhelmingly complex, and solutions like "fresh install" are the code equivalent of "turn it off and on again". The complexity isn't the problem. You're doing good work. It's just that I think we could understand root causes better, and help people get un-stuck sooner.

  • Votes: 168
  • Estimated time to fix: ?
  • Point of contact: Christoph Nakazawa (@cpojer)
  • Comment by Facebook: Please see the response to the first two answers about upgrading and debugging.

General Uncertainty. Lack of confidence #

The vibe I'm getting from some clients [citation needed] is general terror about the future viability of React Native.

Some decision makers at some companies seem to be holding off on any investment in React Native. They've heard that it's being "rewritten". To them, that means that the current status quo is to be avoided like the plague.

Seems like there needs to be some clarity in the messaging. Something to build confidence and certainty about the status quo and the long term viability of the platform. Some ammunition that engineers can use to get decision makers on board.

  • Votes: 144
  • Estimated time to fix: continuous
  • Point of contact: React Native team at Facebook
  • Comment by Facebook: We’ve seen more companies adopt and contribute back to React Native and the ecosystem in the last 6 months than in the year before that. Major companies like Microsoft, Amazon, Walmart, Pinterest, Zynga, and tons of others use React Native and the future of the platform is bright. We look forward to sharing more about the work Facebook and others are doing for React Native and improving our communication to reduce the uncertainty in the community.

Missing documentation #

I feel like there are many hidden advanced features inside RN that are only documented in issues and that usage is found only in advanced libraries, without knowing if the API is official or stable. As a library author it could be helpful to have at least some doc on these APIs. I'm thinking of ScrollResponder, UIManager etc. Even a simple link to the implementation code would be helpful, because navigating the RN native codebase using Github interface is not so easy for a JS dev.

  • react-native-keyboard-aware-scroll-view: one project using undocumented apis
  • Votes: 141
  • Tags: dx, documentation
  • Estimated time to fix: 2019
  • Point of contact: React Native team at Facebook + Core Contributors
  • Comment by Facebook: We are planning on rewriting our documentation this year and we are hoping on significantly improving our website to make it easier to work with React Native.

Built in SVG Images #

I'd like to be able to use SVG images without having to convert it to a font or other hacks that have been attempted (webviews, etc).
When using the same code between my web react apps and native, I have to convert images especially ones that are dynamic.

  • Votes: 115
  • Estimated time to fix: done
  • Point of contact: React Native Communty
  • Comment by Facebook: The community has built some well maintained packages to natively support rendering SVGs. We want to enable these packages to iterate and improve and thus have no plans on building it into React Native. We recommend using one of these packages or building your own and sharing it with others.

Debugging #

Debugging by running the JS in Chrome is a clever solution, but quite clunky. For example, it requires restarting the app, it causes problems with some native modules (e.g. react-native-gl cannot be included in an app you want to debug), and is not that useful for debugging performance issues as the JS is being debugged running on a different machine. Ideally there would be some way to connect directly to the JS running on the device while still using the great debugging tools provided by Chrome.

  • Votes: 109
  • Estimated time to fix: ?
  • Point of contact: React Native team at Facebook
  • Comment by Facebook: On iOS it should be possible to use the Safari Dev Tools to debug the VM directly. A JSI based debugger for Chrome is currently being worked on at Facebook.

Not resilient to crashes #

It happens very often to me that I did something wrong and the app crashes (at least on Android) without a lot of informations about the cause. When it happens, adb logcat can be helpful to find the cause.

Some examples:

  • Using style=width: "100"`` and forgetting the %
  • Using this.props.number && (<View/>) in JSX when number=0
  • Probably a lot other cases I can't remember

I think it would be nice if RN was more resilient to these kind of errors, did warn with a clear error message and did not crash the app.

  • Votes: 109
  • Tags: dx, debugging, crash
  • Estimated time to fix: ?
  • Point of contact: Christoph Nakazawa (@cpojer)
  • Comment by Facebook: We'll look into this as part of the debugging issue 2 on top of this document.

Documentation for library developers #

Currently there is not much documentation to help library developers aside from the introduction guides (iOS, Android). It would be good to have documentation for the full native API to make it clearer what classes and methods are available to use. These could be generated using JavaDoc and AppleDoc.

  • Votes: 106
  • Estimated time to fix: 2019
  • Point of contact: React Native team at Facebook
  • Comment by Facebook: As part of the website rewrite and the work on TurboModules we will look into updating our documentationfor developing native modules. We want to help the community build and maintain high quality libraries so we will be doing work in this area to make the process as smooth as possible.

Warnings in Xcode #

A lot of Warnings when you open react-native/ios app in Xcode.

Style, StyleSheet and optimizations #

Many of us think that StyleSheet API does optimize styles. But it never did and since 0.55 it's an identity function. It's not really clear to me how to write future proof styles today as I don't know the internal FB discussions about this API.

Also want to mention that a lot of people do like to write styles inline, colocated to the markup, like the css prop of emotion of style props of glamorous-native. I think it would be nice to offer today an alternative to StyleSheet API for these people, and ensure this inline API will benefit the future style optimizations.

  • Emotion CSS prop
  • Styled-components CSS prop
  • Glamorous-native built-in components
  • React-Native-Web StyleSheet implementation: based on Atomic CSS and seems to be performant, this could inspire the strategy to use for ReactNative StyleSheet
  • Votes: 102
  • Tags: built-in-glamorouscomponents, dx, styles
  • Estimated time to fix: -
  • Point of contact: -
  • Comment by Facebook: This issue assumes that styles with React Native are not performant, which is not the case so there is nothing to be done to optimize them at this time. There may be an opportunity for us to improve our documentation to make sure people do not assume that the StyleSheet API is slow. We will not be adding a new API for defining styles at this time but that shouldn't stop you from exploring alternative solutions and building your own React Native styling libraries.

Hot reloading #

Hot reload does not work great with functional components currently. It would be awesome to be able to hot reload reliably any RN code without reloading the app, showing the splash screen etc... Tools like react-navigation persistance and storybook help to improve DX on restart, but having a functional hot reload would be the best. Not sure how hot reload will work with FC including hooks but if classes disappear from codebase this may make the things worse. Doesn't it make sense to build a babel plugin to transform FC to class in **DEV**?

ObjC / Java vs Swift / Kotlin #

I'm sure this one comes up a lot and I understand the scale of work that is needed to rewrite rn in these languages, however I found Swift and Kotlin much friendlier for people familiar with JavaScript. This can lead to more OSS contributions and custom native modules from JS devs, since learning curve of Swift / Kotlin is not as steep as ObjC / Java.

Another side effect of adopting these as main languages is that documentation and new third party repositories will likely utilise them, so in general ecosystem becomes a bit more understandable for js devs.

  • Votes: 97
  • Tags: dx
  • Estimated time to fix: ?
  • Point of contact: React Native Community
  • Comment by Facebook: At the moment we are using Objective-C and Java for our codebases at Facebook and we cannot add either Swift or Kotlin to our apps. Since Facebook runs React Native from master, we cannot at the moment rewrite React Native to use either Swift or Kotlin. With our work on Fabric we are actually moving more code from Objective-C and Java to C++ and members of the community have expressed their interest in building alternative app templates that will use Swift and Kotlin instead of Objective-C and Java. There is no timeline for this work.

Consistent KeyboardAvoidingView #

It is almost impossible to know how to properly configure KeyboardAvoidingView, partially because the documentation is so ambiguous on when to use what behavior, partially because its inconsistent across uses based on other circumstances (In/near a scrollview, etc).

I feel a solution could possibly just be better documentation around it, or adapt a strategy like react-native-keyboard-aware-scroll-view

https://github.com/APSL/react-native-keyboard-aware-scroll-view

  • Votes: 78
  • Estimated time to fix: ?
  • Point of contact: React Native Community
  • Comment by Facebook: We realize this component is currently not high-quality and has many issues. We use this module extensively at Facebook and would appreciate either a new third-party module that covers all use cases across platforms well or incremental and non-breaking changes to React Native itself. Send us some pull requests!

PRs #

Mostly we believe it is better to send a PR (solution) than open an issue. However, lots of PRs including mine, are just labelled and left forgotten forever. That just makes people stop contributing.

  • Votes: 70
  • Estimated time to fix: continuous
  • Point of contact: Christoph Nakazawa (@cpojer)
  • Comment by Facebook: See "Support of React Native team" above, as one example, we reduced the number of open pull requests to ~70, compared to ~280 in December, by merging most of them and closing only the ones that weren't applicable any longer. Simultaneously, the average number of Pull Requests that get opened against React Native increased from ~3.5 to ~8 per day.

Android Inconsistencies #

Android is still a second class citizen. Many issues apply only to Android that are fine on iOS and lead to many devs missing Android issues during development.

Examples:

  • {0 && <View />} will crash on Android. Any unexpected falsey value will cause Android to crash with no error screen. You MUST ensure it is a boolean value that is returned. iOS handles this fine.
  • On Android, you cannot name a property flex or the app will crash
  • Toggling secureTextEntry has been broken for years

I'm sure there are many other examples, but Android should be a primary focus for development going forward to better support the claim of being cross platform.

  • Votes: 69
  • Estimated time to fix: ?
  • Point of contact: React Native team at Facebook
  • Comment by Facebook: Yeah, we should fix this. We will appreciate Pull Requests from the community that will help us out on this.

Network request monitoring #

As network requests are proxied, it makes it difficult to track requests and payload responses without third party tools (examples below), suggested workarounds from the issue attached allows you to view the network request leaving via Chrome debugger, but it never returns.

React native Debugger
Reactotron
Charles

facebook/react-native#934

  • Votes: 61
  • Tags: dx, debugging
  • Estimated time to fix: -
  • Point of contact: React Native Community
  • Comment by Facebook: This is definitely important but it will require work from the community. Please feel free to start a new issue to outline the work that needs to be done, and then work on Pull Requests to enable this functionality.

Upgrade CameraRoll to use the iOS Photos Framework #

The current CameraRoll is based on ALAssetsLibrary which was deprecated in iOS 8 😳. This API cannot access photos which are stored in iCloud, which most people use. This results in lots of headaches and confusion both for developers and for app users.

facebook/react-native#21836
facebook/react-native#20462

  • Votes: 57
  • Tags: images, photos
  • Estimated time to fix: Done!
  • Point of contact: Joshua Gross (@JoshuaGross)
  • Comment by Facebook: This will be fixed in React Native 0.59.

Not keeping up with Android updates #

I have Android P. Border radius (ripple) and other stuff are broken. I can't see how this is not a priority. This give discredibility. You have your new shiny phone, new shiny OS but your RN looks bad. See for example:

TouchableNativeFeedback's ripples aren't affected by borderRadius on Android 9

  • Votes: 57
  • **Estimated time to fix: ~**July 2019
  • Point of contact: David Vacca (@mdvacca) and React Native Community
  • Comment by Facebook: We are working on upgrading RN to Android X.

Native Navigation #

I would love react-native-navigation to be moved to the RN community, or forked, and get priority support by the RN team.

I feel some don't understand the importance of having the ability to build native look and feel apps.

I think with the upcoming JSI, this could be a serious player in our ecosystem.

  • Votes: 56
  • Estimated time to fix: -
  • Point of contact: React Native Community
  • Comment by Facebook: We have our own native navigation system at Facebook that is not open source which we have to support already so we are probably not best suited to help maintain solutions in open source. If you would like to move existing projects to React Native community, please ask the maintainers and start a discussion with them.

react-native link issues #

Running react-native link can link the same library multiple times or mess up the formatting of it.

  • Votes: 56
  • Estimated time to fix: ?
  • Point of contact: React Native Community
  • Comment by Facebook: We are currently working on recommending CocoaPods by default for iOS projects and with it we are looking to simplify link to cause fewer problems for people.

Cross Device/Platform Push Notification Support #

Right now you have to use several different libraries depending on platform for push notifications and app badging. I would like a consistent and known/documented way to implement push notifications across all devices.

  • Votes: 55
  • Estimated time to fix: -
  • Point of contact: React Native Community
  • Comment by Facebook: This is definitely an important part of most applications and we recommend the community to rally together to identify a solution that can be easily integrated with React Native. Right now we are looking to reduce the surface area of React Native core so this will have the most support by living in the community.

Support for more native components out of the box - Like camera, video, audio, fingerprint.. #

Lack of many out of the box native components. We have to always go for third party library solutions for accessing many native features. It would be nice to have more out of the box components in the future.

  • Votes: 50
  • Tags: SmallEcosystem
  • Estimated time to fix: -
  • Point of contact: -
  • Comment by Facebook: Actually, we are going the opposite direction and we are actively removing components from React Native as part of the Lean Core effort. We realize that it would be convenient for React Native to have more components out of the box but modules are already being better support living in their own repos and maintained by the community than they ever were when they were part of core. We plan on recommending CocoaPods by default for iOS to make the process of using and linking 3rd party modules easier. We also hope that people will create templates that have a predefined set of modules packaged together to provide functionality that most people need or that expo or ignite will work for you.

Open Source Contribution Process #

Having the Github repo be a mirror of an internal Facebook repository complicates the process for third-party developers to contribute to the React Native core. The process from submitting a PR, getting it approved, then merged into the internal FB repo, and then finally released is quite often a long process.

The would work ok if releases were regularly made from the master branch, however, until the 0.58 release comes out the release process involves an additional step of asking for a cherry pick to be performed in the react-native-releases repository.

For the casual contributor, this is not an obvious process and could lead to confusion and frustration about when a fix with an approved and merged PR is actually available in a release. This is compounded by the fact that the changeling doesn't directly reference the PR numbers and no comment is left on the PRs to say which release they are now available in.

Related discussions:

Automatic Scroll on addition of elements at index 0 of ScrollView / Flatlist #

Adding messages on both sides of ScrollView/Flatlist shouldnot allow automatic scrolling. There should be a prop onPause to allow developers use it so as to disable automatic scrolling and remain on the same viewport on addition of messages at index 0.
There is one support for ios maintainVisibleContentPosition in the scrollview, can we have it for android as well to solve the same use case as mentioned for this, that is chats; and have a proper documentation around it.

maintainVisibleContentPosition : When set, the scroll view will adjust the scroll position so that the first child that is
currently visible and at or beyond minIndexForVisible will not change position. This is useful for lists that are loading content in both directions, e.g. a chat thread, where new messages coming in might otherwise cause the scroll position to jump. A value of 0 is common, but other values such as 1 can be used to skip loading spinners or other content that should not maintain position.

  • Votes: 46
  • Estimated time to fix: -
  • Point of contact: React Native Community
  • Comment by Facebook: It seems like this is a specific feature request which is best handled in a Pull Request. If you would like to see this feature, please build it!

Cocoapod support #

Cocoapod is not well supported. It breaks quite often when upgrading. Breaking are so regular that @orta build a plugin to autofix react native issues: https://github.com/orta/cocoapods-fix-react-native.

Merge of @ashfurrow issue below:

When building React Native apps using CocoaPods, things get complicated. We have to do a lot of work in our Podfile to reference podspecs within the node_modules directory:
https://github.com/artsy/emission/blob/471a4cd13629122f30d2e9ee67deb0294b6349e7/Example/Podfile#L16-L21
Further, React Native won't work out of the box and requires version-specific fixes: https://github.com/orta/cocoapods-fix-react-native There is an RFC to improve things with more context and details here: #18
Ideally, I could do something like the following in my Podfile:
pod 'React' # or 'ReactNative' or whatever
And it would handle all the transitive dependencies, etc for me.

  • Votes: 46
  • Tags: buildtools
  • Estimated time to fix: ?
  • Point of contact: React Native Community
  • Comment by Facebook: We are currently working on improving CocoaPods support inside of React Native as well as making it the default for iOS projects and we have already landed a few pull requests to move us to the right direction. Stay tuned!

Outdated dependencies #

One example would be ws, which is currently at 1.1.5, but needs to be at least 3.3.1, according to this.

  • Votes: 45
  • Estimated time to fix: In progress
  • Point of contact: Christoph Nakazawa (@cpojer)
  • Comment by Facebook: This particular dependency was already upgraded and as part of the Lean Core effort we are working on upgrading and auditing our dependencies.

View Recycling #

React Native sometimes feels like it disrespects the platform by reimplementing basic functionality instead of providing a super thin layer to the mature underling platform stuff.

For example, scrolling lists with view recycling.

Android and iOS handle this differently. But both platforms do handle it. When writing a mobile app, I want to feel confident that I'm using the highest perf most mature stuff.

That being said, I haven't used React Native for a while. For all I know, there may be some awesome view recycling built in for free now. It certainly could theoretically do a great job at that. And come to think of it I do vaguely remember something about that from however long ago.

So maybe this is just a marketing/documentation thing?

  • Votes: 42
  • Estimated time to fix: -
  • Point of contact: React Native team at Facebook
  • Comment by Facebook: Our latest abstractions like FlatList and Fabric should address this.

Unwelcoming first experience #

Recent example:

react-native init demo
cd demo
vim index.test.js
describe('Test', () => {
  it('should be true' () => {
    expect(true).toBe(true)
  })
})
> npm test
Test suite failed to run
Couldn't find preset "module:metro-react-native-babel-preset" relative to directory "~/projects/demo"

This is not the first time that we have a public release where the things out of the box do not work as expected. I understand that it's a huge challenge to make different libraries and it's version work together but it also creates frustration when you want to do simple things.

Usually, the process requires to google around for solutions to the problems. Typically, it leads to react-native project issues on Github. Scanning through the comments it takes multiple attempts to try out different things to resolve the problems. It would be valuable to have a well-documented known-issues document with collected knowledge how to resolve it.

  • Votes: 41
  • Estimated time to fix: ?
  • Point of contact: React Native team at Facebook + React Native Community
  • Comment by Facebook: This is indeed a big problem and we are working on improving our testing strategy for new releases so that people will not run into these kind of issues again.

Developer Experience #

I think we should pay more attention to the tools (as per your hypothetical example in first post) and try to make them more fun and pleasant to work with. Right now, they are very "raw" and often print cryptic errors. Making them more interactive and snappy would contribute to overall feeling its much more stable and "polished".

  • Votes: 40
  • Estimated time to fix: -
  • Point of contact: -
  • Comment by Facebook: See the top issues in this document which should improve developer experience significantly once we are done.

Styling Shadows on Android #

Shadows on Android is managed by elevation, so in your code you have to add more styling lines to manage Android shadows. I feel that using shadow CSS properties make it easier to implement shadows wherever you need it in a consistent way.

  • Votes: 40
  • Estimated time to fix: -
  • Point of contact: -
  • Comment by Facebook: This seems like a concrete issue that is better handled as a GitHub issue or GitHub PR, please discuss it there.

Official Camera Module #

I try to use a lot of cameras libraries, but all have a lot of issues. I think that is a required module for any framework to develop a mobile app.

  • Votes: 39
  • Estimated time to fix: -
  • Point of contact: -
  • Comment by Facebook: We are not planning on adding a camera module to React Native. Please use react-native-camera instead.

Support developers who want to help build react-native itself #

As you can see, there are hundreds of people in this thread alone who are passionate about making react native as good as it can be. Since the facebook team (obviously) has limited capacity, community contributions should be more valued by the core team. I know that they are valued, and that you do a lot of work to make react-native open to all of us. Many of us could help solve the issues found in this thread! I think the challenging part is having a PR sitting open for months (or years) or even having a valid issue raised that you aren't sure how to fix yourself because you don't know how the core code works.

As it stands, there are hundreds of open issues and PRs. As someone using react native for a couple years most every day, I would love to contribute. But to do so, we need a better (official) understanding and documentation of the internal architecture of react native.

  • Votes: 38
  • Estimated time to fix: -
  • Point of contact: -
  • Comment by Facebook: Please see the issues above that discuss how we have become significantly more responsive to Pull Requests in the past few months. We are looking forward to your Pull Requests and will aim to respond much faster than we used to in the past.

Accessibility and Internationalization #

Some issues are voiced here in a way that is a bit too aggressive for my tastes: http://www.takingnotes.co/blog/2018/11/09/react-native-accessibility/.

But there is a grain of truth to it:

This is especially sad to me because the now deprecated NavigatorIOS and TabBariOS had great Accessibility and Internationalization support built in. (Because they were wrappers around the native navigation containers.)

I know the React Native team cares about deeply about Accessibility and Internationalization by the work they have already done. (See https://facebook.github.io/react-native/docs/accessibility) However, I don't see this improving until the Navigation Container Primitives are pulled into core: (Navigation Controller, TabBar, etc.) Something like an official react-native-screens that other Navigation API's can build atop of. Because the Navigation solutions merely built on the native View element will constantly be breaking Accessibility and Internationalization in hard to detect ways.

  • Votes: 37
  • Tags: right-to-left-rtl-layout-support, nuanced-platform-specific-behavior, Accessibility, Internationalization, native-navigation-api
  • Estimated time to fix: -
  • Point of contact: React Native Community
  • Comment by Facebook: This is a very important issue that needs to be addressed. We recently merged two RFCs about accessibility: Actions and Roles but we need your contributions to improve accessibility in React Native.

Better Triaging of Github Issues #

Aside from the mentioned technical issues here, the primary thing that has driven me away from using React Native on projects was the state of the Github issues. There were many issues that I found or were subscribed to that got closed by a bot or someone on the team “cleaning up stale issues”; all of which were not fixed and some which were certainly not stale (reproduced on the latest build comments were being added).

There has to be a better way of utilizing community involvement to triage and/or reconfirm issues. There are many comments here that I can remember being issues that were ultimately closed without a fix. So it’s not surprised that they are being mentioned here.

I believe the first step would be to have a clear way to reopen an old issue that was never fixed. We could then work on a process where the community could help triage issues. This would ultimately help drive community code contribution.

  • Votes: 35
  • Estimated time to fix: continuous
  • Point of contact: Christoph Nakazawa (@cpojer) and Héctor Ramos (@hramos) and the React Native Community
  • Comment by Facebook: We will run a triage session around March 18–20 and hope to get our issue tracker into a more manageable state. However, the volume of issues we receive is huge and it is hard to keep up without our bots that help us manage the load. We would like to ask the community to help us out with triaging and sending Pull Requests to fix the issues people are running into.

Very slow response times for Github Issues #

It seems there are tons of Github Issues and PRs that no React Native contributors get to. I'm know this is a busy project, and I'm thankful you've done so much work, but TypeScript team, for instance, has consistently triaged and solved almost every Github issue I've made for them within a few days of posting, which makes me love that project even if it doesn't have all the functionality I'd ideally want, but get very frustrated with this one.

  • Votes: 34
  • Estimated time to fix: -
  • Point of contact: -
  • Comment by Facebook: See the issue right before this one.

No True Multi-Threading / Javascript Based Background Services #

I'd love to see another attempt at multi-threading/integration with background services. It would be hugely beneficial to be able to write services in javascript as oppose to using the bridge to communicate with a native module that will manage a purely native service.

There has been a few attempts in packages such as React Native Background Task but most don't play well cross-platform and all have drawbacks in one area or another. I'd love to see a true react-native implementation of this.

As an Example:
Developer A wants to build a fitness app. The app needs the ability to track location changes, speed changes, etc. Ideally this app would run in the background and track the users activity through-out the day, without needing the application to be open in the background.

  • Votes: 33
  • Estimated time to fix: -
  • Point of contact: -
  • Comment by Facebook: This should be handled in a separate issue as it relates to a concrete technical problem.

Precompiled RN in iOS #

While android by default load precompiled aar, there is no support for equivalent in iOS yet, hence quite long build times. Supporting precompiled RN on iOS (carthage or framework) would increase the build speed by a lot.

  • Votes: 31
  • Estimated time to fix: -
  • Point of contact: -
  • Comment by Facebook: This should be handled in a separate issue as it relates to a concrete technical problem.

Windows and Linux are second class citizens #

The experience developing for React Native is horrendous in these platforms. The file watchers don't seem to catch on to file changes very often. Worst of all, hot reloading often only works for the first five or so times, and then from then on it just gets stuck completely, and I would have to restart the bundler over and over again.

I've tried before on my (not preferred) MacBook (that I since don't have anymore), and despite my not liking macOS, file watching and hot reloading worked 100% perfectly without ever the need to restart the bundler.

Although I don't expect to be able to develop for iOS without a Mac (because Apple doesn't allow it), I would really appreciate if React Native were either actually cross-platform, or at least Facebook would admit that they are not focusing on Windows or Linux.

  • Votes: 30
  • Estimated time to fix: ?
  • Point of contact: React Native Community
  • Comment by Facebook: This is definitely an important issue to fix but we'll need help from the community both to identify concrete issues and with PRs to fix those issues. If you are affected by problems mentioned in this issue, please investigate and send us a fix.

Everything that's not React #

As a JavaScript developer, I had never seen or been exposed to Xcode or Android Studio before. I feel like most of my dev time is spent troubleshooting Xcode/Android studios. react-native link doesn't seem to be consistent for all libraries, and you have to end up doing weird things just to get something working. I recently had to make an upgrade to the build.grade of a file inside one of my nod_modules.

Getting so many warnings in the console about deprecated code, like for dependencies on the Java side: compile is deprecated in favor implementation really worries me.

  • Votes: 30
  • Estimated time to fix: ?
  • Point of contact: React Native Community
  • Comment by Facebook: We are addressing this in many ways as you can see from our response to other issues before this one. However, we are also planning on improving our documentation and hope this will get easier over time.

Inconsistent EcmaScript features between Android/iOS #

Android doesn't have things like Proxy, so libraries like mobx (version 5) or oc-typescript etc. won't work at all.

First thing I do with a fresh RN project is to replace the JavaScriptCore with newer version in android.

I think documenting what this is all about, each platforms limitation and so on could be a good step forward.

  • Votes: 29
  • Estimated time to fix: Done!
  • Point of contact: -
  • Comment by Facebook: With React Native 0.59 we are shipping a brand new version of JSC on Android thanks to community contributions. Finally!

Not having better official tooling for motion based interface #

User nowadays expect a lot more from apps than when RN was originally released and yet we still need to recur to the community or build from scratch solutions for motion based interfaces like shared element animation transitioning.

  • Votes: 28
  • Tags: ux, animations, dx
  • Estimated time to fix: -
  • Point of contact: -
  • Comment by Facebook: This is something best handled in a third-party tool by the community instead of increasing the surface area of React Native.

Real time crash and performance monitoring tool #

Lack of official or community adopted real-time crash and performance monitoring tool, we do have tools like Newrelic mobile, react-native-sentry, bugsnag but none of them solves all the use-cases.

  • Votes: 28
  • Estimated time to fix: -
  • Point of contact: -
  • Comment by Facebook: This is indeed very important but shouldn't be part of React Native's core. The solutions outlined are all very good tools and hopefully they can be improved to cover more use cases.

A lot of issues while using inverted lists #

Inverted lists are common UX for different kind of applications with a chat ability. But the current implementation of the inverted list has a lot of issues and some missing features.

Some issues:

Missing features:

  • ability to use two-way (for the beginning and the ending of the list) refresh controls
  • callback for two-way onEndReached, if you have reached top and bottom of the list.
  • Votes: 27
  • Tags: flatlist, inverted, sectionlist, lists
  • Estimated time to fix: ?
  • Point of contact: React Native Community
  • Comment by Facebook: This is indeed a problem many people are running into. This is best handled in concrete Pull Requests but it is definitely a hard technical problem that isn't straightforward to fix.

Orientation changes & landscape #

This is another topic quite ignored in RN in general. We just do not have a solution. Mostly RN apps are just locking orientation to portrait. A thing that is not recommended in the mobile world.

  • Votes: 23
  • Estimated time to fix: ?
  • Point of contact: React Native Community
  • Comment by Facebook: This is a concrete technical problem that is best discussed via Pull Requests.

Official Camera && Video && Audio Modules #

wish there were official support for cross platform multi media handling with caching capability

  • Votes: 23
  • Estimated time to fix: -
  • Point of contact: -
  • Comment by Facebook: Please use react-native-camera and react-native-video instead. We are not looking on adding more components to React Native's core.

0.x and dependencies #

The ecosystem of libraries and compatibility with react and react native is up in the air and a game of chance. Can I upgrade this 3rd party library? Well, since we don't know if there's any breaking changes because no one follows semver versioning properly we just have to try and see. Errors might not surface right away and it is just a mess.

Fix: bump to 1.0 and mark breaking API changes according to semver

(yes, I know technically semver allows any breaking changes in 0.x, but with the whole ecosystem around and 3rd party libraries it becomes a mess and 0.x in this case should be avoided asap)

  • Votes: 22
  • Estimated time to fix: ?
  • Point of contact: React Native team at Facebook
  • Comment by Facebook: We are still moving fast and we are incrementally rewriting React Native right now. As outlined in our Open Source Roadmap we are working towards a 1.0 release but it will likely take a while before we get there.

Lack of Documentation Around Breaking Changes #

When upgrading between versions, including minor/patch versions, there are often breaking changes that either aren't documented at all (example: this CLI argument change that broke the Storybook packager script), or mentioned with no real description of what kind of stuff might break or how to migrate (ex. the switch to Babel 7).

The decision not to upgrade dependencies in minor versions is a really good step in the right direction here, but it would still be nice to have some kind of docs when 0.58 drops that explain issues that could come up as a result of, say, any Metro updates, and how to migrate the code as a result.

  • Votes: 22
  • Estimated time to fix: -
  • Point of contact: -
  • Comment by Facebook: See the first reply in this document. We will work on better surfacing breaking changes in future releases in hopes to address this issue.

Payment APIs #

Having to go to a third party to handle In-App-Purchase APIs is not ideal because that's how most apps make money and people have more confidence when the APIs are provided by a backed team like Facebook instead of an individual or a small company in country X.

There are many libraries to do IAP, some platform specific and some for both.
Example this: https://github.com/dooboolab/react-native-iap

  • Votes: 22
  • Estimated time to fix: -
  • Point of contact: -
  • Comment by Facebook: We recommend this to be handled by third-party plugins and we are not looking to include such a module into React Native core at this point.

Performant list and input #

FlatList and TextInput lacks of memory management and should be faster.
This amazing video at Chain React 2018 already addresses it, but I think this should be mentioned here anyway: https://youtu.be/83ffAY-CmL4

  • Votes: 20
  • Estimated time to fix: -
  • Point of contact: -
  • Comment by Facebook: This is a concrete technical problem that is best discussed in GitHub issues and Pull Requests.

More stagnant modules should be moved out of core #

I'm a big fan of the slimmening but I think there should be a more aggressive effort to extract stagnant modules from react-native core and move them into the community. I'd like to see this happen with pretty much all the (mostly deprecated) platform specific components and APIs. Then more effort can be put into improving the stability and performance of truly core components like Image or TextInput.

  • Votes: 19
  • Estimated time to fix: In progress
  • Point of contact: Christoph Nakazawa (@cpojer)
  • Comment by Facebook: We are working on it as hard as we can as part of the Lean Core effort. Join us!

AppRegistry and lifecycle documentation incomplete #

Looking at the documentation for AppRegistry, you can see that there are a lot of methods without any form of extended description. Though their names are mostly useful, the methods that do have an extended description offer better insights into how and when they should be used.

The best example of this is the mysterious rootTag which took me days just to figure out how to use for asynchronous application bootstrap.

  • Votes: 19
  • Estimated time to fix: 2019
  • Point of contact: Christoph Nakazawa (@cpojer)
  • Comment by Facebook: Thanks for the feedback! We'll consider it when we rewrite the documentation.

Native and React Lifecycle event mismatch #

Often have the issue while bridging that the ReactJS lifecycle events on the JS thread, are not consistent with the Native lifecycle events. We need more documentation on advanced and specific bridging issues.

  • Android RN Module: Native module lifecycle event onHostResume needs to call JS function, but ReactJS lifecycle didn't register eventListener yet. (Solution was to call from JS componentDidMount the native initialiser)
  • Android RN view: Javascript renders a custom native view. Bridge calls createViewInstance which needs to inflate a view and call a factory method to initialise it, but because it is called from render it's too soon. Had to be called onActivityStarted on app level (RN package level was too soon)
  • IOS: in the scenario where the app has been opened, a cast session started and the app has been closed, you want to attach to the already opened cast session when the app opens again.

You do this, but a RCT_EXPORT_MODULE init method will be called before viewDidLoad, so hasConnectedCastSession will be called too early and be false.

Having a 1/1 on RN view/(ios-scene/android-activity) would probably fix this issue (and provide native navigation support?)

  • Votes: 19
  • Tags: bridge, documentation
  • Estimated time to fix: ?
  • Point of contact: React Native team at Facebook
  • Comment by Facebook: We'll look into it.

Inconsistent Style Attributes as Component Props (instead of style) #

Some components like TouchableHighlight and TextInput have inconsistent style properties that get passed in as props instead of using StyleSheet style, like

<TouchableHighlight underlayColor={...} activeOpacity={...}> where it would be a lot easier to theme components if everything related to visual style was passed in to the style prop.

This is also the case with <TextInput placeholderTextColor={...}>.

  • Votes: 18
  • Estimated time to fix: ?
  • Point of contact: React Native team at Facebook
  • Comment by Facebook: This is a good point. We'll look into it as we work on improving our core components.

zIndex behaviour on iOS #

zIndex on iOS only works relatively to nodes which are brothers. Instead I would like to have it work as Android and the web, and have the zIndex which works in an absolute manner. I had some use cases where the design was really hard to implement on iOS because of that whereas it was trivial to do so on Android.

  • Votes: 18
  • Estimated time to fix: ?
  • Point of contact: ?
  • Comment by Facebook: We currently have no answer for this. Please open an issue on GitHub to further discuss this.

Android overall feels like a second-class citizen #

There are many components that have iOS-only features, or features that have very poor equivalents in Android. There are also many performance issues - FlatList loading a lot of images works smoothly on iOS, but loads extremely slow on Android. (See react-native-snap-carousel's repo, there are a lot of issues discussing alternatives to FlatList for Android)

Seeing as how Android has a much bigger marketshare worldwide, I find it unacceptable that it gets treated like a lesser platform.

Also, as a side-note, I feel like Windows for development is treated as Android is for developing on. Most guides focus on mac, a couple on Linux but very few guides for Windows. With WSL becoming more complete each day that passes, I feel the community could standardize on bash tooling and guides be written without platform-specific focus when this isn't needed.

  • Votes: 18
  • Estimated time to fix: ?
  • Point of contact: React Native team at Facebook
  • Comment by Facebook: Android is definitely a very important platform for us at Facebook and we are hoping to equalize the differences between iOS performance over time.

Images by default don't have size. #

When I place an Image I would like to see that Image, but since I haven't specified a size it's not displayed. This default behaviour seems weird to me, when you place an Image it should be visible by default regarding if you entered width and height styling attributes. I remember wasting quite a lot of time figuring out why my Image wasn't displayed before understanding it.

  • Votes: 16
  • Estimated time to fix: ?
  • Point of contact: React Native Community
  • Comment by Facebook: It seems like this can be fixed via better documentation and error messages.

Database & Offline #

This is another topic. In RN docs there is just AsyncStorage. Is that enough? Well if you are a mobile developer you know it is not. You can go now with Realm or WatermelonDB. But it would be good if the core invest more on this (as is one of most important mobile capabilities). And add some guidance about that.

  • Votes: 16
  • Estimated time to fix: -
  • Point of contact: -
  • Comment by Facebook: We are not looking to add storage solutions into React Native. Please use a third-party module for this.

Warnings #

I don't like the react-native init experience - it prints many warnings, has not many colours and I find it really hard to follow. I think I got used to that over time, like many other developers doing React Native on a daily basis. However, initialising the app for the first time ever may give false conclusion that there's actually something wrong with the app.

This is also true for many other places, like Xcode or Android builds. Others have mentioned this earlier.

  • Votes: 16
  • Estimated time to fix: In progress
  • Point of contact: React Native Community
  • Comment by Facebook: The CLI was recently moved out of React Native and is now being more actively maintained and improved. See this blog post for more information.

Better support for CocoaPods #

When building React Native apps using CocoaPods, things get complicated. We have to do a lot of work in our Podfile to reference podspecs within the node_modules directory:

https://github.com/artsy/emission/blob/471a4cd13629122f30d2e9ee67deb0294b6349e7/Example/Podfile#L16-L21

Further, React Native won't work out of the box and requires version-specific fixes: https://github.com/orta/cocoapods-fix-react-native There is an RFC to improve things with more context and details here: #18

Ideally, I could do something like the following in my Podfile:

pod 'React' # or 'ReactNative' or whatever

And it would handle all the transitive dependencies, etc for me.

EDIT: Haha, jinx @tychota 😄

  • Votes: 15
  • Estimated time to fix: -
  • Point of contact: -
  • Comment by Facebook: Please see previous responses in this document. We are working on it!

Fresco vs best practices in iOS/ android world #

I often experience cache miss with RN , often enough so react-native-fast-image is becoming my default replacement when starting a project.

It features:

  • glide 4
  • SDWebImage

And fixes a bunch of cache miss with normal images.

https://github.com/DylanVann/react-native-fast-image

  • Votes: 14
  • Tags: readme, images
  • Estimated time to fix: -
  • Point of contact: -
  • Comment by Facebook: This is not a question.

No support for Ram bundle by any OTA platform #

Ram bundle is supported by latest react native versions but currently, it is not supported by any OTA platform like codepush. It will be great if we can have a more connected community and community-based feature prioritisation including third party libraries.

  • Votes: 14
  • Tags: issuecomment-
  • Estimated time to fix: In progress
  • Point of contact: Christoph Nakazawa (@cpojer)
  • Comment by Facebook: We are working on it!

Collecting performance metrics is difficult #

When trying to improve performance of your React Native application, it can be difficult to come up with specific metrics that reflect poor performance. Using trace tools, like the built in Systrace tracing, can give you a start, but its not as easy, as say tracing a React app in Chrome Dev Tools Performance tab. It requires collecting a trace, then opening it in Chrome Dev Tools, and attempting to decipher what various events are.

The React Native docs recommend using Instruments.app to collect this information on iOS and "you should learn to use systrace" for Android.

It'd be great to have perf tooling akin to what exists for React, such that we can empower great devs to analyze and address perf issues easily.

  • Systrace docs
  • "Profiling with Systrace" docs
  • "Optimizing Performance" from React.js docs
  • Votes: 14
  • Tags: profiling-components-with-the-chrome-performance-tab, profiling-android-ui-performance-with-systrace, profiling-components-with-the-chrome-performance-tab, performance
  • Estimated time to fix: ?
  • Point of contact: React Native Community
  • Comment by Facebook: Unfortunately we have a lot of internal tooling at Facebook to measure performance that is not applicable to open source. We'd appreciate if members from the community could step up to both improve the tooling and documentation on how to improve performance of an application.

Native API Support #

It would be really nice if instead of having to use a bunch of 3rd party libraries native phone functionality was accessable through RN itself. It would be nice to not have to use a 3rd party tool for camera, push notifications, file upload, and things like that.

  • Votes: 14
  • Estimated time to fix: -
  • Point of contact: -
  • Comment by Facebook: As mentioned in other issues in this document, we are actively trying to reduce the surface area of React Native and we hope that templates with more features on top of RN will be created.

Building time on iOS #

Building time takes a lot of time for iOS devices. When you compile multiple times your app during the day, it starts to become really annoying, especially when you see how fast it is on Android.

  • Votes: 13
  • Estimated time to fix: ?
  • Point of contact: ?
  • Comment by Facebook: This is best handled in an issue or through Pull Requests on GitHub.

Basic things are not possible (or need a dependency / native module) #

You have to install dependencies for a lot of basic things that are needed to develop an app. I would like to see more components and helpers within react-native itself. This way it gets maintained by a bigger community and it works out of the box.

A few examples:

  • Get and lock the orientation of the device
  • Ask or check for permissions
  • Get basic information from the device such as: app version, device type etc.
  • etc.

Basic things that are not possible with the current framework. Right now you have to install a dependency or you have to make a native module for yourself. A good example of something that works well is how you can get the network information with NetInfo.

  • Votes: 13
  • Estimated time to fix: -
  • Point of contact: -
  • Comment by Facebook: As mentioned in other issues in this document, we are actively trying to reduce the surface area of React Native and we hope that templates with more features on top of RN will be created.

Updating to newer versions takes too much time #

We use it for a handful of features inside of our app. But most of the parts of the app are still done in the respective native languages.

Using ReactNative decreased development time for these features. But in the long run these gains are canceling out because the effort we put into updating to newer versions is too much.

  • a new version has bugs on either iOS or Android and we therefore have to cancel the update to this version
  • breaking changes mean we have to put a lot of effort into the update, even though we only want minor features like safeArea support
  • Votes: 13
  • Estimated time to fix: -
  • Point of contact: -
  • Comment by Facebook: See the top issue on how we are planning on addressing this.

Performance documentation/tooling #

Performance documentation are hard to get into it. For instant, in iOS, it require to be proficient with Instrument and not that many of us are.

I would make sense to have a more example oriented approach, based on some demo apps so people can have access to it.

Tooling to invest performance is quite fragmented, between React Profiler, systrace, and Instrument. There is no way to have in a simple view a profile that show the performance of native and react side, and is not too low level to understand.

http://blog.nparashuram.com/2018/11/react-native-performance-playbook-part-i.html goes in the right direction but we need more polishing

  • Votes: 13
  • Tags: performance
  • Estimated time to fix: -
  • Point of contact: -
  • Comment by Facebook: Please see replies before this one. We need help from the community!

File System API #

This isn't something I necessarily dislike, but right now in order to work with the native file system we need to install & use a third partly library.

This seems like something that should be part of the core as it is very important for most projects, & some companies I've worked with (mainly enterprise) question why something like this isn't first class.

Right now, there are a couple of third party libraries that handle this, but they have in the past been neglected for periods of time.

  • Votes: 12
  • Estimated time to fix: -
  • Point of contact: -
  • Comment by Facebook: As mentioned in other issues in this document, we are actively trying to reduce the surface area of React Native and we hope that templates with more features on top of RN will be created.

AsyncStorage is broken #

Something core like AsyncStorage that is one of the only mechanisms of storage provided in RN is hopelessly and totally broken, and no updates have been given on the issue thread:

facebook/react-native#18372

and that the only alternative is to use Expo's. Please at least give an indication that core features that are an absolute necessity are being worked on, ideally a timeline!

  • Votes: 11
  • Estimated time to fix: ?
  • Point of contact: React Native Community
  • Comment by Facebook: This module was recently split out of React Native into a separate repository: react-native-async-storage. Please discuss this issue there.

Android Image Flickering #

Swapping image URLs on Android usually results in flickering (even with local resources) which doesn't happen with the native ImageView. I end up having to use the overlaid images+opacity hacks 99% of the time.

  • Votes: 10
  • Estimated time to fix: ?
  • Point of contact: ?
  • Comment by Facebook: This is best handled in a GitHub issue, please post about this there with a reproduction.

Node compatible environment #

Unlike it was done on the web with browerify & successors, react-native still does not support and implement classical native library like "url", "crypto", etc..

The current status quo is to manually install the "browserify" version of them, but it is limited. Typically if you need some crypto feature or depends on library that was targeting specific node/browser environment you might need to turn to hackier solution like rn-nodeify (one example if you want to use ripple-lib because on how heavy it depends on crypto). This works smoothly but feels really clunky.

  • Votes: 10
  • Estimated time to fix: -
  • Point of contact: -
  • Comment by Facebook: This is intentional: React Native is not aiming to be a compatible runtime to Node.js. Please let us know if there are specific modules that are necessary for your application and we can discuss individually how to make them work in React Native.

No way to respect for docs in PRs/commits #

Right now there's no constraint on updating the docs when doing PRs/commits on the master branch of react-native.
So as a consequence the docs are always lagging behind the actual implementation of react-native. sometimes even for months after being stale, Because there's no way to recognize it. The current behavior is always gonna be a cat-and-mouse game. But it shouldn't be. You don't see this problem in react itself because of its small core API.
And the best person to make sure they are sync is the author of commit/PR itself because it's an OSS project and it's already hard for maintainers to manage the issues/PRs and it would be too much to ask the maintainers to change the docs.
I really like the way that some packages decide to have the API documentation itself on the main repo (like the amazing react-native-video). This way every commit/PR can change the docs directly at the same time.
Obviously there are other solutions. But any solution that fixes this problem in a way that's automated and mandated on every commit/PR review (Like the way the tests are) would be great.

  • Votes: 10
  • Tags: Documentation, Automation
  • Estimated time to fix: ?
  • Point of contact: React Native team at Facebook
  • Comment by Facebook: Thanks for bringing this to our attention, we'll figure out a way to improve this.

Debugging Style Issues #

'Toggle Inspector' has to be one of the least used options to debug style related issues in react-native. Please consider improving this option.

  • Votes: 10
  • Tags: toggleinspector
  • Estimated time to fix: ?
  • Point of contact: React Native Community
  • Comment by Facebook: We will appreciate any Pull Requests that improves the style inspector.

install and link native modules from npm (as alternative to cocoapods/carthage) #

There is already ongoing discussion

  • Votes: 10
  • Estimated time to fix: -
  • Point of contact: -
  • Comment by Facebook: This is being addressed in the linked discussion.
@zaguiini
Copy link

Great! Any chance of having more web polyfills (like a proper AbortController, FormData, Intl, for instance)? Some of those aren’t even included and other are just not good enough — they differ from the web implementation or are inconsistent between Android and iOS. A fix for this would be great.

I can help if necessary.

@kelset kelset added the 👓 Transparency This label identifies a subject on which the core has been already discussing prior to the repo label Feb 27, 2019
@pie6k
Copy link

pie6k commented Feb 27, 2019

Wow! Great work!

@ckhicks
Copy link

ckhicks commented Feb 27, 2019

I love, love, love seeing all of the details you included here. Thanks for being transparent as part of the process!

@atrauzzi
Copy link

You missed fixing blobs.

@rafaellincoln
Copy link

I've raised a question to discuss a possibility of adding cross-platform support on react-native-push-notification-ios.

@retyui
Copy link

retyui commented Mar 6, 2019

I really don't like your's update Flow.js model!

Recently flow.js improve support React and make many breaking changes
But we can use these changes because react-native team update flow.js only on new major versions. Our project has many native modules and we have to wait when all modules will update support for next version RN after than we update flow.

@mjmasn
Copy link

mjmasn commented Mar 6, 2019

@retyui you can just update flow yourself yarn add --dev flow-bin, and update or delete the [version] section in your .flowconfig.

@retyui
Copy link

retyui commented Mar 7, 2019

@mjmasn
If you used flow.js, you would not give such advice. Since during the next update of the flow.js errors occur in the very react-native

example facebook/react-native@ef2084c#diff-a9d0201e8c5bdc946e54218bb9206174

you can see how much has been added $FlowFixMe comments

@alleniver
Copy link

great work!

@anhtukhtn
Copy link

anhtukhtn commented Mar 12, 2019

GREAT WORK!!! Thank you very much!

@cpojer
Copy link
Member Author

cpojer commented Jun 12, 2019

We shared a progress update in our latest blog post here: https://facebook.github.io/react-native/blog/2019/06/12/react-native-open-source-update and simultaneously started a new issue to request for feedback on React Native: #134

@cpojer cpojer closed this as completed Jun 12, 2019
@zaguiini
Copy link

@cpojer 404 link

@cpojer
Copy link
Member Author

cpojer commented Jun 12, 2019

@zaguiini the website update was still being propagated, it should work now :)

@RWOverdijk
Copy link

RWOverdijk commented Jun 12, 2019

Still running or just not working. working now

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
👓 Transparency This label identifies a subject on which the core has been already discussing prior to the repo
Projects
None yet
Development

No branches or pull requests