New issue

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

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

Already on GitHub? Sign in to your account

What do you dislike about React Native? #64

Open
cpojer opened this Issue Dec 6, 2018 · 127 comments

Comments

Projects
None yet
@cpojer

cpojer commented Dec 6, 2018

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

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

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

Hypothetical Example:

Not enough emoji

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

@janhesters

This comment has been minimized.

janhesters commented Dec 6, 2018

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. #upgrading

@slorber

This comment has been minimized.

slorber commented Dec 6, 2018

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.

#dx #debugging

@slorber

This comment has been minimized.

slorber commented Dec 6, 2018

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.

#dx #debugging #crash

@slorber

This comment has been minimized.

slorber commented Dec 6, 2018

Hot reloading

Hot reload does not work great with Stateless Functional Components (SFC) 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 SFC 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 SFC to class in __DEV__?

#dx #hotreload

@roydipti23

This comment has been minimized.

roydipti23 commented Dec 6, 2018

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.

@slorber

This comment has been minimized.

slorber commented Dec 6, 2018

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.

#dx #styles

@tomduncalf

This comment has been minimized.

tomduncalf commented Dec 6, 2018

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.

@IljaDaderko

This comment has been minimized.

IljaDaderko commented Dec 6, 2018

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.

#dx

@thecachedbyte

This comment has been minimized.

thecachedbyte commented Dec 6, 2018

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.

@thecachedbyte

This comment has been minimized.

thecachedbyte commented Dec 6, 2018

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.

@Gregoirevda

This comment has been minimized.

Gregoirevda commented Dec 6, 2018

Support of React Native team

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

Examples:

  • many github issues are unanswered
  • blog posts on good practices for advanced problems
@matt-oakes

This comment has been minimized.

matt-oakes commented Dec 6, 2018

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.

@matt-oakes

This comment has been minimized.

matt-oakes commented Dec 6, 2018

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:

@slorber

This comment has been minimized.

slorber commented Dec 6, 2018

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:

#dx #packaging #symlinks #metro

@Gregoirevda

This comment has been minimized.

Gregoirevda commented Dec 6, 2018

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. #bridge #documentation

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

@grsabreu

This comment has been minimized.

grsabreu commented Dec 6, 2018

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.

#ux #animations #dx

@slorber

This comment has been minimized.

slorber commented Dec 6, 2018

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.

#dx #documentation

@subtleGradient

This comment has been minimized.

subtleGradient commented Dec 6, 2018

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?

@subtleGradient

This comment has been minimized.

subtleGradient commented Dec 6, 2018

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.

@assertchris

This comment has been minimized.

assertchris commented Dec 6, 2018

Android emulation is bad

It is a slow and ugly process to run an app through the Android emulator. The Android toolchain is a great effort, by much better developers than myself; but it's still slow and prohibitively expensive (in SSD space).

I don't know what the solution is, here. Deeper and/or faster links to hosted emulation? Free devices for all? Who knows.

Edit: this seems to be an unpopular opinion. I should clarify that; when compared to the speed, stability, and easy of setup of iOS simulator; Android emulation is years behind. I'm not saying this to be cruel or because I think I can do better. I'm saying it because it's demonstrably easier and better to develop strictly for iOS and ignore Android (even for the trivial case) because the only tooling available for Android is prohibitively poor in comparison.

@assertchris

This comment has been minimized.

assertchris commented Dec 6, 2018

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.

@petterh

This comment has been minimized.

petterh commented Dec 6, 2018

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.

@ferrannp

This comment has been minimized.

ferrannp commented Dec 6, 2018

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.

@ferrannp

This comment has been minimized.

ferrannp commented Dec 6, 2018

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

@ferrannp

This comment has been minimized.

ferrannp commented Dec 6, 2018

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.

@ferrannp

This comment has been minimized.

ferrannp commented Dec 6, 2018

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.

@ferrannp

This comment has been minimized.

ferrannp commented Dec 6, 2018

PRs

Mostly we believe 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.

