search

react-native-community / discussions-and-proposals

Discussions and proposals related to the main React Native project
https://reactnative.dev
1.69k stars 127 forks source link

What do you dislike about React Native? #64

Closed cpojer closed 5 years ago

cpojer commented 5 years ago

Edit: See our reply here: https://github.com/react-native-community/discussions-and-proposals/issues/104.

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

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

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

Hypothetical Example:

Not enough emoji

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

janhesters commented 5 years ago

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

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

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.

dx #debugging #crash

slorber commented 5 years ago

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

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

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

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.

xzilja commented 5 years ago

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

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

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

Support of React Native team

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

Examples:

matt-oakes commented 5 years ago

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

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

Metro follow symlinks

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

Related issue:

dx #packaging #symlinks #metro

Gregoirevda commented 5 years ago

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

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

fakenickels commented 5 years ago

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

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

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

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

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

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

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

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

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

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

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

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

Warnings in Xcode

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

PierreCapo commented 5 years ago

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.

dayhaysoos commented 5 years ago

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.

grabbou commented 5 years ago

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.

PierreCapo commented 5 years ago

Inspector in debug tools flexibility

The inspector in debug tools is less flexible than his web counterpart. Usually there are a lot more nodes in the arborescence which makes it totally cluttered.

PierreCapo commented 5 years ago

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.

PierreCapo commented 5 years ago

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.

PierreCapo commented 5 years ago

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.

dayhaysoos commented 5 years ago

Expo

In theory, expo sounds amazing and I love it, but in practice it hasn't been great for me personally. I had really weird issues with just trying to run expo, and go between different expo projects. It feels like whole other eco system to adapt to on top of trying to manage Xcode/Android studio things.

I think one problem React Native is having as far as being adopted by the industry is that it feels too immature, over the years it's gotten much much better and React Native is getting there, I'm very pleased.

However, I'm afraid that Expo is very immature right now, and since it's being shipped at the initial phases of starting a RN project, it makes RN look very immature/inconsistent.

grabbou commented 5 years ago

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

horaciomoreno10 commented 5 years ago

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.

atrauzzi commented 5 years ago

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.

atrauzzi commented 5 years ago

Application startup could be more refined

After a lot of trial an error, I've discovered that the only way to correctly boot my own utility library is to contain it within a kind of bootstrap component.

React Native seems to have a very strict dependency on having a React component very early on in its lifecycle and offers no way to obtain a rootTag without having an initial bootstrap component.

Examples:

  1. Bootstrap component.
  2. Capture rootTag and then boot my application framework.
  3. Overwrite the bootstrap component with my root component once my application framework is running.

I think a lot of what I did here is necessary just to get the correct lifecycle established without resorting to any kinds of compromises. It is however still a bit of a workaround and I think could be improved by adding/allowing:

syq7970 commented 5 years ago

Old and pool native api

Just like cameraRoll and Fetch in iOS，cameraRoll used deprecated api and Fetch lost advance api like selfSigned ssl and interceptor. Actually extension native apis cost 50 percent of my time.

absolute-heike commented 5 years ago

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.

syq7970 commented 5 years ago

High performance list lost This is a critical issue that give me a lower develop experience. A recycleable and low memory used listview is still not implement in RN, I have to work hard with optimize listview what it is not needed in pure native. I wish some day, I can develop pure RN app without too much hard based work, just write business and ui like a charm.

Kikketer commented 5 years ago

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.

muhozi commented 5 years ago

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.

I noticed that for using npm when installing dependencies doesn't show warnings but when you use yarn the warnings come up. When initializing new react native app(react-native init) it should show warnings because the dependencies get installed using yarn by default.

edvinasbartkus commented 5 years ago

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.

jeremy-deutsch commented 5 years ago

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.

hfossli commented 5 years ago

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)

mbyram1 commented 5 years ago

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.

Kikketer commented 5 years ago

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.