search

react-native-community / discussions-and-proposals

Discussions and proposal related to the main React Native project
https://facebook.github.io/react-native/
1.64k stars 124 forks source link

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

Closed cpojer closed 5 years ago

cpojer commented 5 years ago

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 (https://github.com/react-native-community/discussions-and-proposals/issues/4) and TurboModules (https://github.com/react-native-community/discussions-and-proposals/issues/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.

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:

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.

Metro follow symlinks #

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

Related 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.

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.

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.

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.

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.

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:

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.

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.

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.

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.

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

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.

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:

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.

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

https://github.com/facebook/react-native/issues/934

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.

https://github.com/facebook/react-native/issues/21836 https://github.com/facebook/react-native/issues/20462

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

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.

react-native link issues #

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

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.

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.

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.

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.

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.

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?

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.

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".

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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:

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.

Official Camera && Video && Audio Modules #

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

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)

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.

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

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

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.

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.

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.

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

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={...}>.

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.

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.

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.

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.

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.

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: https://github.com/react-native-community/discussions-and-proposals/pull/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 😄

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:

And fixes a bunch of cache miss with normal images.

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

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.

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.

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.

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.

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:

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.

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.

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

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.

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!

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.

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.

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.

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.

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

There is already ongoing discussion

zaguiini commented 5 years ago

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.

pie6k commented 5 years ago

Wow! Great work!

ckhicks commented 5 years ago

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

atrauzzi commented 5 years ago

You missed fixing blobs.

rafaellincoln commented 5 years ago

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

retyui commented 5 years ago

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 commented 5 years ago

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

retyui commented 5 years ago

@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 https://github.com/facebook/react-native/commit/ef2084c6bd52d4c89022d808406e41660917860c#diff-a9d0201e8c5bdc946e54218bb9206174

you can see how much has been added $FlowFixMe comments

alleniver commented 5 years ago

great work!

anhtukhtn commented 5 years ago

GREAT WORK!!! Thank you very much!

cpojer commented 5 years ago

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: https://github.com/react-native-community/discussions-and-proposals/issues/134

zaguiini commented 5 years ago

@cpojer 404 link

cpojer commented 5 years ago

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

RWOverdijk commented 5 years ago

~Still running or just not working.~ working now