@muhozi

This comment has been minimized.

muhozi commented Dec 6, 2018

Warnings in Xcode

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

@yuriy-yarosh

This comment was marked as disruptive content.

yuriy-yarosh commented Dec 7, 2018

RTCBridge throughput

• Low RTCBridge throughput

causes drastic and overwhelming 60fps capable optimization effort, everything else are marketing materials. When 99% of your components ending in a native (Kotlin/Swift) port, there's no point in using react-native at all. Airbnb came to the same conclusion after almost three years of struggle - It just doesn't worth the effort.

Lack of CSS units

• Absense of proper CSS units like vmin / vmax / vh / vw / rem etc

99% of viable projects are using 3rd party polyfils for those most of the time, and I'd be happy to be able to reuse the same react components on react-native. I don't think that people are happy that you're keep on ignoring the fact that stylesheets from iOS are always broken on other devices like Samsung Galaxy Series phones and tablets. I've seen tons of vendor-bugs before, but you're keep on pretending like there's none... it does irritate people, and contributes to the github issues pool.

No proper flebox/grid support

• Absense of proper flebox/grid support

I do get the point of Yoga, but meh, it's 2018... you should've replaced that long time ago. I do know at least three enterprise RN projects who are replacing yoga just to be able to reuse the stylesheets across react and react-native effectively.

Too many langs without any proper test cases makes this project a pile of garbage

• Overall RN QA is bullshit

I do get that you've guys started with C/C++/Objective-C/Objective-C++ with different folks, without any proper test cases, implemented by no one really remembers whom and why. Again, this is a decent soil for vendor-specific bugs to strive. And just getting things sorted, like the navigation mentioned above, will take too much toll and effort. I do get that FB management is bs and you're applying 50 shades of "ship it", for a yet another way of ignorance/hype monetization on a yet another conference, but more experienced people are just way too tired of that crap.

Up to 800 github issues/day is bs

•Up to 800 github issues per day,

and overall ignorance only about that fact triggers lots of folks.
I don't care that much, I've switched to native, and it's great... At least longterm support costs are like 3 times lower. Just asking people "what's wrong about RN?" shows how shortsighted is the decision making... and react-native is all about monetizing hype, and not about the development experience. Showing some attention, when things already started to burn, really does explain your priorities.

If you'd really paid any attention to the community feedback none of the above would be even possible in the first place.

Nah, RN is just full of hypocritical crap overflowing from all over the places, and you can't really hide it anymore... that would be the shortest explanation of "what I, personally, don't like in RN".

☝️just me being triggered by the most obvious and ignorant question ...

@miblanchard

This comment has been minimized.

miblanchard commented Dec 7, 2018

react-native link does not work in monorepos with multiple apps

It would be awesome if we could use react-native link in our monorepo by providing a path from root to the folder where the app is located (ex. packages/apps/TestApp), in order to still use this convenient tool.

@aarjithn

This comment has been minimized.

aarjithn commented Dec 7, 2018

No support for gesture navigation

Nowadays in mobile apps, it is common to have draggable navigation along with shared element transition. For eg, Photos in gallery/whatsapp etc where you can drag down to go to the previous screen. You see items fading in and moving while you drag down. sample

fram-x/FluidTransitions lets you use a shared element, but it is based on stack navigator and doesn't work with gestures.

@Tkoefod

This comment has been minimized.

Tkoefod commented Dec 7, 2018

Using audio inside RN seems a lot more complicated then it should be, and I find it odd there is no official usage of audio.

@bogdan-calapod

This comment has been minimized.

bogdan-calapod commented Dec 7, 2018

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.

@assertchris

This comment has been minimized.

assertchris commented Dec 8, 2018

Perf monitor hides after cmd + R

When you "Show Perf Monitor", from the debug menu; it is displayed. After that, when you cmd + R; the monitor disappears but debug menu still shows "Hide Perf Monitor". It would be great if perf monitor was displayed post cmd + R, or if debug menu reflected the shown/hidden state of perf monitor correctly. I would prefer the first solution...

@neiker

This comment has been minimized.

neiker commented Dec 8, 2018

Lack of JIT compiler

I know is a system limitation on iOS, but why is missing on Android?

@IljaDaderko

This comment has been minimized.

IljaDaderko commented Dec 8, 2018

Concerns about being up to date with latest features / tooling

To me it seems as react-native is in this weird state where we are light years ahead on things like bridging js to native, but very far behind advancements happening in iOS / Android scene.

Some recent examples of when we had too wait way to long for support of new features and tooling include

  1. XCode 10
  2. Updating android target sdk

And I am now a bit concerned about new high refresh rate devices coming out, I'm not sure if react-native is ready to support ui's running faster than 60fps?

It seems as if we are settling with "implementation from one year ago is still working fine, no need to tweak it", instead of striving for quick adoption of new features and tooling. And this makes sense at facebooks scale, i.e. these would probably be breaking changes, but I'm sure many projects of smaller scale or new ones would want to try new things out.

@lyahdav

This comment has been minimized.

lyahdav commented Dec 9, 2018

Accessibility

I haven't looked into the state of accessibility in React Native, but this blog post paints a bleak story (at least on iOS) if it's accurate.

@dalcib

This comment has been minimized.

dalcib commented Dec 9, 2018

The lack of officially supported Typescript definitions.
People that contribute to DefinitelyType are doing a good job, but official support would be welcome

@cpojer

This comment has been minimized.

cpojer commented Dec 10, 2018

Thank you everyone for participating in this discussion, this has been incredibly helpful to understand both the problems people are facing as well as what they are bothered by. We appreciate that so many people added their thoughts and that people stuck to the issue template without going off the rails. We would like to ask everyone not to add more items to this list for now, as it has gotten incredibly long.

I cleaned up this issue a little bit and deleted comments by core contributors of RN urging people to stay close to the template, and I removed some comments that strayed too far from the proposed template and also got a large number of downvotes in an effort to keep this GitHub issue readable and the responses actionable.

I took every single comment here and put it into a list, sorted by the total number of positive reactions (thumbs up, laugh, hooray, heart) minus the negative reactions (thumbs down, confused). I am dismissing comments with zero or negative overall reactions assuming they are not considered as important by a large amount of people using React Native. Next, my plan is to group them into these categories:

  • Things that Facebook is already working on and/or planning on working on
  • Things the community is working on or could work on
  • Things that we choose not to work on (right now)
  • Things outside of the scope of React Native, or things that aren't actionable or concrete enough

We will discuss everything within the React Native team at Facebook and the community of core contributors before we will publish this document and the actions we will take based on the comments we got here. We can't promise any concrete action that we will take at this time, and there is a ton of other work we are doing for open source (see https://facebook.github.io/react-native/blog/2018/11/01/oss-roadmap for an overview) so please give us some time to work through this. I promise we'll get back to you by mid-January. For now please enjoy your holiday season with a lot of good food and your family :)

@xtrycatchx

This comment has been minimized.

xtrycatchx commented Dec 10, 2018

Buffer type support for RCT_EXPORT_METHOD

Might interesting if RN can support Buffer / bytes arguments for Native Modules. Currently, it only supports these: https://facebook.github.io/react-native/docs/native-modules-ios#argument-types

#wishlist

This was referenced Dec 11, 2018

@cpojer

This comment has been minimized.

cpojer commented Dec 11, 2018

I finished generating the document. For full transparency, here is the actual script used to create the markdown document that we are now iterating on: GitHub Gist. Please expect a reply sometime after mid-January.

The two top voted comments are "Upgrading requires a lot (too much?) effort" and "Debugging exceptions". Both of them are very broad so we would like to gather a better understanding about the concrete problems people are running into. If you have problems with upgrading or debugging, please comment in the follow-up issues:

@hramos hramos referenced this issue Dec 11, 2018

Open

Warnings in Xcode #22609

0 of 9 tasks complete
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment